callscript weekly downloads statistics

callscript

Code Mode, without the sandbox.

Experimental. callscript is a Vercel Labs project. APIs may change between releases.

The model writes JavaScript - and it never runs. Instead of calling tools one at a time, the model authors ONE small script in TypeScript and it compiles into an inert JSON plan: validated whole before anything runs (every issue reported at once), executed with bounded call counts, steps scheduled by data dependency. The only things that can execute are the tools you mounted.

Install

Two small runtime dependencies (acorn, zod), no sandbox, no service: the engine is a library that runs wherever your JS runs. The adapter's peer (ai) is optional and only needed by its own entrypoint.

Quick start

Mount your AI SDK tools on an engine and hand the model the ready-made tools - execute runs the script it authors; search and describe let it discover mounted tools without carrying every definition in its prompt:

Why

Classic tool calling has a shape problem: one call per model round-trip. Every intermediate result travels back through the context window just so the model can look at it and decide the next call: slow, token-expensive, and the plan lives nowhere you can inspect it.

Code Mode fixes this by having the model write real TypeScript that calls the tools, then executing that program. The insight is right: models are better at writing programs than at emitting tool-call chains, and intermediate data should flow between calls without a detour through the context. But the price is that you are now executing arbitrary LLM-authored code, so you need a sandbox: an isolate, a container, a worker. That is infrastructure to run, and a security boundary you must get exactly right.

callscript is Code Mode without the sandbox. The model still authors one program - in the JavaScript it already writes, with loops, branches, and dataflow - but nothing it writes ever executes as code: the script compiles into inert JSON with a pure expression subset. The only things that can execute are the tools you mounted. That one change buys the rest:

• No sandbox needed: there is no arbitrary code to contain. Expressions are a side-effect-free JS subset (no I/O, no globals, no imports), so the engine runs wherever your JS runs: serverless, edge, the same process as your app. • Statically checkable: because the plan is data, the whole thing validates before anything runs: unknown tools, misshaped args, unbound references, every issue reported at once. Arbitrary code can only fail at runtime, one error at a time. • Bounded by construction: fan-outs declare max and the engine enforces call limits; a runaway loop is a validation error, not an incident. • Serializable and resumable: a JSON plan plus a serializable record means runs can suspend (approval gates, external events) and resume with settled steps reused. Pausing arbitrary code mid-execution is famously hard. • Parallel for free: steps are scheduled by data dependency, so independent calls run concurrently without the model having to write Promise.all correctly. • Plain-value results: sandboxed code hands results back as logged text you parse afterwards; script steps return plain values the next step - and the host - reads directly. • Auditable: what will run and what ran are the same inert artifact: reviewable before execution, replayable after.

Expressions are a small language for pure transforms between calls, not general computation. If a step genuinely needs code, then you can have a code tool exposed to the agent.

The JS surface

The authoring format is the JavaScript the model already writes - so the entire language instruction (jsLanguageCard, what engine.describe() puts in the prompt) is one card of ~500 tokens, and the validator's pointed messages teach the rest on retry:

This is parsed, never executed: each statement compiles into a step of the same inert plan - const x = await tool(...) is a call step, const x = expr a pure derivation, if (cond) return v a guard, Promise.all(list.map(...)) a bounded fan-out (the visible slice is the bound), try/catch the error branch (e compiles to $errors.), and the trailing return the output projection. What is stored, hashed, validated, approved, and resumed is always the JSON plan; the JS text is a frontend, not a runtime.

Semantics match the JS reading: awaited calls run in statement order (the compiler inserts after edges where no data already orders them), and Promise.all - the spelling the model already knows for concurrency - runs calls in parallel. A call's second argument carries per-step options: github.closeIssue(args, { reason: "why", suspend: true, onError: "skip" }). An un-awaited call to a mounted tool detaches (fire-and-forget) and a later script joins it with const r = await job.

Everything outside the recognized grammar is rejected before anything runs, with the message that names the callscript spelling - while points at the bounded fan-out, reassignment at single-assignment consts, new Set at the dedupe idiom - so one retry converges:

Every door accepts both surfaces: a string is the JS surface, an object is the JSON plan. Engines default to teaching the JS surface (describe, toolDefinition, tools); pass format: "json" to teach the JSON plan instead - execution accepts both regardless.

The plan: three verbs, four modifiers

Under the surface, a script is one inert JSON plan: a list of steps wired by dataflow. Steps reference each other by id, and those references ARE the schedule - independent steps run concurrently, dependent ones wait for their inputs. Each step 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. • let - const x = expr - derives a value from earlier steps with a pure expression. • return - if (cond) return value - a guard clause: when it fires the run ends right there with that value; otherwise the run continues.…

Description from the npm listing.