One Generation, a Hundred Tool Calls: Code Mode Moves Governance to the Bridge

Vercel’s AI SDK now ships Code Mode: the model writes JavaScript, the SDK executes it in a QuickJS sandbox, and that code calls your tools through a bridge. The default ceiling is 100 bridge requests per generation, with 10 allowed in flight at once. One generation, up to one hundred tool calls, and the human sees the code once, if at all. The feature is explicitly experimental, requires Node.js 22 or newer, and does not run in browser or edge runtimes. The governance implications are not experimental at all.

If your agent-control story is “a human approves each tool call,” Code Mode is where that story ends. Approval-per-call assumed the model emitted one structured call at a time and something could sit in the middle. Code Mode collapses the loop: iteration, branching, concurrency, and data transformation happen inside a single generated program. The unit of review stops being the call. It becomes the program, the bridge that program talks through, and the ceilings the runtime enforces.

We made the economic case for this pattern when Cloudflare argued that tool sprawl taxes every token. That argument is settled and we will not repeat it. What is new in August 2026 is that the pattern is a first-class SDK capability with a reviewable permission model. There is now a specific, enumerable control surface to govern. This essay enumerates it.

What the sandbox actually is

Each invocation gets a fresh QuickJS context. No Node globals, no filesystem access, no network fetch, no eval, no dynamic Function. Code that the model writes can compute, and it can call the bridge. Nothing else.

That sounds like the control. The docs say otherwise, verbatim: “Treat the sandbox as defense in depth. Generated code and tool arguments are untrusted.” Take that stance as an architecture statement from the vendor itself. The sandbox bounds what a runaway or hostile generation can do to the host. It says nothing about what a well-formed generation can do through the bridge, and the bridge is where your systems live.

This is the same layering we walked through in the five levels of bash containment: the execution cage is one surface, and the capabilities you hand into the cage are a different one. A perfect sandbox wrapping an over-provisioned bridge is a bank vault with a teller window that honors every withdrawal slip.

The three surfaces you now govern

Surface 1: what the bridge exposes. Tool exposure is governed by experimental_toolCallers. Each tool can be marked for direct invocation by the model, for invocation from generated code, or for both via DIRECT_TOOL_CALL. This is your allowlist, relocated. The question changes from “should the model see this tool” to “should generated code be able to loop over this tool a hundred times without a human between iterations.” Those are different questions. A send_email tool that was tolerable under per-call approval becomes a bulk mailer inside a for loop. A read-only lookup tool is probably fine on both paths. The audit is per tool, per path, and it is an audit nobody could have done before, because the second path did not exist.

Surface 2: the ceilings. The runtime enforces resource limits: maxBridgeRequests (default 100), maxInFlightBridgeRequests (default 10), plus timeout, memory, payload size, and console output limits. These defaults are the vendor’s guess about a reasonable workload. They are not your risk posture. A hundred bridged calls against an internal analytics API is a normal afternoon. A hundred bridged calls against a payment API is an incident. The ceilings are configuration, which means they are code, which means they can be reviewed, versioned, and set per deployment. Treat the default as a starting point you must consciously accept or lower, tool set by tool set.

Surface 3: authorization inside the tools. Since generated code and its arguments are untrusted, each tool must enforce its own authorization as if the caller were hostile. Validate arguments in the tool. Check the acting identity in the tool. Rate-limit and audit-log in the tool. Any check that lives only in the prompt, or only in the model’s good behavior, does not exist on this path. The bridge will deliver whatever the program sends, up to the ceiling, and the tool is the last party that can say no.

Notice what is absent from all three surfaces: a human. That is the design, and pretending otherwise wastes the pattern. The honest posture is to accept that approval moved from runtime to configuration time, then invest review effort where it now pays: in the tool caller declarations, the ceiling values, and the tool-side authorization code. All three are diffable artifacts in a pull request. Per-call approval never was.

What per-call governance loses, and what replaces it

Per-call approval gave you two things: a checkpoint before each side effect, and an audit trail that mapped one decision to one action. Code Mode takes the checkpoint. It does not have to take the trail. Bridge requests are still discrete, observable events; the runtime that enforces maxBridgeRequests is counting them, which means they can be logged with the generation that produced them. The reviewable unit becomes the generated program plus its bridge transcript. That is a better forensic artifact than a hundred isolated approval clicks, because it preserves intent: you can read the loop that produced the calls, not just the calls.

The loss is real at the edge, though. Under per-call approval, a bad generation costs one bad call. Under Code Mode, a bad generation costs up to maxBridgeRequests bad calls before anything intervenes. The ceiling is not an abstract tuning knob. It is your blast radius, stated as an integer, sitting in a config file. If your team has no written answer to “what is the largest number of tool invocations we accept from a single unreviewed model output,” Code Mode now demands one.

One caveat belongs in every plan built on this: the feature is experimental. The API surface carries the experimental_ prefix, and the ceilings, defaults, and caller semantics can change between releases. Govern the pattern now, but pin versions and re-audit on upgrade.

Do this now

Pick one agent you run, or plan to run, on the AI SDK. Before enabling Code Mode for it, write three lists. First, every tool, annotated with which invocation paths it should allow: direct, code, both, or neither. Second, the ceiling values you can defend to your own security review, with the default 100 treated as a proposal rather than a decision. Third, for each code-callable tool, the authorization checks that live inside the tool itself, assuming hostile arguments. If any list is hard to write, that difficulty is the audit finding. The bridge is about to become the busiest interface in your agent architecture. Govern it like one.

---

This analysis synthesizes Code Mode (AI SDK Core) (Vercel, AI SDK v7 documentation, August 2026).

Victorino Group helps engineering teams design the control surface for code-executing agents: bridge exposure, resource ceilings, and in-tool authorization. Let’s talk.