Interface: CodeRunner

A service that runs code in an isolated session — a managed code interpreter, a container pool, a subprocess.

The shape is Start → Execute ×N → Stop, because that is what every real one is, and the middle is the part a framework has to make possible. Paying session start-up on every call is the honest cheap version; holding the session in a module-level map is the fast version that hands one live sandbox to whoever calls next. ctx.onTeardown + ToolExecutionContext.runId are what let a tool do neither.

── Why this port exists at all: "summarize prose, compute data" ──────────── A tool that returns 40MB of rows does not need a bigger context window; it needs to not put the rows in one. The motivating failure is a real production request of 879,073 tokens — a tool result pasted straight into the prompt. With a code runner, the model writes the aggregation, the RUNNER holds the data, and what comes back is the answer. Prose gets summarized; data gets computed. CodeResult.truncated exists so the second half of that promise cannot quietly break.

Implement it for your own backend; ship it to codeRunnerTool({ runner }).