Droid 1.0: Programmatic Tool Calling Comes of Age

Posted on by
Contents show
Droid 1.0

A coding agent like Droid 1.0 spends most of its life in its tool loop. It calls a tool, reads the output, decides, calls another. On a messy task that loop spins hundreds of times, and every spin has a price measured twice: in tokens, because every tool output lands in the model's context, and in latency, because every model call takes seconds. The loop is the agent, and the loop is also the bill.

Factory has released Droid 1.0, the largest update yet to its model-independent agent harness, and the change at its center attacks that loop directly. Droid 1.0 turns the loop itself into the product. Programmatic tool calling is now on by default: instead of reading each tool output, the model writes a short program that runs its tools, keeps the raw results inside a sandbox, and returns only what it printed. One model request can now drive hundreds of tool calls.

Factory reports that Droid 1.0 cut its base prompt by 37 percent, lifted its Terminal-Bench 4 pass rate to 65.2 percent with Claude Opus 5.5, the highest of any harness it tested on the same model, and did so at lower cost than every competitor it measured.

This article explains how Droid 1.0's programmatic tool calling works, what the benchmarks establish and what they only suggest, and why the rest of the update, an agents-improving-agents loop, may matter more than the headline feature.

What a harness is, and why the loop is the product

Factory defines a harness as everything around the model: the prompts, the tools, how tool results return, and the loop that runs between them. Droid 1.0 is that definition taken seriously. The definition is worth taking seriously, because it implies the model is the replaceable part.

Droid 1.0 is model-independent. Users bring their own API keys or let Factory Router pick a cost-efficient mix, and the harness adapts underneath whatever model wins the next evaluation. That positioning changes what a release like this one has to prove. A model maker ships capability; a harness maker has to ship reliability and cost per task, because the model can be swapped underneath. Every number in the release is therefore a claim about the loop, not about a model.

The standard loop is the target. In it, the model requests a tool, the harness executes it, the full output enters the context, and the model decides again. Each iteration costs a model call plus the tokens for everything the tool returned. A search that returns fifty kilobytes of logs costs fifty kilobytes of context, whether or not the useful part was two lines. Agents have compensated with clever summarization and truncation, but the structural problem remains: the model reads everything its tools produce.

Programmatic tool calling removes the structure. The question is how, and the answer is a tool that is also a program.

The Script tool: programs instead of round trips

Droid 1.0 implements programmatic tool calling as a Script tool, and the Droid 1.0 sandbox is the security boundary for everything the model writes. In the Droid 1.0 design the model writes JavaScript, the JavaScript runs in a sandbox with no file, network or system access of its own, and the sandbox can call the harness's real tools. Raw files, search results and logs stay inside the program's world. Only printed output returns to the model's context. Independent calls inside a Droid 1.0 script run concurrently.

The consequence is easiest to see in a bulk task. Factory describes a cleanup that moved and verified 151 issues through 312 tool calls. Run directly, that models to 36 model requests and roughly 3.1 million tokens. Run as a script, it took 2 requests and about 61,000 tokens, a reduction of about 98 percent on the same work. A CI sweep of 5,384 jobs across 547 runs completed in 2 requests, with under 0.1 percent of tool results reaching the model's context.

Those are self-reported Droid 1.0 examples, and a skeptic will note they are the showcase cases. But the mechanism behind them is not mysterious: when a loop's iterations are deterministic bookkeeping, moving them from the model into a program is not an approximation, it is a correction. The model should decide what to do; it should not need to be the for-loop.

The lineage of programmatic tool calling matters too. The approach builds on CodeAct, published in 2024, which argued for executable code as the agent's action space. What Droid 1.0 adds is production packaging: on by default, working across ten models including GPT-6.1 Sol and Kimi K3, and measured rather than merely argued for.

Watching one task through both loops

The abstract claim gets concrete when the same task runs through the standard loop and the script loop side by side, so consider the unit-test fix from the release.

In the standard loop, the agent requests a read of the failing test, receives the file in context, requests a second read of the implementation, receives it, requests a patch application, receives the diff confirmation, runs the test, receives the full failure output, and iterates. Ten model calls, five tool calls, 56.8 seconds. Most of the context after the third call is file contents the model has already decided not to change.

In the Droid 1.0 script loop, the model writes a program: open the test, open the implementation, compute the patch, apply it, run the test, print the verdict. One request produces the program. The sandbox executes it, making the same five tool calls concurrently where they are independent, and prints a three-line summary. The model reads the summary, confirms the fix, and finishes. Two requests, 41.6 seconds, and a context that contains the decision rather than the debris.

The difference in what the model sees is the deeper story. In the standard loop, the model's attention is spent re-reading tool output on every subsequent call, diluting the signal it needs for the next decision. In the script loop, the printed summary is the only trace, so the model's context stays close to pure decision state. Cheaper and sharper at the same time is rare in systems work, which is why the technique deserves the default-on treatment.

A failure mode exists symmetrically. When a script has a bug, the model now debugs a program it wrote that touched hundreds of tool calls, and the error surface is a stack trace rather than a transcript of what went wrong on step 40. Factory's bounded autonomy counters help, and the release does not claim otherwise, but debugging programs written by a model is a different skill from reviewing its steps, and teams will feel that difference in their incident workflows.

What the Droid 1.0 benchmark establishes

Factory ran each competing harness against Droid on the same model, three trials per task, between October 23 and 28, 2026, counting only tasks that both harnesses passed in all three trials toward cost and time. On Claude Opus 5.5, Droid scored 65.2 percent on Terminal-Bench 4 against 62.1 for Cursor, 59.6 for Devin and 57.6 for Claude Code, at up to 24 percent lower cost, taking 16 to 26 percent less time per passed task and 17 percent fewer tokens than Claude Code. On GPT-6.1 Sol, Droid scored 57.6 percent at $0.79 per passed task against 54.0 for Codex, though Codex was 10 percent faster per passed task.

Two features of the methodology strengthen the result. Same model across harnesses means the comparison isolates the loop, which is the thing being sold. And cost-per-passed-task, rather than cost-per-run, prevents the common trick of failing cheaply.

The limits are equally visible. These are Factory's own runs of its own methodology on its own product, and the time figure concedes that on Sol, Codex still wins on speed. Terminal-Bench measures terminal tasks, which is a real but bounded slice of agent work for Droid 1.0. And pass-rate differences of a few points across harnesses running identical models, while consistent enough to suggest a real loop advantage, are small enough that teams should expect their own workloads to vary. The Droid 1.0 release's own framing, highest pass rate of every harness Factory tested, is accurate as written and self-reported.

The cache trick hiding behind the tool list

One change in the release looks minor and is arguably the most broadly useful: newly loaded tools are appended to the end of the request instead of the system prompt.

The reason is prompt caching. Cached prefixes must match byte for byte, so a tool definition inserted early invalidates everything after it, and every model call re-reads the whole prompt at full price. Appending new tools to the request tail preserves the shared prefix, which is why the typical production request now reads 98 percent of its input from cache. Combined with the 46 percent reduction in upfront tool definitions, from 11 shipped to 2, the first request gets cheaper and every subsequent request gets dramatically cheaper.

This is unglamorous systems work, and it is the kind of change that compounds silently across thousands of sessions. Teams that operate their own agent stacks should steal the pattern directly: order the prompt so volatile content sits at the tail, and defer loading anything the session has not needed yet. The savings do not depend on Droid, the Script tool, or any particular model, and they arrive immediately.

The Agent Factory loop may outlast the feature

The quieter story in the release is how these improvements were produced. Factory describes an internal loop, Agent Factory, in which agents read harness failures and propose changes, with every proposal tested on every affected model family before engineers review and merge.

That is a compounding process. A human-driven harness improves when someone notices a problem; an agent-driven harness improves whenever its failures are legible enough to propose against. The release's other changes read like outputs of that process rather than features someone prioritized: tool definitions appended to the request tail so the typical production request reads 98 percent of input from cache, rarely used tools loading on demand, a bounded autonomy scheme where three identical tool calls trigger a nudge and six stop the loop, compaction summaries doubled to 16,000 tokens, first paint cut from 1,839 milliseconds to 488, and per-session memory reduced from 350 MB to about 20 MB.

The bounded autonomy scheme in Droid 1.0 deserves its own mention, because it is the kind of safety mechanism that only gets built after watching real failures. A stuck loop is the most common pathological agent behavior, and counting identical calls is a cheaper detector than any clever one. It is also the same principle, replay and bounds around generated behavior, that this site has argued for elsewhere, including in recursive agent harnessing: autonomy is fine when the loop has a leash.

What changes for governance and audit

The shift from transcripts to programs reaches further than debugging habits, because it touches how enterprises prove what an agent did.

A transcript-based agent produces a legible record by construction. Every tool call, every input and every output sits in sequence, and an auditor can replay the reasoning step by step. A programmatic agent produces a program and an execution log, which is equally complete for anyone who can read the program, and considerably less legible for everyone else. The information is not lost; it has moved behind a literacy boundary.

That has two practical consequences for anyone auditing Droid 1.0. Incident review needs tooling that renders a script execution into a human-readable narrative of what the sandbox did, and any vendor in this space that ships such a renderer will have answered the first question every security team asks. And policy enforcement needs to move inside the sandbox. If a script can call the harness's tools, then the harness's permission model, not the model's judgment, is what stops a bulk operation from touching something it should not. Droid's sandbox strips file, network and system access from generated programs, which addresses the contained-world problem, but the tool permissions granted to the sandbox remain the real perimeter.

Enterprises evaluating the Droid 1.0 harness should ask for exactly two demonstrations: a rendered execution narrative for a failed script, and the permission boundary of the sandbox against a deliberately overreaching one. Both are cheap to request and either answer is informative.

Reading the release as an enterprise buyer

Strip the benchmark framing and the Droid 1.0 buyer's decision comes down to four things, each of which the release changes to a measurable degree.

Cost per passed task, which is the metric that actually maps to budget, improved on both tested models, dramatically so on Opus 5.5. Surface coverage is complete, with a desktop app, a terminal UI and a Node SDK that exposes the same harness with sessions, streaming and MCP tools, starting at $20 per month. Model independence means the Droid 1.0 harness investment survives a model switch, which is the hedge most enterprises say they want and few actually get. And the Droid 1.0 benchmark methodology, published with dates, trial counts and pass criteria, is reproducible in outline even though the runs are Factory's own.

What should temper enthusiasm for Droid 1.0 is equally concrete. The SDK's license is Apache 2.0 but the harness license is not disclosed in the comparison, which matters for teams planning to embed it. Terminal-Bench is not the workload most enterprise teams have; a repo with a slow build, flaky tests and private APIs will stress a harness in ways the benchmark does not. The Script sandbox removes file, network and system access from generated programs, which is the right default, but the boundary between what a script may call and what it may not deserves scrutiny in any deployment where the model is exposed to untrusted input. And programmatic tool calling changes the debugging experience: when 312 tool calls hide inside 2 model requests, a failed script is a program to debug, not a transcript to read.

That last point is a genuine trade, not a flaw. Teams adopting Droid 1.0's programmatic tool calling are moving from an auditable transcript to an auditable program plus a log. The trace is smaller, faster and cheaper; it is also less narratable. For high-stakes deployments, the transcript remains worth keeping, and the release does not say whether Droid retains one.

For a broader view of where harnesses fit in the agent stack, the comparative work in our AI gateway comparison covers the serving boundary, and our piece on Nvidia OpenShell covers the enforcement boundary. Droid 1.0 is the strongest public statement yet about the loop boundary, and the three together sketch the full stack an enterprise actually has to govern.

Questions teams will ask

Does programmatic tool calling work with every model?

Droid 1.0 ships it on by default for ten models, including GPT-6.1 Sol and Kimi K3, and the harness is model-independent otherwise. The honest answer for any model outside that list is: test it, because writing good scripts is a model capability and the release's own comparison concedes that the advantage over Codex disappears on speed with some models.

Is the Script sandbox safe against a malicious model?

The sandbox has no file, network or system access of its own, and generated programs can only call the harness's tools. That containment is the right architecture. The remaining question is which tools the sandbox may call and with what permissions, and that is a deployment configuration to verify, not a guarantee to assume.

What should we benchmark before switching harnesses?

Cost per passed task on your own task suite, time per passed task, and the failure modes you have actually seen in production. Terminal-Bench results are a useful prior; they are not your workload.

Sources
Subscription Form