Style and structure fixes across 9 files

Co-authored-by: elithrar <elithrar@users.noreply.github.com>

Author: ask-bonk[bot]

src/content/docs/dynamic-workers/api-reference.mdx

@@ -10,65 +10,65 @@ products:
 
 import { Type, MetaInfo } from "~/components";
 
-This page describes the Worker Loader binding API, assuming you have [configured such a binding](/dynamic-workers/getting-started/#configure-worker-loader) as `env.LOADER`.
+This page describes the Worker Loader binding API, assuming you have [configured a binding](/dynamic-workers/getting-started/#configure-worker-loader) as `env.LOADER`.
 
-### `load`
+## `load`
 
 <code>env.LOADER.load(code <Type text="WorkerCode" />) <Type text="WorkerStub" /></code>
 
 Loads a Worker from the provided `WorkerCode` and returns a `WorkerStub` which may be used to invoke the Worker.
 
-Unlike `get()`, `load()` does not cache by ID. Each call creates a fresh Worker.
+Unlike `get()`, `load()` does not cache by ID. Each call creates a new Worker.
 
-Use `load()` when the code is always new, such as for one-off AI-generated tool calls.
+Use `load()` when the code is always new, such as for one-time AI-generated tool calls.
 
-### `get`
+## `get`
 
 <code>env.LOADER.get(id <Type text="string" />, getCodeCallback <Type text="() => Promise<WorkerCode>" />): <Type text="WorkerStub" /></code>
 
 Loads a Worker with the given ID, returning a `WorkerStub` which may be used to invoke the Worker.
 
-As a convenience, the loader implements caching of isolates. When a new ID is seen the first time, a new isolate is loaded. But, the isolate may be kept warm in memory for a while. If later invocations of the loader request the same ID, the existing isolate may be returned again, rather than create a new one. But there is no guarantee: a later call with the same ID may instead start a new isolate from scratch.
+The loader caches isolates by ID. When the loader sees an ID for the first time, it creates a new isolate. The isolate may stay warm in memory for subsequent requests. If a later call uses the same ID, the runtime may return the existing isolate instead of creating a new one. However, there is no guarantee &mdash; a later call with the same ID may start a new isolate from scratch.
 
-Whenever the system determines it needs to start a new isolate, and it does not already have a copy of the code cached, it will invoke `codeCallback` to get the Worker's code. This is an async callback, so the application can load the code from remote storage if desired. The callback returns a `WorkerCode` object (described below).
+When the runtime needs to start a new isolate and does not have a cached copy of the code, it invokes `codeCallback` to get the Worker code. This is an async callback, so the application can load the code from remote storage if needed. The callback returns a `WorkerCode` object (described below).
 
-Because of the caching, you should ensure that the callback always returns exactly the same content, when called for the same ID. If anything about the content changes, you must use a new ID. But if the content hasn't changed, it's best to reuse the same ID in order to take advantage of caching. If the `WorkerCode` is different every time, you can pass a random ID.
+Because of caching, ensure that the callback always returns exactly the same content for the same ID. If anything about the content changes, you must use a new ID. If the content has not changed, reuse the same ID to take advantage of caching. If the `WorkerCode` is different every time, pass a random ID.
 
-You could, for example, use IDs of the form `<worker-name>:<version-number>`, where the version number increments every time the code changes. Or, you could compute IDs based on a hash of the code and config, so that any change results in a new ID.
+For example, use IDs of the form `<worker-name>:<version-number>`, where the version number increments every time the code changes. Alternatively, compute IDs based on a hash of the code and config so that any change produces a new ID.
 
-`get()` returns a `WorkerStub`, which can be used to send requests to the loaded Worker. Note that the stub is returned synchronously&mdash;you do not have to await it. If the Worker is not loaded yet, requests made to the stub will wait for the Worker to load before being delivered. If loading fails, the request will throw an exception.
+`get()` returns a `WorkerStub`, which you can use to send requests to the loaded Worker. The stub is returned synchronously &mdash; you do not have to await it. If the Worker is not loaded yet, requests made to the stub wait for the Worker to load before being delivered. If loading fails, the request throws an exception.
 
-It is never guaranteed that two requests will go to the same isolate. Even if you use the same `WorkerStub` to make multiple requests, they could execute in different isolates. The callback passed to `loader.get()` could be called any number of times (although it is unusual for it to be called more than once).
+Two requests are never guaranteed to reach the same isolate. Even if you use the same `WorkerStub` to make multiple requests, they could execute in different isolates. The callback passed to `loader.get()` could run any number of times, although it is unusual for it to run more than once.
 
-### `WorkerCode`
+## `WorkerCode`
 
 This is the structure returned by `getCodeCallback` to represent a worker.
 
-#### <code>compatibilityDate <Type text="string" /></code>
+### <code>compatibilityDate <Type text="string" /></code>
 
 The [compatibility date](/workers/configuration/compatibility-dates/) for the Worker. This has the same meaning as the `compatibility_date` setting in a Wrangler config file.
 
-#### <code>compatibilityFlags <Type text="string[]" /> <MetaInfo text='Optional' /></code>
+### <code>compatibilityFlags <Type text="string[]" /> <MetaInfo text='Optional' /></code>
 
 An optional list of [compatibility flags](/workers/configuration/compatibility-flags) augmenting the compatibility date. This has the same meaning as the `compatibility_flags` setting in a Wrangler config file.
 
-#### <code>allowExperimental <Type text="boolean" /> <MetaInfo text='Optional' /></code>
+### <code>allowExperimental <Type text="boolean" /> <MetaInfo text='Optional' /></code>
 
-If true, then experimental compatibility flags will be permitted in `compatibilityFlags`. In order to set this, the worker calling the loader must itself have the compatibility flag `"experimental"` set. Experimental flags cannot be enabled in production.
+If true, experimental compatibility flags are permitted in `compatibilityFlags`. To set this, the Worker calling the loader must itself have the `"experimental"` compatibility flag set. Experimental flags cannot be used in production.
 
-#### <code>mainModule <Type text="string" /></code>
+### <code>mainModule <Type text="string" /></code>
 
 The name of the Worker's main module. This must be one of the modules listed in `modules`.
 
-#### <code>modules <Type text="Record<string, string | Module>"/></code>
+### <code>modules <Type text="Record&lt;string, string | Module&gt;"/></code>
 
-A dictionary object mapping module names to their string contents. If the module content is a plain string, then the module name must have a file extension indicating its type: either `.js` or `.py`.
+A dictionary object mapping module names to their string contents. If the module content is a plain string, the module name must have a file extension indicating its type: either `.js` or `.py`.
 
-A module's content can also be specified as an object, in order to specify its type independent from the name. The allowed objects are:
+You can also specify a module's content as an object to set its type independent of the name. The allowed objects are:
 
 - `{js: string}`: A JavaScript module, using ES modules syntax for imports and exports.
 - `{cjs: string}`: A CommonJS module, using `require()` syntax for imports.
-- `{py: string}`: A [Python module](/workers/languages/python/). See warning below.
+- `{py: string}`: A [Python module](/workers/languages/python/). Refer to the warning below.
 - `{text: string}`: An importable string value.
 - `{data: ArrayBuffer}`: An importable `ArrayBuffer` value.
 - `{json: object}`: An importable object. The value must be JSON-serializable. However, note that value is provided as a parsed object, and is delivered as a parsed object; neither side actually sees the JSON serialization.
@@ -79,17 +79,17 @@ While Dynamic Workers support Python, Python Workers are currently much slower t
 
 :::
 
-#### <code>globalOutbound <Type text="ServiceStub | null" /> <MetaInfo text='Optional' /></code>
+### <code>globalOutbound <Type text="ServiceStub | null" /> <MetaInfo text='Optional' /></code>
 
 Controls whether the dynamic Worker has access to the network. The global `fetch()` and `connect()` functions (for making HTTP requests and TCP connections, respectively) can be blocked or redirected to isolate the Worker.
 
-If `globalOutbound` is not specified, the default is to inherit the parent's network access, which usually means the dynamic Worker will have full access to the public Internet.
+If `globalOutbound` is not specified, the default is to inherit the parent's network access, which usually means the dynamic Worker has full access to the public internet.
 
-If `globalOutbound` is `null`, then the dynamic Worker will be totally cut off from the network. Both `fetch()` and `connect()` will throw exceptions.
+If `globalOutbound` is `null`, the dynamic Worker is fully cut off from the network. Both `fetch()` and `connect()` throw exceptions.
 
-`globalOutbound` can also be set to any service binding, including service bindings in the parent worker's `env` as well as [loopback bindings from `ctx.exports`](/workers/runtime-apis/context/#exports).
+You can also set `globalOutbound` to any service binding, including service bindings in the parent Worker's `env` and [loopback bindings from `ctx.exports`](/workers/runtime-apis/context/#exports).
 
-Using `ctx.exports` is particularly useful as it allows you to customize the binding further for the specific sandbox, by setting the value of `ctx.props` that should be passed back to it. The `props` can contain information to identify the specific dynamic Worker that made the request.
+Using `ctx.exports` is particularly useful because it lets you customize the binding for a specific sandbox by setting the value of `ctx.props` that is passed back to it. The `props` can contain information to identify the specific dynamic Worker that made the request.
 
 For example:
 
@@ -120,13 +120,13 @@ export default {
 };
 ```
 
-#### <code>env <Type text="object" /></code>
+### <code>env <Type text="object" /></code>
 
 The environment object to provide to the dynamic Worker.
 
 Using this, you can provide custom bindings to the Worker.
 
-`env` is serialized and transferred into the dynamic Worker, where it is used directly as the value of `env` there. It may contain:
+`env` is serialized and transferred into the dynamic Worker, where it becomes the value of `env`. It may contain:
 
 - [Structured clonable types](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm).
 - [Service Bindings](/workers/runtime-apis/bindings/service-bindings), including [loopback bindings from `ctx.exports`](/workers/runtime-apis/context/#exports).
@@ -164,9 +164,9 @@ export default {
 };
 ```
 
-#### <code>tails <Type text="ServiceStub[]" /> <MetaInfo text='Optional' /></code>
+### <code>tails <Type text="ServiceStub[]" /> <MetaInfo text='Optional' /></code>
 
-You may specify one or more [Tail Workers](/workers/observability/logs/tail-workers/) which will observe console logs, errors, and other details about the dynamically-loaded worker's execution. A tail event will be delivered to the Tail Worker upon completion of a request to the dynamically-loaded Worker. As always, you can implement the Tail Worker as an alternative entrypoint in your parent Worker, referring to it using `ctx.exports`:
+Specify one or more [Tail Workers](/workers/observability/logs/tail-workers/) to observe console logs, errors, and other details about the dynamically-loaded Worker's execution. A tail event is delivered to the Tail Worker when a request to the dynamically-loaded Worker completes. You can implement the Tail Worker as an alternative entrypoint in your parent Worker, referencing it with `ctx.exports`:
 
 ```js
 import { WorkerEntrypoint } from "cloudflare:workers";

src/content/docs/dynamic-workers/examples/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Examples
-description: See common Dynamic Workers patterns for code execution and sandboxing.
+description: Common Dynamic Workers patterns for code execution and sandboxing.
 pcx_content_type: navigation
 sidebar:
   order: 4

src/content/docs/dynamic-workers/getting-started.mdx

@@ -19,36 +19,31 @@ Dynamic Workers support two loading modes:
 
 `load()` is best for one-time code execution, for example when using [Codemode](/agents/api-reference/codemode/). `get(id, callback)` is better when the same code will receive subsequent requests, for example when you are building applications.
 
-### Try it out
+## Try it out
 
-#### Dynamic Workers Starter
+### Dynamic Workers Starter
 
 [![Deploy to Workers](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers)
 
 Use this "hello world" [starter](https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers) to get a Worker deployed that can load and execute Dynamic Workers.
 
-#### Dynamic Workers Playground
+### Dynamic Workers Playground
 
 [![Deploy to Workers](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers-playground)
 
 You can also deploy the [Dynamic Workers Playground](https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers-playground), where you can write or import code, bundle it at runtime with `@cloudflare/worker-bundler`, execute it through a Dynamic Worker, and see real-time responses and execution logs.
 
 ## Configure Worker Loader
 
-In order for a Worker to be able to create Dynamic Workers, it needs a Worker Loader binding. Unlike most Workers bindings, this binding doesn't point at any external resource in particular; it simply provides access to the Worker Loader API.
+For a Worker to create Dynamic Workers, it needs a Worker Loader binding. Unlike most Workers bindings, this binding does not point at any external resource. It provides access to the Worker Loader API.
 
-Configure it like so, in your Worker's `wrangler.jsonc`:
+Add the following to your Worker's Wrangler configuration:
 
 <WranglerConfig>
 
-```jsonc
-{
-	"worker_loaders": [
-		{
-			"binding": "LOADER",
-		},
-	],
-}
+```toml
+[[worker_loaders]]
+binding = "LOADER"
 ```
 
 </WranglerConfig>
@@ -101,9 +96,9 @@ In this example, `env.LOADER.load()` creates a Dynamic Worker from the code defi
 
 ### Reusing a Dynamic Worker across requests
 
-If you expect to load the exact same Worker more than once, use [`get(id, callback)`](/dynamic-workers/api-reference/#get) instead of `load()`. The `id` should be a unique string identifying the particular code you intend to load. When the runtime sees the same `id` again, it can reuse the existing Worker instead of creating a new one, if it hasn't been evicted yet.
+If you expect to load the exact same Worker more than once, use [`get(id, callback)`](/dynamic-workers/api-reference/#get) instead of `load()`. The `id` should be a unique string identifying the particular code you intend to load. When the runtime sees the same `id` again, it can reuse the existing Worker instead of creating a new one, if it has not been evicted yet.
 
-The callback you provide will only be called if the Worker is not already loaded. This lets you skip loading the code from storage when the Worker is already running.
+The callback you provide only runs if the Worker is not already loaded. This lets you skip loading the code from storage when the Worker is already running.
 
 <TypeScriptExample>
 
@@ -157,7 +152,7 @@ const worker = env.LOADER.get("my-worker", async () => {
 		},
 	});
 
-	return { mainModule, modules, compatibilityDate: "2026-01-01" };
+	return { mainModule, modules, compatibilityDate: "$today" };
 });
 ```
 

src/content/docs/dynamic-workers/index.mdx

@@ -16,19 +16,19 @@ Spin up Workers at runtime to execute code on-demand in a secure, sandboxed envi
 
 </Description>
 
-Dynamic Workers let you spin up an unlimited number of Workers to execute arbitrary code specified at runtime. Dynamic Workers can be used as a lightweight alternative to containers for securely sandboxing code you don't trust.
+Dynamic Workers let you spin up an unlimited number of Workers to execute arbitrary code specified at runtime. Use Dynamic Workers as a lightweight alternative to containers for securely sandboxing code you do not trust.
 
 Dynamic Workers are the lowest-level primitive for spinning up a Worker, giving you full control over defining how the Worker is composed, which bindings it receives, whether it can reach the network, and more.
 
-### Get started
+## Get started
 
 Deploy the [Dynamic Workers Playground](https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers-playground) to create and run Workers dynamically from code you write or import from GitHub, with real-time logs and observability.
 
 [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/dinasaur404/dynamic-workers-playground)
 
-## Use Dynamic Workers for
+## Use cases
 
-Use this pattern when code needs to run quickly in a secure, isolated environment.
+Use Dynamic Workers when code needs to run quickly in a secure, isolated environment.
 
 - **AI Agent "Code Mode"**: LLMs are trained to write code. Instead of supplying an agent with tool calls to perform tasks, give it an API and let it write and execute code. Save up to 80% in inference tokens and cost by allowing the agent to programmatically process data instead of sending it all through the LLM.
 - **AI-generated applications / "Vibe Code"**: Run generated code for prototypes, projects, and automations in a secure, isolated sandboxed environment.