First, the plain definition.
In code mode, a model writes a short program that can call registered tools. The program can run several calls, inspect structured results, keep selected state, and return only the useful part to the model. That saves model turns and keeps bulky intermediate output out of the conversation.
Armin Ronacher describes Pi 1.0 doing this with JavaScript inside a restricted QuickJS and WebAssembly runtime. Pi's runtime has no direct network, filesystem, or timer access. It reaches the outside world through tools. Ronacher calls the trusted agent process the brain and the command target the hands.[1]
Code mode changes how calls are composed. It does not erase where each call runs.
The program is not the tool.
A generated JavaScript loop can live beside the model while a shell tool runs in a separate sandbox. An MCP call may reach a remote service. A function call may run in your application. OpenAI's programmatic tool-calling guide makes the same separation explicit. Its hosted runtime runs the generated JavaScript, while the application executes client-owned function calls. The guide says that orchestration does not change tool placement.[2]
This distinction controls security review. Do not ask only whether the code-mode runtime has network access. Ask which tools it can call, where those tools run, which credentials they use, and whether a retry can repeat a side effect.
Put policy on every call.
A program that can call ten tools has no ambient right to all ten. Give each tool an input schema, an output schema, a timeout, and an allowed caller. Validate arguments and permissions when the call arrives. Require application-level approval before an action changes inventory, sends a message, spends money, or edits production.
The MCP lifecycle offers a useful base rule. Client and server negotiate protocol versions and capabilities during initialization. Both sides must use only the capabilities they negotiated. Implementations should set request timeouts and stop waiting after a timeout, even if progress events can extend a shorter clock.[3]
Design the return path before the fast path.
Code mode can reduce context use by filtering intermediate output. That filter can also hide the event needed to diagnose a bad result. Save the program identity, tool calls, arguments after redaction, structured results, completion status, and final evidence. Keep these records outside polished prose.
Recovery needs one more decision. Mark calls as read-only, idempotent, or side-effecting. A read can repeat. An idempotent write can repeat under its contract. A side effect needs a receipt or reconciliation check before retry. The current Hacker News discussion keeps returning to this point through questions about trust separation, failed nested calls, lock-in, and interrupted execution.[4]
Run a matched road test.
Compare direct tool calls with code mode on the same work. Use representative inputs and the same tools. Measure final correctness, evidence coverage, latency, token use, call count, retries, and safety outcomes. OpenAI recommends this baseline-first comparison rather than assuming fewer model turns means a better result.[2]
CODE MODE ROAD TEST 1. Draw the harness host and execution host separately. 2. List every callable tool and its real execution location. 3. Mark each call read-only, idempotent, or side-effecting. 4. Require approval for high-impact calls. 5. Save program, nested calls, results, and completion state. 6. Interrupt one run after a side effect and reconcile it. 7. Compare direct calls and code mode on the same cases.