Programmatic tool calling goes default in Droid 1.0: one program, hundreds of tool calls, and a new allowed_callers decision

The standard agent loop has a fixed rhythm: the model emits a tool call, the result lands in its context window, and the next call costs a fresh request that re-sends the instructions and the whole history. On October 29, Factory shipped Droid 1.0 with that loop replaced by default. The model writes a JavaScript program, the program chains the tool calls, and the model only sees what the program prints.

Factory calls this programmatic tool calling. If you maintain agent configs, the name matters more than the product. OpenAI and Anthropic both ship the same pattern as a documented API feature, and both expose it through a config field called allowed_callers. That field is arriving in your config files whether or not you ever run Droid.

What shipped on October 29

Droid is Factory's agent harness: the prompts, the tools, how results come back, and the loop that runs it all. Droid 1.0 is their largest update so far, and its core change is programmatic tool calling (PTC) enabled by default for ten models: GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, GPT-5.6 Sol, Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, and Kimi K3.

The implementation is a Script tool. The model writes JavaScript that runs in a sandbox with no file, network, or system access of its own, so it can only act through the tools Droid exposes. A script can make hundreds of tool calls in one model request, which means instructions and history are sent once instead of re-sent every few calls. Printed output is capped in size, full results are logged where the model can search them later, and calls that don't depend on each other run concurrently.

How the loop actually changes

In direct tool calling, every tool output gets appended to the model's context, and every step costs a request. Under PTC, the intermediate data stays inside the program as ordinary variables. Anthropic's docs for their version of the feature show the shape in one line, where a tool becomes an async Python function inside a code execution container:

rows = json.loads(await query_database({"sql": "SELECT .."}))

The model writes that code, the sandbox runs it, intermediate rows never touch the context window, and the model receives whatever the program returns. Factory's stated reasons for making it the default are concrete: a cleaner context window, fewer model requests, and deterministic reliability, because checks and loops run in code instead of hoping the model re-members its own plan on turn forty.

The numbers, and whose numbers they are

Factory publishes real measurements alongside the launch, all of them self-run:

• The startup context that rides along on every turn (tool definitions included) shrank from 20,887 to 13,055 input tokens between Droid 0.170.0 and 0.250.0, a 37% reduction, and it's the part of the harness they say they cut hardest.
• Script mode cuts Droid's cost by 15% on Claude Opus 5.5, but the savings concentrate in the 12.5% of scripts that make six or more tool calls. Most scripts are small.
• On Terminal-Bench 4, Factory reports Droid scoring 3.5 points higher than Codex with GPT-6.1 Sol at 12% lower cost, and 3.0 to 7.6 points higher than Cursor, OpenCode, Devin, and Claude Code with Opus 5.5 at up to 24% lower cost.

Treat the comparison numbers as vendor-run. Factory executed the benchmark itself between October 23 and 28, and independent coverage flagged methodology choices such as counting cost and time only on tasks both harnesses completed. The one third-party-adjacent number that isn't Factory's: Anthropic reports that adding PTC on top of basic search tools improved agentic search performance on BrowseComp and DeepSearchQA by an average of 11% while using 24% fewer input tokens.

Not a Factory feature, an industry surface

The lineage matters for where you'll meet this. The CodeAct paper (Wang et al., 2024) showed that acting through code beats JSON and text tool calls across 17 models. Cloudflare and Anthropic brought the idea to production in late 2025, Codex brought it to coding agents this year, and Droid 1.0 is the first coding agent to make it the default. OpenAI now documents it as a first-class capability: you add a programmatic_tool_calling hosted tool, and it is enabled by default in their Agents API.

The config surface is the interesting part. A tool definition now declares who may call it:

{
  "name": "query_database",
  "description": "Execute a SQL query against the database",
  "input_schema": { },
  "allowed_callers": ["code_execution_20260120"]
}

That's Anthropic's form, where the value names their code execution tool. OpenAI's equivalent accepts direct, programmatic, or both. Three states per tool, for every tool you expose.

Where the permission boundary moves

Here is the change that reaches your config on Monday. In the old loop, each tool call is a checkpoint: hooks, allowlists, and approval prompts fire per call. When one program makes hundreds of calls inside a single request, those checkpoints can no longer ride the model turn. OpenAI's own guide is blunt about the consequence: for writes or approval-sensitive actions, use direct tool calling "to preserve a clear authorization boundary", and check arguments and permissions for each call in your application even when the call comes from a hosted program. On the MCP side, a tool's require_approval policy can pause the whole program until someone approves.

Droid's answer is the sandbox itself: the script has no file, network, or system access, so the tool interface is the entire boundary. That holds only if the tools exposed to the program are narrowly scoped, which is a config problem, not a model problem.

Four decisions for your config

1. Classify every tool by caller. Reads, searches, and aggregations can go programmatic. Writes and anything with side effects stay direct, or stay behind per-call approval. OpenAI's routing table recommends exactly this split.
2. Tighten output shapes. A program parses structure, not prose. Give tools an output_schema and compact structured returns so generated code doesn't hallucinate field names mid-loop.
3. Move the audit trail. Printed output is capped (in Droid) and full results land in logs, so your logging config becomes the review surface for what the program actually did.
4. Make side-effecting calls idempotent. A retry or replay of a program should not repeat an unsafe action. OpenAI's SDK docs disable some provider-managed retries when a program is present precisely because replay safety is no longer free.

The honest limits

PTC pays off on bounded workflows with predictable control flow. OpenAI's own guidance says to keep direct calling when each result should influence the model's next decision, for adaptive search, or for final citation validation. Most scripts stay small, per Factory's own distribution. Claude Haiku 4.5 accepts the code execution tool but doesn't support PTC at all, so check the capabilities field before assuming a model can use it. And if the whole thing sounds like harness decisions mattering more than model decisions, that's the direction this month keeps pointing: the same model can score 33% or 62% depending on the harness around it, and GitHub now routes between models for you.

Bottom line

Programmatic tool calling turns the most expensive part of an agent run, the per-call round trip that re-sends everything, into a single sandboxed program. The wins are real and measured: 37% smaller startup context for Droid, 24% fewer input tokens in Anthropic's search benchmarks. The cost is architectural: your permission model has to move from the model turn into the tool definitions themselves. The allowed_callers field is where that work lands. If you write agent configs, that's the line item to learn this week.

Sources: Factory's Droid 1.0 announcement, OpenAI's Programmatic Tool Calling guide, Anthropic's programmatic tool calling docs, Neural Brew's independent coverage. Related on this account: the harness variance measurement and Copilot Fusion making model routing a harness decision.