Factory Droid 1.0: Programmatic Tool Calling, Prompt Cache Discipline, and the Benchmark Claims to Read Carefully

Factory published "Droid 1.0: Building a Frontier Harness" on October 29. The post is a vendor engineering write-up, and the most reusable part is not the leaderboard. It is the design: let the model write a program that calls tools, keep the request append-only so the prompt cache stays warm, and put stuck-detection rules in the loop instead of the model.

I read the whole post. I did not read the methodology page it links, run Droid, or check any benchmark. Every number below is Factory's, from its own testing, and Factory sells the product.

What Factory claims at the top

• Droid is Factory's agent harness, "everything around the model: the prompts, the tools, how tool results come back, and the loop that runs it all".
• "On the same tasks, Droid outperforms the native harnesses built for their models up to 20% more efficiently."
• On Terminal-Bench 4 with GPT-6.1 Sol, Droid scores 3.5 points higher than Codex at 12% lower cost, and 6.6 to 12.6 points higher than OpenCode and Devin. With Claude Opus 5.5, it scores 3.0 to 7.6 points higher than Cursor, OpenCode, Devin and Claude Code, at up to 24% lower cost.
• The post notes Cursor is not shown for OpenAI models because it has no access to them.
• On Claude Opus 5.5, Droid takes 26% less time per passed task than Claude Code and uses 17% fewer tokens. On GPT-6.1 Sol, it uses 12% fewer tokens than Codex while taking 10% longer.

So even in Factory's own table, the result on one model is slower than the competitor. These are comparisons Factory ran, against competitors it chose, and I could not check the methodology.

Programmatic tool calling

In a standard loop, the model calls tools directly and every output is appended to its context. With programmatic tool calling (PTC), per the post, the agent writes a program that invokes the tools, then runs it end to end in one invocation. Factory made this the default in Droid 1.0 for three stated reasons: a cleaner context window, fewer model requests, and more reliable loops and checks because they run deterministically in code.

The post credits earlier work: CodeAct (Wang et al., 2024) on acting through code, and says Cloudflare and Anthropic brought the idea to production in late 2025 and that Codex brought it to coding agents this year. I did not check those claims.

How Droid does it. A Script tool where the model writes JavaScript that runs in a sandbox with no file, network or system access of its own. Per the post:

• A Script can make hundreds of tool calls in one model request.
• Printed output is capped, and full results are logged where the model can search them later.
• Independent calls run concurrently.
• A program waits up to 5 minutes and then hands back its output so far. It can also start in the background, and a dedicated tool checks, waits for or stops it. Droid wakes the model when background work finishes, so there is no polling.

Factory's numbers on it:

• An example session, fixing a failing unit test with GPT-6.1 Sol: direct calls took 10 model calls and 56.8 seconds, the Script version 5 model calls and 41.6 seconds, for the same 15 tool calls.
• Script mode cuts Droid's cost by 15% on Claude Opus 5.5. The post says most Scripts are small, and savings concentrate in the 12.5% that make six or more tool calls.
• Two Scripts from Factory's own sessions: a Linear cleanup moving 151 issues (312 tool calls) took 2 model requests and about 61,000 tokens, versus an estimated 36 requests and about 3.1M input tokens with direct calls. A CI sweep of 5,384 jobs took 2 requests instead of an estimated 59 to 187.

Notice the wording: the direct-call figures for those two cases are estimates, which the post states, assuming 3 to 10 calls per request. They are modeled, not measured.

Script mode is on by default for a list of models, including GPT-6.1 Sol, GPT-6.1 Terra, Claude Opus 5.5 and Kimi K3, per the post.

Design choices the post lists

A table in the post names choices that mattered: programs get whole files and structured, typed search results, literal text travels in raw input blocks instead of escaped strings, edits inside a program return the same short summary as a direct edit, and programs never block on a long job.

Prompt cache discipline

Providers cache requests by prefix, so any early change invalidates everything after it. Per the post, Droid's requests were already append-only except tool discovery, since tool definitions sit near the top. Droid now appends newly discovered tools to the end of the request.

Factory reports: in production the typical request reads 98% of its input from cache, and 98.6% of requests are strictly append-only. A monitor compares every request with the previous one and names whatever broke the cache. Its test numbers for the share of the next request read from cache: 99.1% after a git status change, 99.8% after a session rollback, 96.5% with a second subagent of the same type, and 100% after loading a new tool in a before-and-after test on Azure.

Whether or not you use Droid, the rule is general: anything inserted near the top of a request after the session starts forces the provider to reprocess what follows.

A smaller base prompt

Factory says the first request shrank from 20,887 input tokens to 13,055, a 37% reduction, between Droid 0.170.0 and 0.250.0. Most of it came from tools: 11 tool definitions sent up front became 2, with rarely used tools loaded on demand. The post says the two releases ran on different models, so tokenizers differ, and gives a character count too (57,035 to 36,802, down 35%). The system prompt itself grew 31%.

Bounded autonomy

The post says the rules for stuck agents live in the loop, so they hold for every provider:

• On Factory-managed Anthropic streams, 4 minutes of silence counts as a dropped stream and is retried.
• A response that hits a hard time limit gets at most two attempts.
• Three turns in a row with no visible output, and Droid stops. Three identical tool calls get a nudge, and six stop the loop. Repeats that return new results, like polling a build, can continue.
• Compaction summaries now have room for 16,000 tokens, up from 8,000, because by Factory's estimate a third or more were filling the old limit.

These are concrete numbers you can copy into your own loop as starting points, and test.

The Agent Factory

Factory describes an internal loop where agents study benchmark failures and user friction, propose changes with a stated hypothesis, and test each on every affected model, and where engineers review the evidence and decide what ships. It says an automation tracks more than 20 models. One example it gives cuts both ways: numbering every line of files read cut Opus's cost by 22% on one task but raised cost by 8% on GLM and 32% on Kimi, so it shipped as an option the model asks for.

Speed numbers

Median time to first paint fell from 1,839 to 488 ms and time to first prompt from 1,876 to 618 ms between the August 25 and October 20 releases, per the post. Median quit time in production fell from 648 to 30 ms, and sessions share a daemon process at about 20 MB each instead of about 350 MB per process.

What the post does not tell you

• The benchmark methodology. The post links a page I did not read.
• How competitor harnesses were configured, and whether each got the same tuning effort.
• Any result from an independent party.
• What Droid costs. The post gives relative cost, not a price.
• Failure cases for Script mode, such as bad programs that run many wrong calls. The sandbox has no file, network or system access, but tool calls inside it can still act.

What I would check

These are my untested suggestions.

1. Check your own loop for cache breaks. Log whether anything in your request changes before the end between turns.

2. Try batching tool calls into one program for one workflow with many reads, and compare model requests and tokens with direct calls.

3. Decide what a program may do without review. A Script that runs hundreds of calls can also run hundreds of wrong calls. Think about approval for destructive tools.

4. Add loop-level limits. Repeated identical calls and silent turns are cheap to count.

5. Read the methodology page before you use any of the benchmark gaps in a decision.

6. Run your own tasks. A 3 to 7 point difference on one benchmark may not show up on your code.

What I would not conclude

• That Droid is the best harness. The comparisons are Factory's, and on one model it was slower than a competitor by its own numbers.
• That PTC is always cheaper. The post says savings concentrate in a minority of Scripts, and its direct-call baselines are estimates.
• That a 98% cache read rate applies to your workload.
• That a sandboxed Script is safe. The sandbox limits the program, not the tools it calls.

Frequently asked questions

What is programmatic tool calling?

Per Factory, the agent writes a program that invokes the tools and runs it in one invocation, instead of calling each tool in a separate model turn.

Which models use Script mode by default?

The post lists 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.

How much does Script mode save?

Factory says 15% of cost on Claude Opus 5.5, with savings concentrated in Scripts that make six or more tool calls.

What does append-only mean for a request?

New content goes at the end, so the provider can reuse the cached prefix. Factory says 98.6% of its production requests are strictly append-only.

How does Droid stop a stuck agent?

By counting: three silent turns stop it, three identical tool calls get a nudge, six stop the loop, per the post.

Are the benchmark results independent?

No. They are from Factory's own testing. I did not read the methodology page.

Is Droid open source?

I did not see that in the post. Check Factory's site.

Sources

All read on October 30, 2026.

• Droid 1.0: Building a Frontier Harness (Factory, October 29, 2026)

Not read: the benchmark methodology page, the figure animations in detail, and any independent evaluation.