Factory shipped Droid 1.0 on 29 October 2026, and the headline change is small to describe and large in effect: the model no longer has to call tools one at a time. It writes a short program, and that program makes the calls. In one of Factory’s own examples, a cleanup job that needed 312 tool calls finished in 2 model requests. Factory estimates the old way would have read about 3.1M input tokens. That figure is a model of what would have happened, not a measurement, and Factory says so.
The idea is not new. Making it the default is. I read the post, the changelog and the benchmark methodology. I did not run Droid myself.
What is an agent harness, and why does it cost so much?
Factory defines the harness as “everything around the model: the prompts, the tools, how tool results come back, and the loop that runs it all.” Claude Managed Agents work on the same layer.
The cost problem is simple arithmetic. Agents now run for hours or days across hundreds of turns. Every turn re-sends the instructions, the tool definitions and the history. In Factory’s Linear example, about 28,000 tokens of instructions travel with every single request.
Factory is model-independent and routes between models with something it calls Factory Router. The harness is the part it actually owns.
How does programmatic tool calling actually work?
In the standard loop, the model calls a tool, the output is appended to the context, and the model is called again. Repeat until done. With programmatic tool calling, the agent writes a program that invokes the tools and runs it end to end in one invocation.
In Droid this is the Script tool. The model writes JavaScript, which runs in a sandbox with no file, network or system access of its own. Every real action goes through Droid’s own tools. After the LiteLLM supply chain attack I would not ship an agent that runs generated code any other way.
A few mechanics, per Factory’s post:
- Printed output is capped in size. Full results are logged where the model can search them later.
- Independent calls run concurrently, so a batch takes as long as its slowest call.
- One result can drive the next call. Search, read every match, filter, all in one pass.
Factory gives three reasons for the change. Raw files, search results and logs stay as program variables instead of flooding the context. Fewer model requests mean lower cost and lower latency. And loops and checks run deterministically in code, so the model cannot lazily drop a case it planned to handle.
The cleanest example is a small one. Fixing a failing unit test with GPT-6.1 Sol on high reasoning, direct calls took 10 model calls, 15 tool calls and 56.8 seconds, according to Factory. With Script: 5 model calls, the same 15 tool calls, 41.6 seconds. Time spent inside model calls dropped from 42.3 to 28.0 seconds.
CodeAct (Wang et al., 2024) showed that acting through code beats JSON and text tool calls across 17 models. In Factory’s words, “Cloudflare and Anthropic brought the idea to production in late 2025, and Codex brought it to coding agents this year.” See Cloudflare Code Mode and Anthropic’s advanced tool use.
Script mode is on by default for 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. Factory says it tuned the behavior on GPT-6.1 Sol, Claude Opus 5.5, GLM 5.3 and Kimi K3.
The numbers, direct calls vs Script
All figures below are Factory’s own. The direct-call numbers for the two big jobs are estimates, modeled rather than run.
| Task (Factory’s examples) | Direct tool calls | Script (PTC) |
|---|---|---|
| Fix a failing unit test, GPT-6.1 Sol | 10 model calls, 15 tool calls, 56.8 s | 5 model calls, 15 tool calls, 41.6 s |
| Linear cleanup, 151 issues, 312 tool calls | about 36 requests, about 3.1M input tokens (modeled) | 2 requests, about 61,000 tokens |
| CI sweep, 5,384 jobs, 550 tool calls | an estimated 59 to 187 requests | 2 requests, under 0.1% of results in context |
| Average cost on Claude Opus 5.5 | baseline | 15% lower |
The Linear job moved 151 issues between queues and verified each one. Factory modeled direct calling at 10 calls per request for the 36 figure. The 3.1M token estimate comes from a gentler assumption, 107 requests at 3 calls per request, each one dragging those 28,000 tokens of instructions along. The Script version used 2 requests and about 61,000 tokens. It also compared 15 fields before and after every write and stopped at the first unexpected change. The check runs every time because it is code.
The CI sweep is the more striking one. The Script checked 5,384 desktop jobs across 547 runs, 550 tool calls, 60 at a time. The model saw a five-number summary that included 41 failed jobs. Under 0.1% of tool results ever reached the context. It ran in the background for about 8 minutes.
If it is this good, why is the average saving only 15%?
Factory says most Scripts are small, and the per-task savings concentrate in the 12.5% of Scripts that make six or more tool calls. The 15% cost reduction on Claude Opus 5.5 is an average across real work, and real work is mostly short.
There is also a quieter lesson in the post about how model-specific harness tweaks are. Factory tried numbering every line of every file the agent reads. On one task this cut Opus cost by 22%. It also added about two tokens per line, which raised cost by 8% on GLM and 32% on Kimi. Same change, opposite results. Factory shipped it as an opt-in option. If you build on more than one frontier model, that example is worth more than any benchmark chart.
The boring engineering underneath
Prompt cache first. Newly discovered tools from MCP servers and connectors are now appended at the end of the request instead of inserted near the top, so the cached prefix survives. Factory reports that the typical production request reads 98% of its input from cache, and 98.6% of requests are strictly append-only. That is over 20.4M production CLI requests in the 7 days to 22 October. Weighted by tokens, the append-only share is 91.5%.
Then the base prompt. Between Droid 0.170.0 on Opus 4.8 and 0.250.0 on Opus 5.5, the first request shrank from 20,887 to 13,055 input tokens, a 37% cut. Tool definitions sent up front went from 11 to 2, with the rest loading on demand, and their token count fell from 15,798 to 8,528. The system prompt actually grew 31%, from 1,618 to 2,155 tokens. Different models use different tokenizers, so Factory also gives characters: 57,035 to 36,802, down 35%.
Smaller items:
- Compaction summaries now have room for 16,000 tokens, up from 8,000.
- Three turns with no visible output stop the agent. Three identical tool calls get a nudge, six stop it.
- Parallel sessions share one daemon process, about 20 MB each instead of about 350 MB per process. Median first paint went from 1,839 to 488 ms, quit from 648 to 30 ms.
Factory also describes an internal loop it calls Agent Factory. An automation tracks 20+ models and adds new ones. Agents read benchmark failures and friction from real sessions, propose changes with a stated hypothesis, controlled experiments run on every affected model, and an engineer reviews and merges. Factory says nothing ships without an engineer.
Should you believe the Terminal-Bench 4 numbers?
This is a vendor benchmark, run and reported by the vendor. Read it as a claim, not as an independent result.
Factory ran Terminal-Bench 4 on all tasks from 23 to 28 October 2026, three trials per task, high reasoning. Its claims:
- On GPT-6.1 Sol, Droid scored 3.5 points above Codex at 12% lower cost, and 6.6 to 12.6 points above OpenCode and Devin. Cursor is not shown, which Factory attributes to Cursor having no access to OpenAI models.
- On Claude Opus 5.5, Droid scored 3.0 to 7.6 points above Cursor, OpenCode, Devin and Claude Code, at up to 24% lower cost. It used 26% less time per passed task than Claude Code and 17% fewer tokens.
- On GPT-6.1 Sol, Droid used 12% fewer tokens than Codex but took 10% longer.
Factory left that last line in, which a pure marketing chart would not. It also lists its own methodology quirks:
- Cost and time only count tasks that both harnesses passed in all three trials.
- Runs that hit Anthropic content moderation blocks on Opus 5.5 were rerun on Opus 5.
- Devin tasks where it stopped to ask the user were counted as passed if Codex passed, an average of 4.7 tasks per trial.
- Cursor’s token undercount was estimated from transcripts in two trials.
Versions tested: codex@0.163.0, claude-code@2.1.306, cursor-cli@2026.10.19-6bbf2c4, devin@3000.11.92, opencode@2.1.2.
None of this looks dishonest, but it shows how many judgment calls sit inside a “3.5 points” headline. What would convince me is an independent rerun with the same versions, or another harness team reproducing the gap. Until then, the gaps are plausible and unconfirmed.
What this means if you build agents
Droid 1.0 ships as a desktop app for macOS and Windows, a terminal UI, and the Droid SDK, @factory/droid-sdk. The SDK runs the same Droid as the CLI: start it from Node, hold multi-turn sessions, stream work, add custom tools over MCP, or connect to a running daemon.
If models are going to call your tools from code, write tools that are pleasant to call from code. Return typed data and short summaries, and keep raw output out of the context. Factory’s design choices say the same thing: real typed data, literal text in raw blocks instead of escaped strings, a 5-minute wait before handing back partial output, and a dedicated tool to check or stop a running program so nobody polls.
And budget tokens like they cost money, because they do. The 28,000 tokens re-sent on every request is the number I keep coming back to. The Claude Duet deep dive covered the approval side of long-running agents. The cost side is just as real.
What to watch next: whether anyone reproduces the Terminal-Bench 4 gaps, and whether the 15% average moves as more people hand agents long, boring, many-step jobs.
Sources
- Factory, Droid 1.0: Building a Frontier Harness (29 October 2026)
- Factory, Release notes, CLI v1.0.0 and Desktop v1.0.0
- Factory on X, launch post
- Wang et al., CodeAct (2024)
- Cloudflare, Code Mode
- Anthropic, Advanced tool use
