Cloudflare Code Mode is a pattern where the model writes a short JavaScript function and a sandbox runs it, instead of the model calling tools one by one through its context window. In the version most people saw the headline for, a vendor's MCP server exposes only two tools, search and execute. search runs model-written code against the vendor's OpenAPI document and returns whatever that code selected. execute runs model-written code that can call one authenticated request helper, and returns whatever that code returns. Cloudflare's own server uses this to expose over 2,500 endpoints for around 1,000 tokens of tool definitions.
That is the whole mechanism. The rest of this post is the detail you need before deciding whether to copy it, and the part the headline leaves out: what it does not give your customer's agent.
Two things share the name
There are two Code Modes, and they sit on opposite sides of the wire.
Caller-side, September 2025. The original Code Mode post is aimed at people building agents. Their SDK converts every tool on the agent's connected MCP servers into a TypeScript API, the model writes a script against it, and the script runs in a Workers isolate the agent builder hosts. Only the return value enters context. In Cloudflare's words: "LLMs are better at writing code to call MCP, than at calling MCP directly." Nothing changes for the vendor on the other end. Anthropic published the same idea as code execution with MCP.
Vendor-side, February 2026. The Code Mode MCP server post moves the pattern to the vendor. Cloudflare rebuilt its own API MCP server so that it advertises two tools instead of thousands. The agent on the other end does not need a code sandbox of its own; the sandbox lives on the vendor's Worker. Cloudflare then documented the pattern and shipped a guide so any vendor with an OpenAPI 3.x document can do the same with openApiMcpServer() from the @cloudflare/codemode package.
If you are a software company asking "should we copy this," the second one is the one you would copy, so that is the one I will take apart.
What search takes and returns
search is not a keyword search. It takes a JavaScript function the model wrote. That function gets a codemode.spec() call that returns the vendor's full OpenAPI document as an object, with every $ref already resolved inline. The function filters the document however it likes and returns whatever it selected. That return value is the tool result.
Adapted from Cloudflare's guide, a search the model might write to find order endpoints looks like this:
async () => {
const spec = await codemode.spec();
return Object.entries(spec.paths)
.filter(([path]) => path.includes("/orders"))
.map(([path, operations]) => ({
path,
methods: Object.keys(operations),
}));
};The OpenAPI document never enters the model's context. The model sees only what its own code returned: a few paths and their methods. If it needs a request body schema next, it writes another search that drills into one operation and returns just that. Cloudflare's tool description is one line: "Search the Cloudflare OpenAPI spec. All $refs are pre-resolved inline."
What execute takes and what it can call
execute also takes a JavaScript function the model wrote. Inside the sandbox, that function has exactly one way to reach the outside world: codemode.request({ method, path, query, body }). That helper is provided by the host Worker, and it is plain REST underneath. The model composes calls, loops over pages, checks responses, and returns a focused result.
Again adapted from the guide:
async () => {
const response = await codemode.request({
method: "GET",
path: "/orders",
query: { status: "processing", limit: 20 },
});
return response.items.map(({ id, status }) => ({ id, status }));
};Twenty orders come back from the API. Twenty pairs of id and status reach the model. Everything else stays in the sandbox and is gone when the isolate exits. Cloudflare's post says the agent's code "can make Cloudflare API requests, handle pagination, check responses, and chain operations together in a single execution."
Where the auth lives
The bearer token never goes into the sandbox. In the guide's reference server, the host Worker reads the Authorization header from the incoming MCP request, and the request callback the host defines attaches that header to every outbound API call. Model-written code calls codemode.request(...) and never sees a credential. Cloudflare's guide: "The token never enters the sandbox."
The sandbox itself is a Dynamic Worker isolate created per execution. Per Cloudflare, it has "no file system, no environment variables to leak through prompt injection and external fetches disabled by default." Direct fetch() and connect() are blocked unless the host opts in. So a prompt injection that talks the model into writing fetch("https://evil.example") fails at the network layer.
One more line from the docs that matters more than it looks: "Code execution does not replace authorization." Permission checks belong in the host request callback or the upstream API. Code Mode moves the model's request to a sandbox. It does not decide what the caller is allowed to do.
Why it saves tokens
Two reasons, and it helps to keep them separate.
Schemas never enter context. A conventional MCP server puts every tool's name, description, and JSON schema into the model's context on every turn. For a real product API that is dozens or hundreds of definitions. Cloudflare's number for its own API is that an equivalent server without Code Mode "would consume 1.17 million tokens." With search and execute, the model carries two tool definitions and pulls in a few operations at a time, only when its own code asks for them.
Intermediate results never enter context. With normal tool calling, as the original post puts it, "the output of each tool call must feed into the LLM's neural network, just to be copied over to the inputs of the next call." List a thousand records, filter to ten, look up each one: all thousand pass through the model. With execute, the loop runs in the sandbox and the model reads ten results.
The first reason is why the headline says 1,000 tokens. The second is why the pattern helps on multi-step jobs even when the API is small; Anthropic's 150,000-to-2,000-token workflow is mostly the second reason at work.
What it is great at
I want to be plain about this because the rest of the post is a turn, and the turn is not "this does not work."
It works. If your API is large, this is the cheapest published way to expose all of it to an agent, and the token math holds no matter how many endpoints you add. Discovery becomes progressive, which suits the 30-to-50-tool accuracy cliff better than any static list. Chained reads, pagination, and filtering stop costing a round trip each. The sandbox is sound and the auth boundary is in the right place. And Cloudflare gave it away, so the price of the transport is a Worker and an OpenAPI document you probably already have.
If a customer's coding agent needs a corner of your API you never wrote a tool for, this is how it gets there without you building anything specific. That is a good property.
What it actually is
Now the turn. Read the two examples above again and notice what they are.
They are your public REST API, wrapped so the caller's model can write a fresh program against it on every request. The agent gets exactly what a developer with your API docs and a bearer token gets, at a fraction of the token cost. That is the achievement, and it is also the limit.
There is no notion of an outcome. execute does not know that the twenty orders were fetched to build a reorder forecast. It ran a function and returned a list.
There is no guarantee. The code is written fresh, by someone else's model, every time. It was not tested against your product. When the model's script is wrong, the sandbox returns an error, and nobody on your side knows a customer just failed to get a forecast.
There is no price. Cloudflare's server bills nobody. There is no catalog, no entitlement, no record that this caller is allowed this much of this thing. The API key's scopes are the only limit, and those were designed for developers, not for an agent acting for a customer who cannot read the code it wrote.
There is no run when nobody is calling. The sandbox exists for one execution and is gone. A job that should run every Monday, or when a shipment goes late, has nowhere to live.
And there is no data the API does not expose. codemode.spec() returns your OpenAPI document. If the useful signal for a customer is something you compute across tenants, or hold in an internal system, or never shipped as an endpoint, search will not find it and execute cannot fetch it.
Cloudflare did not build these things because it was not trying to. The goal was to make an existing API reachable, cheaply and safely, by any agent. It did that. The question for a software company is what you build on top.
What a vendor decides on top of it
Transport is going to zero. Cloudflare gave code mode away; a CLI generator costs a spec; MCP is a weekend. None of them is a business. What remains is deciding which outcomes you design, guarantee, and sell, and four ingredients a buyer's agent cannot get by writing better code against your public API:
- Privileged data. Anything you know across customers or hold in systems the API never exposed. Only you can compute the benchmark.
- Write authority with accountability. You will not hand an arbitrary agent full headless control of writes. Outcomes with side effects will exist as jobs you sanctioned, with limits, an allowlist of what they may touch, and a run log.
- Residency. The customer's agent is not running at 3am. Scheduled and event-triggered work needs a runtime on your side.
- Amortized reliability. A job designed once and run thousands of times on the cheapest model that passes. This one erodes as models improve, so it should never be the only reason.
I covered how this changed our own product in Too Many MCP Tools Makes Your Agent Worse, so I will not retell it. The short form: keep the primitives cheap, by code mode or whatever comes next, and put named outcomes on top of them that you stand behind.
Where Aimdoc fits
Aimdoc runs one customer agent for a software product, on the website, inside the app, over email, and through a public gateway other agents can call. It connects to the product's MCP server, and every call runs as the signed-in customer with their permissions. On top of that, a service is a named outcome the vendor defines: inputs, the tools it may use, limits, the identity it runs as, who is entitled to it, an optional price charged through the vendor's own Stripe account, delivery to the app, email, Slack, or a webhook, and runs on a schedule or on a product event. If your product's MCP server is a Code Mode server, that is fine; a service is what you build above it. The free tier is 10,000 credits with no credit card.
The short version
search is model-written code that filters your OpenAPI document and returns what it picked. execute is model-written code with one authenticated request helper, plain REST underneath. Schemas and intermediate results never enter the model's context, and the credential never enters the sandbox.
Copy it if your API is big and you want every corner of it reachable. Then decide, separately, which outcomes you will design, guarantee, and sell. Code Mode makes your primitives cheap to reach. It does not turn them into a product.