Factory's Droid 1.0 Beats OpenAI and Anthropic Agents While Cutting Costs 51x

Factory has released Droid 1.0, an upgrade to the harness behind its enterprise coding agent. Programmatic tool calling is now the default, allowing the model to generate a short JavaScript program that coordinates hundreds of tool calls in one execution. Factory reports higher Terminal-Bench 4 pass rates than native agents from OpenAI, Anthropic, Cursor, Devin, and OpenCode when each runs the same underlying model.

Every coding agent wraps a model in prompts, tools, result formatting, context management, and an execution loop. That surrounding harness affects accuracy, latency, and cost. Long-running agents may operate for hours across hundreds of turns, with each request resending instructions and conversation history. Reducing model round trips can therefore save more than trimming an individual prompt.

One script, hundreds of calls

A conventional agent sends a tool call, appends the result to the model’s context, and asks the model to choose the next action. Programmatic tool calling, or PTC, moves the loop into code. The model writes a program that invokes tools, checks results, handles batches, and prints a compact summary for the next model request.

Droid implements PTC through a Script tool that runs JavaScript in a sandbox. The sandbox has no direct file, network, or system access. Its capabilities come from the tool functions that Droid explicitly exposes, so existing permissions still determine which external actions the script can perform.

CodeAct research by Wang et al. found that code-based actions outperformed JSON and text tool calls across 17 models. Factory also cites production implementations from Cloudflare, Anthropic, and OpenAI’s Codex. Droid applies the pattern across several model families and enables it by default where Factory’s evaluations show a benefit.

• Smaller contexts: Files, logs, and search results remain inside program variables. The model receives only the values printed by the script.
• Fewer model requests: A single generated program can run many tool calls without resending the full prompt and history after each action.
• Explicit control flow: Loops, batching, validation, and stopping conditions execute as code, reducing the chance that the model skips a planned case.
• Parallel execution: Independent operations can run concurrently through constructs such as Promise.allSettled().

151 issues, 61,000 input tokens

Factory’s clearest production example involved moving 151 Linear issues between queues and verifying every change. The task required 312 tool calls. Factory estimates that direct calling, even with 10 calls grouped into each request, would have required 36 requests and about 3.1 million input tokens. Script mode completed the workflow with two model requests and about 61,000 input tokens: one request generated the program, and another interpreted its printed result.

A separate CI sweep checked 5,384 desktop jobs across 547 runs. The script made 550 tool calls in batches of 60 and completed with two model requests, compared with Factory’s estimate of 59 to 187 requests under direct calling. It returned a five-number summary that included 41 failed jobs, leaving more than 99.9% of the raw tool results outside the model’s context.

Across Factory’s production sessions on Claude Opus 5.5, Script mode reduced cost by 15%. Most savings came from the 12.5% of scripts that issued at least six tool calls, indicating that larger batches deliver the strongest economic benefit.

const remaining = new Set(readReport('<report>').notAttempted) // 151 issues
const queues = await Promise.all([listAll('Triage'), listAll('queue 2')])
const targets = queues.flat().filter((i) => remaining.has(i.id))
const verified = [], failures = []

for (const batch of chunks(targets, 3)) {
  await Promise.allSettled(
    batch.map((i) => setStatus(i, 'Backlog'))
  )

  const after = await Promise.allSettled(
    batch.map((i) => getIssue(i))
  )

  after.forEach((result, index) =>
    (onlyStatusChanged(batch[index], result.value)
      ? verified
      : failures
    ).push(batch[index].id)
  )

  if (failures.length) break
}

text({ verified: verified.length, failures })

The model receives the value passed to text(). Raw issue objects, intermediate responses, and verification data remain inside the sandboxed execution.

Droid leads Factory’s benchmark

Factory tested Droid against Codex, Claude Code, Cursor, Devin, and OpenCode on Terminal-Bench 4, a suite of terminal-based agent tasks. Each comparison used the same underlying model, helping isolate the effect of the harness.

On the rounded figures, Droid’s GPT-6.1 Sol configuration scored 3.6 percentage points above Codex while costing 12% less per task. It scored 6.6 to 12.6 points above OpenCode and Devin. With Claude Opus 5.5, Droid led the listed competitors by 3.1 to 7.6 points and cost up to 24% less.

Execution metrics showed a similar pattern. Droid used 17% fewer tokens than Claude Code and took 26% less time per passed task on Claude Opus 5.5. On GPT-6.1 Sol, it used 12% fewer tokens than Codex but took 10% longer.

Because Factory ran and reported these tests, the figures remain vendor benchmarks. Independent replication would show how consistently the gains carry across task selection, retry policies, pricing assumptions, and production workloads.

An agent tunes the agent

Factory uses an internal system called Agent Factory to adapt Droid when new models arrive. The process combines automated checks, benchmark tasks, production traces, controlled experiments, and engineering review:

1. Automation adds a newly released model and runs behavioral assertions, which are tests for expected agent behavior.
2. Each model receives the same benchmark tasks and a sample of live production traffic.
3. An analysis agent examines traces for failure patterns that recur across tasks or model families.
4. The agent proposes a change and states the hypothesis behind it.
5. A controlled experiment measures the effect on every relevant model family.
6. An engineer reviews the evidence and decides whether the change ships.

Cross-model acceptance criteria prevent an optimization for one model from silently raising costs for another. Factory tested Script mode simultaneously on GPT-6.1 Sol, Claude Opus 5.5, GLM 5.3, and Kimi K3.

One experiment added line numbers to every file read. The change stopped GPT-6.1 Sol from reopening files through the shell to recover line positions and reduced Claude Opus 5.5’s cost by 22% on one task. The extra numbering added about two tokens per line, raising costs by 8% on GLM 5.3 and 32% on Kimi K3. Factory shipped the feature as an opt-in flag.

Small cuts with measurable returns

• Stable prompt caching: Droid previously inserted newly discovered tools near the top of the tool list, invalidating the cached prompt prefix that followed. It now appends tools to the end. Factory says a typical production request reads 98% of its input from cache, while 98.6% of requests preserve the earlier prompt and add content only at the end.
• A smaller base prompt: Between Droid 0.170.0 and 0.250.0, first-request input fell from 20,887 tokens to 13,055, a 37% reduction. Droid now sends two tool definitions initially instead of 11 and loads the others on demand.
• Bounded execution: Droid stops after three turns without visible output. Three identical tool calls trigger a corrective instruction, and six halt the loop. Compaction summaries, which preserve older conversation state when the context is compressed, now receive a 16,000-token budget instead of 8,000.
• Lower launch latency: Median time to first paint fell from 1,839 milliseconds to 488 milliseconds. Median time until Droid accepted a prompt dropped from 1,876 milliseconds to 618 milliseconds, partly through precompiled code and an upgrade to Bun 1.4.2.

Where Script mode pays off

Script mode produces its largest gains on long-running work with repeated operations, bounded inputs, and checks that can be expressed in code. Short exploratory sessions with a few tool calls have fewer round trips to eliminate.

Generated scripts can still contain faulty assumptions, incomplete error handling, or unsafe retry behavior. Side-effecting tools need narrow permissions, idempotency controls, rate limits, and verification. The sandbox blocks direct system access, while tool permissions govern the actions available through exposed functions.

Default models and developer access

• GPT models: GPT-6.1 Sol, GPT-6.1 Terra, GPT-6 Astra, GPT-6 Sol, and GPT-5.6 Sol
• Claude models: Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, and Claude Opus 5
• Other models: Kimi K3

Factory offers Droid through desktop applications for macOS and Windows and through a command-line interface. The Droid SDK, published as @factory/droid-sdk, exposes the same harness to Node applications with multi-turn sessions, streaming, and custom Model Context Protocol tools.

The model turn becomes a larger unit of work

Direct tool calling makes token use rise with the number of model turns because each request carries instructions, tools, and accumulated history. PTC moves repeated operations and intermediate data into a program, allowing one model-generated action to represent a much larger unit of work.

Factory’s Linear example estimates a roughly 51-fold reduction in input tokens, from 3.1 million to 61,000. Total cost will vary with output tokens, tool execution, cache pricing, and model rates, while Factory’s broader production figure shows a 15% cost reduction on Claude Opus 5.5. Together, those numbers explain the practical value of the release: harness design can materially change the cost and reliability of long-running agents even when the underlying model stays the same.