Joshthoward/do pricing update

src/content/docs/durable-objects/platform/pricing.mdx

@@ -5,114 +5,119 @@ sidebar:
   order: 1
 ---
 
-import { Render } from "~/components"
+import { Render } from "~/components";
 
 Durable Objects can incur two types of billing: compute and storage.
 
-<Render file="do-plans-note"/>
+<Render file="do-plans-note" />
 
 On Workers Free plan:
+
 - If you exceed any one of the free tier limits, further operations of that type will fail with an error.
 - Daily free limits reset at 00:00 UTC.
 
-<Render file="durable-objects-pricing" product="durable-objects" params={{product:"durable-objects"}}/>
+<Render
+	file="durable-objects-pricing"
+	product="durable-objects"
+	params={{ product: "durable-objects" }}
+/>
 
 ## Compute billing examples
 
 These examples exclude the costs for the Workers calling the Durable Objects. When modelling the costs of a Durable Object, note that:
 
-* Inactive objects receiving no requests do not incur any duration charges.
-* The [WebSocket Hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) can dramatically reduce duration-related charges for Durable Objects communicating with clients over the WebSocket protocol, especially if messages are only transmitted occasionally at sparse intervals.
+- Inactive objects receiving no requests do not incur any duration charges.
+- The [WebSocket Hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) can dramatically reduce duration-related charges for Durable Objects communicating with clients over the WebSocket protocol, especially if messages are only transmitted occasionally at sparse intervals.
 
 ### Example 1
 
 This example represents a simple Durable Object used as a co-ordination service invoked via HTTP.
 
-* A single Durable Object was called by a Worker 1.5 million times
-* It is active for 1,000,000 seconds in the month
+- A single Durable Object was called by a Worker 1.5 million times
+- It is active for 1,000,000 seconds in the month
 
 In this scenario, the estimated monthly cost would be calculated as:
 
 **Requests**:
 
-* (1.5 million requests - included 1 million requests) x $0.15 / 1,000,000 = $0.075
+- (1.5 million requests - included 1 million requests) x $0.15 / 1,000,000 = $0.075
 
 **Compute Duration**:
 
-* 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
+- 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
 
 **Estimated total**: \~$0.075 (requests) + $0.00 (compute duration) + minimum $5/mo usage = $5.08 per month
 
 ### Example 2
 
 This example represents a moderately trafficked Durable Objects based application using WebSockets to broadcast game, chat or real-time user state across connected clients:
 
-* 100 Durable Objects have 50 WebSocket connections established to each of them.
-* Clients send approximately one message a minute for eight active hours a day, every day of the month.
+- 100 Durable Objects have 50 WebSocket connections established to each of them.
+- Clients send approximately one message a minute for eight active hours a day, every day of the month.
 
 In this scenario, the estimated monthly cost would be calculated as:
 
 **Requests**:
 
-* 50 WebSocket connections \* 100 Durable Objects to establish the WebSockets = 5,000 connections created each day \* 30 days = 150,000 WebSocket connection requests.
-* 50 messages per minute \* 100 Durable Objects \* 60 minutes \* 8 hours \* 30 days = 72,000,000 WebSocket message requests.
-* 150,000 + (72 million requests / 20 for WebSocket message billing ratio) = 3.75 million billing request.
-* (3.75 million requests - included 1 million requests) x $0.15 / 1,000,000 = $0.41.
+- 50 WebSocket connections \* 100 Durable Objects to establish the WebSockets = 5,000 connections created each day \* 30 days = 150,000 WebSocket connection requests.
+- 50 messages per minute \* 100 Durable Objects \* 60 minutes \* 8 hours \* 30 days = 72,000,000 WebSocket message requests.
+- 150,000 + (72 million requests / 20 for WebSocket message billing ratio) = 3.75 million billing request.
+- (3.75 million requests - included 1 million requests) x $0.15 / 1,000,000 = $0.41.
 
 **Compute Duration**:
 
-* 100 Durable Objects \* 60 seconds \* 60 minutes \* 8 hours \* 30 days = 86,400,000 seconds.
-* 86,400,000 seconds \* 128 MB / 1 GB = 11,059,200 GB-s.
-* (11,059,200 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $133.24.
+- 100 Durable Objects \* 60 seconds \* 60 minutes \* 8 hours \* 30 days = 86,400,000 seconds.
+- 86,400,000 seconds \* 128 MB / 1 GB = 11,059,200 GB-s.
+- (11,059,200 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $133.24.
 
 **Estimated total**: $0.41 (requests) + $133.24 (compute duration) + minimum $5/mo usage = $138.65 per month.
 
 ### Example 3
 
 This example represents a horizontally scaled Durable Objects based application using WebSockets to communicate user-specific state to a single client connected to each Durable Object.
 
-* 100 Durable Objects each have a single WebSocket connection established to each of them.
-* Clients sent one message every second of the month so that the Durable Objects were active for the entire month.
+- 100 Durable Objects each have a single WebSocket connection established to each of them.
+- Clients sent one message every second of the month so that the Durable Objects were active for the entire month.
 
 In this scenario, the estimated monthly cost would be calculated as:
 
 **Requests**:
 
-* 100 WebSocket connection requests.
-* 1 message per second \* 100 connections \* 60 seconds \* 60 minutes \* 24 hours \* 30 days = 259,200,000 WebSocket message requests.
-* 100 + (259.2 million requests / 20 for WebSocket billing ratio) = 12,960,100 requests.
-* (12.9 million requests - included 1 million requests) x $0.15 / 1,000,000 = $1.79.
+- 100 WebSocket connection requests.
+- 1 message per second \* 100 connections \* 60 seconds \* 60 minutes \* 24 hours \* 30 days = 259,200,000 WebSocket message requests.
+- 100 + (259.2 million requests / 20 for WebSocket billing ratio) = 12,960,100 requests.
+- (12.9 million requests - included 1 million requests) x $0.15 / 1,000,000 = $1.79.
 
 **Compute Duration**:
 
-* 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
+- 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
 
 **Estimated total**: $1.79 (requests) + $409.72 (compute duration) + minimum $5/mo usage = $416.51 per month
 
 ### Example 4
 
 This example represents a moderately trafficked Durable Objects based application using WebSocket Hibernation to broadcast game, chat or real-time user state across connected clients:
 
-* 100 Durable Objects each have 100 Hibernatable WebSocket connections established to each of them.
-* Clients send one message per minute, and it takes 10ms to process a single message in the `webSocketMessage()` handler. Since each Durable Object handles 100 WebSockets, cumulatively each Durable Object will be actively executing JS for 1 second each minute (100 WebSockets \* 10ms).
+- 100 Durable Objects each have 100 Hibernatable WebSocket connections established to each of them.
+- Clients send one message per minute, and it takes 10ms to process a single message in the `webSocketMessage()` handler. Since each Durable Object handles 100 WebSockets, cumulatively each Durable Object will be actively executing JS for 1 second each minute (100 WebSockets \* 10ms).
 
 In this scenario, the estimated monthly cost would be calculated as:
 
 **Requests**:
 
-* 100 WebSocket connections \* 100 Durable Objects to establish the WebSockets = 10,000 initial WebSocket connection requests.
-* 100 messages per minute<sup>1</sup> \* 100 Durable Objects \* 60 minutes \* 24 hours \* 30 days = 432,000,000 requests.
-* 10,000 + (432 million requests / 20 for WebSocket billing ratio) = 21,610,000 million requests.
-* (21.6 million requests - included 1 million requests) x $0.15 / 1,000,000 = $3.09.
+- 100 WebSocket connections \* 100 Durable Objects to establish the WebSockets = 10,000 initial WebSocket connection requests.
+- 100 messages per minute<sup>1</sup> \* 100 Durable Objects \* 60 minutes \* 24 hours \* 30 days = 432,000,000 requests.
+- 10,000 + (432 million requests / 20 for WebSocket billing ratio) = 21,610,000 million requests.
+- (21.6 million requests - included 1 million requests) x $0.15 / 1,000,000 = $3.09.
 
 **Compute Duration**:
 
-* 100 Durable Objects \* 1 second<sup>2</sup> \* 60 minutes \* 24 hours \* 30 days = 4,320,000 seconds
-* 4,320,000 seconds \* 128 MB / 1 GB = 552,960 GB-s
-* (552,960 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $1.91
+- 100 Durable Objects \* 1 second<sup>2</sup> \* 60 minutes \* 24 hours \* 30 days = 4,320,000 seconds
+- 4,320,000 seconds \* 128 MB / 1 GB = 552,960 GB-s
+- (552,960 GB-s - included 400,000 GB-s) x $12.50 / 1,000,000 = $1.91
 
 **Estimated total**: $3.09 (requests) + $1.91 (compute duration) + minimum $5/mo usage = $10.00 per month
 
@@ -134,20 +139,19 @@ The metadata remains in the Durable Object until you call [`deleteAll()`](/durab
 
 ### When does a Durable Object incur duration charges?
 
-A Durable Object incurs duration charges as long as the JavaScript object is held in memory. Once an object has been evicted from memory, the next time it is needed, it will be recreated (calling the constructor again). There are two factors which decide when an object may be evicted from memory: hibernatability and existence of clients.
+A Durable Object incurs duration charges as long as the JavaScript object is not able to be evicted from memory. Once an object has been evicted from memory, the next time it is needed, it will be recreated (calling the constructor again). There are two factors which decide when an object may be evicted from memory: hibernatability and existence of clients.
 
-A Durable Object is considered hibernatable any time that it is not waiting for any I/O or callbacks that depend on the in-memory state. 
+A Durable Object is considered hibernatable any time that it is not waiting for any I/O or callbacks that depend on the in-memory state.
 
-- For example, if an object calls `fetch()` and awaits the response, it is considered to be waiting for I/O, and so cannot hibernate. 
+- For example, if an object calls `fetch()` and awaits the response, it is considered to be waiting for I/O, and so cannot hibernate.
 
-- Less obvious to a user, if an object calls `setTimeout()` to schedule a callback in the future - no matter how far in the future - then it is considered non-hibernatable, since there would be no way to recreate the callback after hibernating. 
+- Less obvious to a user, if an object calls `setTimeout()` to schedule a callback in the future - no matter how far in the future - then it is considered non-hibernatable, since there would be no way to recreate the callback after hibernating.
 
 - Additionally, if the Durable Object has received an incoming request and has not fully responded yet, then it cannot be hibernated, because hibernating would mean losing track of the async function which is eventually supposed to return a response to that request.
 
-- As an exception, a WebSocket request which has explicitly been accepted using the [WebSocket hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api allows a Durable Object to hibernate even while the WebSocket is still connected.
-
-
+- As an exception, a WebSocket request which has explicitly been accepted using the [WebSocket hibernation API](/durable-objects/best-practices/websockets/#websocket-hibernation-api) allows a Durable Object to hibernate even while the WebSocket is still connected.
 
-Once a Durable Object has been in a hibernatable state for 10 consecutive seconds, it hibernates, and duration billing stops.
+Duration billing stops once a Durable Object is in a hibernatable state. When a Durable Object has been in a hibernatable state for 10 consecutive seconds, it hibernates and gets evicted from memory.
+This time of 10s while being in a hibernatable state is not billed.
 
 Even if a Durable Object never becomes hibernatable, it will still be evicted once all clients have gone away. A Durable Object is considered to have clients if any other Worker currently holds a stub pointing to the Durable Object, or is waiting for a response from the Durable Object. An incoming WebSocket connection counts as a client. If the object is currently responding to an alarm event, this also counts as having a client. When not hibernatable, a Durable Object will be evicted from memory after it has had no client for 70-140 seconds (the exact interval varies). But again, if the object is hibernatable, then the 10-second hibernation timeout takes precedence and the 70-140 second no-client timeout is moot.

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

@@ -32,7 +32,7 @@ await durableObjectStub.cat(); // billed as a request
 
 <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.
 
-<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. It is recommended to use the WebSocket Hibernation API to avoid incurring duration charges once all event handlers finish running. Note that the Durable Object will remain active for 10 seconds after the last client disconnects. For a complete explanation, refer to [When does a Durable Object incur duration charges?](/durable-objects/platform/pricing/#when-does-a-durable-object-incur-duration-charges).
+<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. It is recommended to use the WebSocket Hibernation API to avoid incurring duration charges once all event handlers finish running. For a complete explanation, refer to [When does a Durable Object incur duration charges?](/durable-objects/platform/pricing/#when-does-a-durable-object-incur-duration-charges).
 
 <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.