The most troubling result in my Code Mode experiment was a correct answer.
I used RaiseGate's existing read functions to compare direct MCP calls with a program written by the model and run through Cloudflare's Code Mode. Both used the same tools and data. Direct calling gave the model each result before it chose the next call. Code Mode let the model write JavaScript to make several calls and return a smaller answer.
In one test, I made a funding read fail temporarily. The Code Mode program caught the error and returned a funding count of zero. That company had no funding records in the test data. My first checker marked the answer correct.
Here is the relevant part of the program Gemini 3.5 Flash-Lite (gemini-3.5-flash-lite in the saved run) wrote, shortened and with the tool name generalized:
let fundingCount = 0;
try {
const result = await funding.read(name);
if (Array.isArray(result.data)) fundingCount = result.data.length;
} catch (e) {
// ignore or handle
}
return { funding_count: fundingCount };
The program had failed to read the records. Its zero matched the data by chance.
The saved trace shows the generated code, the failed read, and the returned zero. I have included a small reproduction of the same failure mechanism with the evidence for this article.
I almost turned that into a post about Code Mode being unreliable. That would have been a lazy conclusion. The failure came from a choice in the code Flash-Lite wrote. I repeated the task with Gemini 4 Argon (gemini-4-argon in the saved run). Its program retried the failed read. The trace showed a successful funding read after the retry. One stronger-model run cannot establish a reliability rate. It did show that model choice changed the behavior I was about to attribute to the architecture.
There was a real benefit to moving the work into code. On a single-company lookup, writing a program added overhead. On a six-company task with twelve reads, the program could make and combine calls while keeping most of the intermediate data out of the model's context. I completed one Argon direct/Code Mode pair for each of three tasks. In the six-company pair, total model tokens went from 5,051 with direct calls to 3,201 with Code Mode. An earlier attempt at that pair failed on a Vertex server error before yielding a comparable Code Mode result. This is a small observation from completed runs. It says little about production latency.
The part I keep coming back to is what happens to evidence when you make that move. In Code Mode, generated JavaScript handles tool results before they reach the model's context. That's often the point: the model doesn't need to read twelve raw responses if a short program can reduce them. A catch block can also turn a failed read into an apparently valid zero. The final answer may conceal the failure.
This is where the question moves beyond token efficiency. If I'm building something a founder will use to make a decision, a correct answer by accident can mislead them. The product has to know which sources it actually read. A failed read should leave the answer unverified, even when the returned value happens to be correct.
The first batch had 48 Flash-Lite runs: four tasks, each tested with direct calls and Code Mode, with and without a host retry policy, repeated three times. I counted a run as verified only when its returned fields matched the expected values and the trace showed a successful read for every required source. By that rule, 45 verified. All three failures were the unmodified Code Mode runs with an injected funding-read failure. Each swallowed the error and returned the expected zero without a successful funding read.
I then gave both paths the same host policy: retry only errors marked transient, at most twice after the first attempt. All three Code Mode failure runs verified with that policy. Direct calling already recovered in its three failure runs. With host retry, its median total model tokens fell from 6,863 to 3,892, while median model calls fell from three to two. Both medians are over three runs, so I wouldn't turn them into a general performance claim. They do show why I stopped judging the final JSON alone.
The host has to retain the few facts the generated program cannot be allowed to erase. Did the required read succeed? Was a fallback explicitly acceptable for this question? Did a retry actually recover the missing evidence? My trace audit caught the false zero that the output checker missed. A production version would need to enforce the distinction before an answer is treated as verified.
Code Mode called the same MCP tools in this setup. The useful choice was how much orchestration to delegate to a generated program, and which guarantees to keep outside it. For complicated retrieval, I would let the model choose an efficient path through the data. The host still needs proof that the required reads succeeded.
Experiment note: I used @cloudflare/codemode 0.5.5, its DynamicWorkerExecutor in local workerd, and MCP's in-memory transport. The reads queried a hosted database. The Argon follow-up comprised one completed direct/Code Mode pair for each of the single-company, six-company, and domain-resolution tasks, plus one Code Mode failure run with and without host retry. The sanitized trace and synthetic repro omit private data; full snapshots and transcripts remain private. As of 24 October 2026, Cloudflare's open draft PR #2609 proposes moving the existing Code Mode API into src/legacy and marking it feature-frozen. Its proposed src/legacy/index.ts exports DynamicWorkerExecutor; the PR's scope may change. This experiment tested the published 0.5.5 executor. The proposed WorkerJavaScriptBackend remains outside the scope of this experiment. These results describe this setup.