Callscript: Code Mode, Without the Sandbox

CallScript, a new tool-calling language for LLMs, compiles a subset of JavaScript into an inert JSON plan instead of executing it, eliminating the need for a sandbox while preserving the benefits of code mode. The language, which parses statements into steps that reference each other by id, allows plans to be approved deterministically, stored, and resumed later, and supports concurrent execution via Promise.all. CallScript mounts tools via adapters like the AI SDK and MCP, and provides search and describe functions for tool discovery.

CallScript Code Mode, without the sandbox. A tool-calling language for LLMs. The model writes a subset of JavaScript - CallScript parses it into a JSON plan instead of executing it. Plans can be approved deterministically, stored, and resumed later, and steps reference earlier results by id. compiles to why Say you have two GitHub tools mounted - listIssues , which returns the first 100 issues of a repo, and closeIssue , which closes one issue by number - and you prompt the agent: "close stale issues". With plain tool calling, every listIssues call lands all 100 issues in the agent's context. To pick the stale ones it has to read them; to close them it has to generate tokens for each closeIssue call - and so on, one round-trip at a time. That is slow, costs tokens, no way to see the full set of calls ahead of time, judgments like "stale" are made mid-run and so on.. Code Mode https://developers.cloudflare.com/agents/tools/codemode/ - or, in Anthropic's writing, code execution with MCP https://www.anthropic.com/engineering/code-execution-with-mcp - solves this by giving the model type definitions for the tools and letting it write a TypeScript program against them: models are better at writing programs than at emitting tool-call chains, and results flow between calls without going back through the model. But code mode introduces its own complexity - from Anthropic's: Note that code execution introduces its own complexity. Running agent-generated code requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid. The benefits of code execution—reduced token costs, lower latency, and improved tool composition—should be weighed against these implementation costs. But calling tools and APIs shouldn't need a Turing-complete language. By the rule of least power https://en.wikipedia.org/wiki/Rule of least power , the unused power is what forces the sandbox and keeps the code from being validated, bounded, or paused. the script CallScript keeps the parts of JavaScript the job needs - calls, dataflow, branches, bounded fan-outs - and compiles them to inert data before anything executes. The benefits stay and the infrastructure goes: a plan and its state are plain data, so a run stores anywhere, resumes later, and takes new input when it does. The agent answers the same prompt by writing one small JavaScript program: callscript never executes it - each statement compiles into one step of an inert JSON plan: Steps reference each other by id, and those references are the schedule: independent steps run concurrently, dependent ones wait. Awaited calls keep statement order, and Promise.all runs calls in parallel. usage Mount your tools on callscript and hand the model the ready-made tools - execute , search , and describe : tool definitions In callscript, a tool is anything an executor can evaluate. Executors come from adapters - the AI SDK, MCP, and others - and the default executor evaluates a plain object: { name, execute } plus an optional schema and description: function signatures callscript turns each tool definition into a function signature: one card with the signature line, the description, and any declared error codes. search Tools are meant to be discovered: search finds mounted tools by keyword and returns names with one-line summaries, and describe returns the full signature cards for the names a script will use. You pick the exposure. Append every card into the prompt when the toolset is small; or list only names and short descriptions and let the agent describe the ones it needs - no searching to discover - or expose nothing inline and let it search first, so the prompt stays the same size however many tools you mount. execute is the third tool of the pair - the one that acts, running the script the model authored. serializability An execution of a callscript is data all the way down: the plan, every settled step, and the point where it stopped all serialize into one plain record. You can flag a risky call for approval, park a run on an external event, or leave a long job running and join it from a later script: which compiles to the plan step: The paused run comes back as a plain state record that can be stored in memory or as a KV entry; when the answer arrives, execution continues from the serialized record - settled steps reused, not re-run. typed authoring cs.script {...} and cs.tool ... are typed against the mounted tools: call autocompletes to mounted tool names and args to that tool's input, so a typo'd name is a type error before it is a validation error. Every expression position takes the string form or a real JS arrow, transpiled - never executed - into the string at the door: The arrow's parameter names everything the body reads; a free name - including a captured outer variable, the thing a native closure could smuggle in - is rejected at the door. What's stored, hashed, and re-executed is always the string form, so the script stays inert data. reference Each step of a plan is one of three verbs: call - const x = await tool.name {...} - invokes a mounted tool; its args validate against the tool's schema before it fires. A second argument carries per-call options: { reason, suspend, onError } . let - const x = expr - derives a value from earlier steps with a pure expression. return - if cond return value - is a guard clause: when it fires the run ends right there with that value; otherwise the run continues. And a step can carry modifiers: if skips the step unless a condition holds. each fans a call out over a list, one dispatch per element, bounded by a hard max . after orders a step behind earlier ones when no data flows between them - close the issues, then post the summary. suspend flags a call for confirmation: the run pauses there until a human approves it. A few more things the language gives you: - Globals. Expressions read earlier steps by id, input data passed to this execution , variables published by earlier runs in the session, $errors.stepId for recorded failures, and safe built-ins like Math , JSON , and Date . - Promises. Every call is async; await only decides whether the run blocks on it. A call without await const job = svc.export {...} detaches and keeps running in the background, and a later script joins it with const r = await job . - Expressions. A side-effect-free subset of JS: arrows, template literals, ternaries, optional chaining - no I/O, no imports, no reaching outside the script's scope. - Output. output projects the run's final result from any settled step; by default it is the last step's value. - Validation. The whole plan is checked before anything runs - unknown tools, misshaped args, unbound references, all reported at once - and hard limits cap steps, total calls, and concurrency.