More tweaks.

Author: kentonv

src/content/changelog/workers/2025-09-26-ctx-exports.md

@@ -6,6 +6,25 @@ date: 2025-09-26
 
 The [`ctx.exports` API](/workers/runtime-apis/context/#exports) contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extending `WorkerEntrypoint`, `ctx.exports` will contain a [Service Binding](/workers/runtime-apis/bindings/service-bindings) by the same name, and for each export extending `DurableObject` (and for which storage has been configured via a [migration](/durable-objects/reference/durable-objects-migrations/)), `ctx.exports` will contain a [Durable Object namespace binding](/durable-objects/api/namespace/). This means you no longer have to configure these bindings explicitly in `wrangler.jsonc`/`wrangler.toml`.
 
+Example:
+
+```js
+import { WorkerEntrypoint } from "cloudflare:workers";
+
+export class Greeter extends WorkerEntrypoint {
+  greet(name) {
+    return `Hello, ${name}!`;
+  }
+}
+
+export default {
+  async fetch(request, env, ctx) {
+    let greeting = await ctx.exports.Greeter.greet("World")
+    return new Response(greeting);
+  }
+}
+```
+
 At present, you must use [the `enable_ctx_exports` compatibility flag](/workers/configuration/compatibility-flags#enable-ctxexports) to enable this API, though it will be on by default in the future.
 
 [See the API reference for more information.](/workers/runtime-apis/context/#exports)

src/content/docs/workers/runtime-apis/bindings/worker-loader.mdx

@@ -98,11 +98,11 @@ binding = "LOADER"
 
 <code>get(id <Type text="string" />, getCodeCallback <Type text="() => Promise<WorkerCode>" />): <Type text="WorkerStub" /></code>
 
-Loads a Worker with the given ID.
+Loads a Worker with the given ID, returning a `WorkerStub` which may be used to invoke the Worker.
 
-As a convenience, the loader implements basic caching of isolates: If this loader has already been used to load a Worker with the same ID in the past, and that Worker's isolate is still resident in memory, then the existing Worker will be returned, and the callback will not be called. When an isolate has not been used in a while, the system will discard it automatically, and then the next attempt to get the same ID will have to load it again. If you frequently run the same code, you should use the same ID in order to get automatic caching. On the other hand, if the code you load is different every time, you can provide a random ID. Note that if your code has many versions, each version will need a unique ID, as there is no way to explicitly evict a previous version.
+As a convenience, the loader implements basic caching of isolates: If this loader has already been used to load a Worker with the same ID in the past, and that Worker's isolate is still resident in memory, then the existing Worker will be returned, and the callback will not be called. When an isolate has not been used in a while, the system will discard it automatically, and then the next attempt to get the same ID will have to start a new isolate. If you frequently run the same code, you should use the same ID in order to get automatic caching. On the other hand, if the code you load is different every time, you can provide a random ID. Note that if your code has many versions, each version will need a unique ID, as there is no way to explicitly evict a previous version. Note also that you should never rely on an isolate already being in memory; if two requests MUST use the same isolate, then you need to make those requests using the same `WorkerStub` (i.e. only call `loader.get()` once).
 
-If the system opts not to reuse an existing Worker, then it invokes `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).
+If the system opts not to reuse an existing isolate, then it invokes `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).
 
 `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.