Making sure there is only one source of truth for

DO pricing.

Author: Oxyjun

src/content/partials/durable-objects/durable-objects-pricing.mdx

@@ -1,83 +1,31 @@
 ---
 {}
-
 ---
 
-import { Markdown } from "~/components"
-
-## Durable Objects
-
-Durable Objects are available on both Workers Free and [Workers Paid plans](/workers/platform/pricing/#workers).
-
-|                      | Free plan | Paid plan                                         |
-| -------------------- | --------- | ------------------------------------------------- |
-| Requests<sup>1</sup> |           | 1 million, + $0.15/million                        |
-| Duration<sup>2</sup> |           | 400,000 GB-s, + $12.50/million GB-s<sup>3,4</sup> |
-
-
-<sup>1</sup> Requests include all incoming HTTP requests, WebSocket messages, and alarm invocations. 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).
-
-<sup>2</sup> Application-level auto-response messages handled by [`state.setWebSocketAutoResponse()`](/durable-objects/best-practices/websockets/) will not incur additional wall-clock time, and will not be charged.
-
-<sup>3</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. Once your Object finishes responding to all requests, it will stop incurring duration charges. Calling `accept()` on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. Prefer using [`state.acceptWebSocket()`](/durable-objects/best-practices/websockets/), which will stop incurring duration charges once all event handlers finish running.
-
-<sup>4</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.
-
-### Durable Objects billing examples
-
-These examples exclude the costs for the Workers calling the Durable Objects.
-
-#### Example 1
-
-If a single Durable Object was called by a Worker 1.5 million times, and was active for 1,000,000 seconds in the month, the estimated cost in a month would be:
-
-Total = ~$0.08 USD + Minimum $5/mo usage = $5.08
-
-- (1.5 million requests - included 1 million requests) x $0.15 / 1,000,000 = $0.075
-- 1,000,000 seconds \* 128 MB / 1 GB = 128,000 GB-s
-- (128,000 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $0.00
-
-#### Example 2
-
-If 100 Durable Objects each had 100 WebSocket connections established to each of them which sent approximately one message a minute for a month, the estimated cost in a month would be, if the messages overlapped so that the Objects were actually active for half the month:
-
-Total = ~$64.65 USD + $202.36 USD + Minimum $5/mo usage = $272.01
-
-- 100 requests to establish the WebSockets.
-- 100 messages per minute \* 100 Durable Objects \* 60 minutes \* 24 hours \* 30 days = 432,000,000 requests
-- (432 million requests - included 1 million requests) x $0.15 / 1,000,000 = $64.65
-- 100 Durable Objects \* 60 seconds \* 60 minutes \* 24 hours \* 30 days / 2 = 129,600,000 seconds
-- 129,600,000 seconds \* 128 MB / 1 GB = 16,588,800 GB-s
-- (16,588,800 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $202.36
+import { Markdown, GlossaryTooltip } from "~/components";
 
-#### Example 3
+[Durable Objects](/durable-objects/) are available on both the Workers Free and [Workers Paid plans](/workers/platform/pricing/#workers), and are billed while the Durable Object is active (including the <GlossaryTooltip term="request context"> request context</GlossaryTooltip>).
 
-If 100 Durable Objects each had a single WebSocket connection established to each of them, which sent one message a second for a month, and the messages overlapped so that the Objects were actually active for the entire month, the estimated cost in a month would be:
+|                      | Paid plan                                                                                                                               |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| Requests             | 1 million, + $0.15/million<br/> Includes HTTP requests, RPC sessions<sup>1</sup>, WebSocket messages<sup>2</sup>, and alarm invocations |
+| Duration<sup>3</sup> | 400,000 GB-s, + $12.50/million GB-s<sup>4,5</sup>                                                                                       |
 
-Total = ~$38.73 USD + $409.72 USD + Minimum $5/mo usage = $453.45
+<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.
 
-- 100 requests to establish the WebSockets.
-- 1 message per second \* 100 connections \* 60 seconds \* 60 minutes \* 24 hours \* 30 days = 259,200,000 requests
-- (259.2 million requests - included 1 million requests) x $0.15 / 1,000,000 = $38.73
-- 100 Durable Objects \* 60 seconds \* 60 minutes \* 24 hours \* 30 days = 259,200,000 seconds
-- 259,200,000 seconds \* 128 MB / 1 GB = 33,177,600 GB-s
-- (33,177,600 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $409.72
+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:
 
-## Storage API
+```js
+let durableObjectStub = OBJECT_NAMESPACE.get(id); // retrieve Durable Object stub
+using foo = await durableObjectStub.bar(); // billed as a request
+await foo.baz(); // treated as part of the same RPC session created by calling bar(), not billed as a request
+await durableObjectStub.cat(); // billed as a request
+```
 
-The [Storage API](/durable-objects/api/storage-api/) is only accessible from within Durable Objects. Durable Objects do not have to use the Storage API, but if your code does call methods on `state.storage`, it will incur the following additional charges:
+<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.
 
-|                                  | Paid plan                  |
-| -------------------------------- | -------------------------- |
-| Read request units<sup>1,2</sup> | 1 million, + $0.20/million |
-| Write request units<sup>1</sup>  | 1 million, + $1.00/million |
-| Delete requests<sup>3</sup>      | 1 million, + $1.00/million |
-| Stored data<sup>4</sup>          | 1 GB, + $0.20/ GB-month    |
+<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.
 
-1.  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 three write request units.
-2.  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 one read request unit.
-3.  Delete requests are unmetered. For example, deleting a 100 KB value will be charged one delete request.
-4.  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.
-5.  Each alarm write is billed as a single write request unit.
+<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 at least 60 seconds after the last client disconnects. 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.
 
-Requests that hit the Durable Objects in-memory cache 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.
+<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.