Callscript: Code Mode, Without the Sandbox

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 - or, in Anthropic's writing, 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, the unused power is what forces the sandbox and keeps the code from being validated, bounded, or d.

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 d 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 hardmax

.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 s 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 likeMath ,JSON

, andDate

. - Promises. Every call is async; await

only decides whether the run blocks on it. A callwithoutawait

(const job = svc.export({...}) ) detaches and keeps running in the background, and a later script joins it withconst 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.

source & further reading

callscript.dev — original article