You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Durable Objects are billed only while the Durable Object is active (includes the <GlossaryTooltipterm="request context"> request context</GlossaryTooltip>).
<sup>1</sup> Each [RPC session](/workers/runtime-apis/rpc/lifecycle/) is billed as one request to your Durable Object. Every [RPC method call](/durable-objects/best-practices/create-durable-object-stubs-and-send-requests/) on a [Durable Objects stub](/durable-objects/) is its own RPC session and therefore a single billed request.
26
+
<sup>1</sup> Each [RPC session](/workers/runtime-apis/rpc/lifecycle/) is billed
27
+
as one request to your Durable Object. Every [RPC method
on a [Durable Objects stub](/durable-objects/) is its own RPC session and
30
+
therefore a single billed request.
21
31
22
32
RPC method calls can return objects (stubs) extending [`RpcTarget`](/workers/runtime-apis/rpc/lifecycle/#lifetimes-memory-and-resource-management) and invoke calls on those stubs. Subsequent calls on the returned stub are part of the same RPC session and are not billed as separate requests. For example:
23
33
@@ -28,13 +38,34 @@ await foo.baz(); // treated as part of the same RPC session created by calling b
28
38
awaitdurableObjectStub.cat(); // billed as a request
29
39
```
30
40
31
-
<sup>2</sup> A request is needed to create a WebSocket connection. There is no charge for outgoing WebSocket messages, nor for incoming [WebSocket protocol pings](https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2). For compute requests billing-only, a 20:1 ratio is applied to incoming WebSocket messages to factor in smaller messages for real-time communication. For example, 100 WebSocket incoming messages would be charged as 5 requests for billing purposes. The 20:1 ratio does not affect Durable Object metrics and analytics, which reflect actual usage.
32
-
33
-
<sup>3</sup> Application level auto-response messages handled by [`state.setWebSocketAutoResponse()`](/durable-objects/best-practices/websockets/) will not incur additional wall-clock time, and so they will not be charged.
34
-
35
-
<sup>4</sup> Duration is billed in wall-clock time as long as the Object is active, but is shared across all requests active on an Object at once. Calling `accept()` on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. Note that the request context for a Durable Object extends for 10 seconds after the last client disconnects. The request context of a Durable Object is evaluated every 70 seconds and the context is ended if it has been active for 70 seconds. If you prefer, use the [WebSocket Hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) to avoid incurring duration charges once all event handlers finish running.
36
-
37
-
<sup>5</sup> Duration billing charges for the 128 MB of memory your Durable Object is allocated, regardless of actual usage. If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. These Durable Objects are still billed as if they are allocated a full 128 MB of memory.
41
+
<sup>2</sup> A request is needed to create a WebSocket connection. There is no
42
+
charge for outgoing WebSocket messages, nor for incoming [WebSocket protocol
43
+
pings](https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2). For compute
44
+
requests billing-only, a 20:1 ratio is applied to incoming WebSocket messages to
45
+
factor in smaller messages for real-time communication. For example, 100
46
+
WebSocket incoming messages would be charged as 5 requests for billing purposes.
47
+
The 20:1 ratio does not affect Durable Object metrics and analytics, which
48
+
reflect actual usage.
49
+
50
+
<sup>3</sup> Application level auto-response messages handled by
<sup>2</sup> Key-value methods like `get()`, `put()`, `delete()`, or `list()` store and query data in a hidden SQLite table and are billed as rows read and rows written.
96
+
<sup>2</sup> Key-value methods like `get()`, `put()`, `delete()`, or `list()`
97
+
store and query data in a hidden SQLite table and are billed as rows read and
98
+
rows written.
65
99
66
-
<sup>3</sup> Each `setAlarm()` is billed as a single row written.
100
+
<sup>3</sup> Each `setAlarm()` is billed as a single row written.
67
101
68
-
<sup>4</sup> Deletes are counted as rows written.
102
+
<sup>4</sup> Deletes are counted as rows written.
69
103
70
-
<sup>5</sup> Durable Objects will be billed for stored data until the [data is removed](/durable-objects/best-practices/access-durable-objects-storage/#remove-a-durable-objects-storage). Once the data is removed, the object will be cleaned up automatically by the system.
104
+
<sup>5</sup> Durable Objects will be billed for stored data until the [data is
Once the data is removed, the object will be cleaned up automatically by the
107
+
system.
71
108
72
109
</Details>
73
110
@@ -83,16 +120,24 @@ The [Durable Objects Storage API](/durable-objects/api/storage-api/) is only acc
83
120
84
121
<Detailsheader="Footnotes"open={true}>
85
122
86
-
<sup>1</sup> A request unit is defined as 4 KB of data read or written. A request that writes or reads more than 4 KB will consume multiple units, for example, a 9 KB write will consume 3 write request units.
123
+
<sup>1</sup> A request unit is defined as 4 KB of data read or written. A
124
+
request that writes or reads more than 4 KB will consume multiple units, for
125
+
example, a 9 KB write will consume 3 write request units.
87
126
88
-
<sup>2</sup> List operations are billed by read request units, based on the amount of data examined. For example, a list request that returns a combined 80 KB of keys and values will be billed 20 read request units. A list request that does not return anything is billed for 1 read request unit.
127
+
<sup>2</sup> List operations are billed by read request units, based on the
128
+
amount of data examined. For example, a list request that returns a combined 80
129
+
KB of keys and values will be billed 20 read request units. A list request that
130
+
does not return anything is billed for 1 read request unit.
89
131
90
-
<sup>3</sup> Each `setAlarm` is billed as a single write request unit.
132
+
<sup>3</sup> Each `setAlarm` is billed as a single write request unit.
91
133
92
-
<sup>4</sup> Delete requests are unmetered. For example, deleting a 100 KB value will be charged one delete request.
134
+
<sup>4</sup> Delete requests are unmetered. For example, deleting a 100 KB value
135
+
will be charged one delete request.
93
136
94
-
<sup>5</sup> Durable Objects will be billed for stored data until the data is removed. Once the data is removed, the object will be cleaned up automatically by the system.
137
+
<sup>5</sup> Durable Objects will be billed for stored data until the data is
138
+
removed. Once the data is removed, the object will be cleaned up automatically
139
+
by the system.
95
140
96
141
Requests that hit the [Durable Objects in-memory cache](/durable-objects/reference/in-memory-state/) or that use the [multi-key versions of `get()`/`put()`/`delete()` methods](/durable-objects/api/storage-api/) are billed the same as if they were a normal, individual request for each key.
0 commit comments