Factory Droid 1.0: A Script-Mode Breakthrough for Model-Agnostic Coding Agents

Factory has released Droid 1.0, a model-agnostic coding agent framework that makes programmatic tool calling the default mechanism. On Factory's own Terminal-Bench 4 test, Droid paired with Claude Opus 5.5 scored 65.2%, at a cost of $4.73 per passed task.

The tool-calling dilemma for coding agents, and a way out

Most mainstream coding agents today rely on the model issuing tool calls one at a time: each step requires the model to reason and return a structured request, which an external framework then parses and executes. This back-and-forth pattern is acceptable for simple tasks, but in complex coding scenarios requiring dozens of tool calls, accumulated latency and context bloat significantly drag down efficiency.

Factory's answer is "script mode" — letting the agent organize tool calls in batches by writing code, rather than requesting them one by one. Droid 1.0 makes this mode the default behavior, meaning the agent tends, during planning, to generate executable script fragments that complete multiple steps at once. This differs fundamentally from traditional function calling: the latter treats each call as an independent event, while the former treats a call sequence as a compilable, executable program.

The design idea is not unfamiliar; prior research has explored the potential of code as a medium for agent action. What makes Droid 1.0 distinctive is that it engineers this into a complete, product-grade framework and explicitly claims model-agnosticism — it does not bind itself to the capability assumptions of any specific vendor's model.

Function Calling is the mainstream mechanism by which large models interact with external tools: based on user intent, the model outputs a structured JSON specifying the tool name and parameters to call; an external framework parses and executes it, then returns the result to the model to continue reasoning. Its advantages are clarity and controllability, with every step auditable; its drawback is that each call requires a full model round-trip. For coding tasks requiring dozens of steps, this "one question, one answer" pattern accumulates substantial latency and repeatedly fills the context window with tool results, slowing things down and driving up token costs.

"Code as Action" is a class of approaches that let agents write code instead of making tool calls one at a time. Representative work includes CodeAct and similar research, whose core observation is that code itself has loops, conditional branches, variable reuse, and intermediate-result storage capabilities, so a model can express in a single script an operation sequence that would otherwise require multiple calls. Compared with function calling, this approach reduces model round-trips and keeps intermediate state in the execution environment rather than the context window, thereby lowering both latency and token consumption. Droid 1.0's "script mode" is precisely the productization of this idea.

What model-agnostic means

The "model-agnostic" positioning deserves unpacking. Coding agent frameworks are usually deeply coupled to a specific model's tool-calling format, context-window characteristics, and reasoning style; switching models often means re-tuning prompts and execution logic. Droid 1.0 claims to break this limitation, in theory allowing users to switch between models without restructuring agent behavior.

Judging from the Terminal-Bench 4 test configuration, Factory chose Claude Opus 5.5 as the reference model and disclosed per-task cost. This detail reveals two things: first, script mode's efficiency advantage may partly come from fewer model round-trips, thus lower token consumption; second, cost data was disclosed as a core metric, indicating that Factory sees the economics of coding agents becoming a competitive focus.

That said, a single benchmark and a single model configuration cannot fully validate the universality of "model-agnostic." Differences in how well various models understand script generation, and their fault tolerance for long-context scripts, will affect the actual experience. Factory's disclosed data currently covers only one test scenario; cross-model comparison data has not yet been made public.

How far the Terminal-Bench 4 results can be read

A 65.2% pass rate and $4.73 per-task cost are figures with reference value in the coding-agent evaluation context, but they should not be over-interpreted. The Terminal-Bench series focuses on task completion in terminal environments, which differs from real development workflows — the ambiguity of requirements, the scale of codebases, and the complexity of environment dependencies in real projects cannot be fully simulated by a benchmark.

The presentation of the cost metric also deserves attention. "Per passed task" cost means the consumption of failed tasks is spread across successful ones. This accounting helps evaluate actual usage cost, but comparability across different task-difficulty distributions is limited. If the benchmark task set skews toward medium difficulty, the cost figure may be optimistic.

Looking at industry trends, competition among coding agents is shifting from "can it do it" to "how fast and how cheaply can it do it." Droid 1.0 highlights cost in its launch, echoing this shift. Script mode theoretically has the advantage of reducing interaction rounds and compressing context usage, consistent with cost-optimization goals.

Terminal-Bench is an agent evaluation benchmark for terminal environments. Tasks typically require completing file operations, code modifications, environment configuration, and script debugging on the command line, with automated validation scripts determining whether a task passes. It is closer to real engineering scenarios than pure Q&A benchmarks, but still runs in controlled container environments with relatively clear task descriptions and limited codebase scale. Its scores can therefore compare different agents' terminal-operation capabilities horizontally, yet are hard to extrapolate directly to large legacy codebases, multi-service collaboration, or real development workflows with vague requirements.

Engineering challenges of programmatic tool calling

Writing tool calls as scripts sounds simple, but engineering it involves many pitfalls. Scripts must be safely parsed and run by the execution environment; tool interfaces must be abstracted into function signatures callable from scripts; and rollback and retry logic after script execution failure must be redesigned. Error handling for traditional one-at-a-time calls is relatively local, whereas a single execution in script mode may involve multiple tools, making state management for partial failures more complex.

Another hidden challenge is the debugging experience. When an agent-generated script fails, developers need to understand the script logic, locate the failing tool call, and determine whether the problem lies in model generation or the tool interface. This debugging chain is more complex than single-step calls, and the framework needs to provide sufficient observability for developers to accept this mode.

Droid 1.0 makes script mode the default rather than an option, indicating that Factory has considerable confidence in the mode's stability. But a default also means users must proactively adapt to a new interaction mental model, which poses a certain barrier for early adopters.

What it means for developers in practice

For teams evaluating coding-agent tools, Droid 1.0 offers a directional sample worth watching: the tool-calling paradigm is migrating from "model-driven step-by-step requests" to "model-generated executable programs." If this migration proves effective, it will change the design focus of agent frameworks — from optimizing prompts for single calls to optimizing the quality of script generation and the reliability of execution.

The model-agnostic promise concerns long-term flexibility. With model capabilities iterating rapidly, decoupling the agent framework from a specific model can theoretically reduce migration costs. But how fully this promise is delivered can only be judged once more cross-model test data emerges.

The information density of Factory's release is not high, with core data concentrated on one benchmark and one model configuration. How broadly Droid 1.0's script mode outperforms traditional calling across task types, and how consistent its performance is when switching models — these key questions still await more independent evaluations.

One-line Summary

Factory releases Droid 1.0, a model-agnostic coding agent framework defaulting to scripted tool calling.

Paragraph Summary

Factory has released Droid 1.0, a model-agnostic coding agent framework that makes programmatic tool calling the default. It lets the agent organize tool calls in batches by writing scripts instead of traditional one-at-a-time function calling, reducing model round-trips and compressing context usage. On Terminal-Bench 4, paired with Claude Opus 5.5, it achieves a 65.2% pass rate at $4.73 per passed task. The article considers this direction valuable for reference, but a single benchmark and single model configuration cannot validate the universality of "model-agnostic"; script mode also brings engineering challenges in multi-tool state management, error rollback, and debugging observability. Key conclusions await independent evaluation.