Factory Makes Script Mode the Default in Droid 1.0 | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
Factory Makes Script Mode the Default in Droid 1.0
Droid’s JavaScript workflows can batch hundreds of tool calls while controlling what reaches the model, but Factory’s efficiency figures still need independent validation.
Factory made Script mode the default in Droid 1.0, announced October 29, 2026, letting a single model request drive hundreds of tool calls through a JavaScript workflow instead of a turn-by-turn loop.
Factory's own benchmark figures show Droid reaching 65.2% on Terminal-Bench 4 with Claude Opus 5.5, versus 57.6% for Claude Code, and claim a 15% cost reduction from Script mode alone. A worked example reports 41.6 seconds versus 56.8 seconds for the same 15 tool calls. All figures are vendor-run and have not been independently reproduced.
Factory made programmatic tool calling the default in Droid 1.0, announced on October 29, 2026. Its Script tool lets an AI model write a JavaScript workflow that invokes Droid’s tools, processes their results and returns selected output to the model. Factory says one model request can drive hundreds of tool calls. Factory’s announcement describes this as the largest change behind the updated agent’s performance.
The practical shift is where intermediate work happens. Files, search results and logs can remain variables inside a running program instead of entering the model’s conversation history after each tool call. The model receives the program’s printed output, with a size cap, and can search logged results later.
That gives developers a concrete alternative to turn-by-turn tool calling for long-running agents. It also creates a different engineering problem: deciding what the program should expose, what it should verify and how to inspect its actions afterward.
How Droid’s Script Tool Changes the Agent Loop
Droid is an agent harness, the software around a model that supplies prompts, tools, execution logic and tool results. Factory describes it as model-independent: developers can choose a supported model or use Factory Router to select a mix.
In the conventional loop described by Factory, the model requests tool calls, receives their outputs and decides what to do next. Direct tool calling can batch operations, but repeated model turns still carry instructions and accumulated history through the workflow.
Script mode moves more of that orchestration into code:
The model writes JavaScript describing a workflow.
Droid executes it in a sandbox.
The program invokes available tools, stores results and performs checks or transformations.
Selected printed output returns to the model.
The model decides whether further work is necessary.
Factory says the sandbox has “no file, network, or system access of its own.” The JavaScript reaches external resources through Droid’s tools, so the sandbox boundary and the tools’ permissions are separate considerations. The primary announcement documents this distinction.
Consider a repository search. A workflow could read a list of files, examine their contents and return only matching paths with short excerpts. The full file contents would remain intermediate data. A ticket workflow could fetch issues, apply a condition to each one and report the identifiers that need attention.
These are explanations of the documented mechanism, not workflows tested for this article. Factory itself gives examples involving hundreds of files, Linear tickets and a database migration broken into deterministic steps.
The useful distinction is between tool execution and model reasoning. Script mode still performs the underlying reads, searches or updates. It can remove the need for the model to supervise each intermediate step.
I’d view that as a good fit for repetitive operations with clear rules. Work that requires interpreting an unexpected result may still need another model turn. Packing more operations into JavaScript cannot eliminate decisions the program was never equipped to make.
Fewer Model Requests, With the Same Tool Work
Factory’s worked example compares two ways to fix a failing unit test. Both perform 15 tool calls, but Script mode uses fewer model requests:
Factory’s worked example
Direct tool calls
Script tool
Model calls
10
5
Tool calls
15
15
Elapsed time
56.8 seconds
41.6 seconds
The announcement’s example shows a 15.2-second reduction. Calculated from those figures, that is approximately 27% less elapsed time, alongside a 50% reduction in model calls.
That difference matters. Halving model requests did not halve completion time because tool execution and other processing still took time. The example illustrates reduced orchestration overhead, not a universal multiplier for agent speed.
Factory also says independent calls can run concurrently. A group of unrelated reads can therefore overlap, while a call that needs an earlier result must wait. In practice, service rate limits, concurrency limits and slow individual operations can constrain the benefit.
A larger example shows why context management may be the more consequential change. MarkTechPost’s account of Factory’s results reports a Linear cleanup involving 151 issues and 312 tool calls:
Factory’s Linear example
Script workflow
Estimated direct-call workflow
Model requests
2
36
Tokens
About 61,000
About 3.1 million
The direct-call figures are an estimate, not a second measured execution. That distinction rules out treating the table as a demonstrated 51-fold token saving across equivalent runs.
The mechanism is still useful to understand. A program can process hundreds of responses while returning a compact report. A conversational loop may repeatedly carry those responses forward as history.
Token counts also need billing context. Savings depend on the model’s prices, prompt caching, output volume and how a provider charges for requests. Fewer tokens and lower cost are related, but they are different measurements.
What Factory’s Benchmark Results Actually Show
Factory reports higher Terminal-Bench 4 scores than competing harnesses using the same underlying models. The following figures come from its own runs, as detailed in TSN’s coverage of the announcement and methodology:
Model
Harness
Reported pass rate
Reported cost per passed task
Claude Opus 5.5
Droid
65.2%
$4.73
Claude Opus 5.5
Claude Code
57.6%
Not listed here
GPT-6.1 Sol
Droid
57.6%
$0.79
GPT-6.1 Sol
Codex
54.0%
Not listed here
These are vendor measurements, not independently reproduced results. TSN reported finding no independent reproduction, and neither cited third-party article supplies its own test results.
Factory ran the comparisons between October 23 and 28, 2026, with three trials per task and high reasoning effort. Several methodology choices affect how readers should interpret the outcome:
Cost and time use a restricted comparison set. They include tasks that both harnesses in a pair passed in all three trials, rather than every attempted task.
Some failures were rerun. Factory reran trials it judged to have failed for reasons outside the harness.
Some Opus trials changed models. Where Anthropic’s moderation stopped Opus 5.5, Factory reran those trials using the older Claude Opus 5.
Devin received a scoring adjustment. When it stopped to ask a question, Factory counted the task as passed if Codex had passed it, averaging 4.7 tasks per trial.
These conditions are consequential. Cost on consistently successful shared tasks answers a narrower question than the total bill for attempting an entire workload, including failures and retries.
The speed results also vary. Factory reports that Droid took 26% less time per passed task than Claude Code with Opus 5.5, but 10% more time than Codex with GPT-6.1 Sol. A general claim that Droid is faster would obscure that model-specific result.
Script Mode’s Benefit Is Separate From the Whole Harness
Factory attributes a 15% cost reduction on Claude Opus 5.5 to Script mode compared with Droid’s direct tool calling, according to TSN. That comparison is closer to the question of what programmatic calling contributes.
The cross-product benchmark measures more than Script mode. Factory also changes prompts, tool descriptions and other parts of the harness. Its announcement says those choices are tuned for each supported model.
My reading is that the evidence supports two separate propositions: Factory reports that its complete harness performs well under its chosen benchmark conditions, and it reports an additional cost benefit from Script mode within Droid. Those numbers should not be combined into a cumulative savings promise.
For an adopter, the most informative comparison would hold the model and workload constant while changing the tool-calling mode. That would help distinguish gains from programmatic orchestration from gains elsewhere in the product.
The Sandbox Boundary Is Only Part of Safety
A JavaScript sandbox without direct filesystem or network access limits what the script runtime can do by itself. Droid’s exposed tools remain the route to useful actions, including any tool capable of reading private information or modifying external systems.
The practical safety boundary therefore includes tool permissions, credentials and approval controls. A script capable of issuing hundreds of calls can also issue hundreds of consequential writes if those tools permit it.
Programmatic loops improve consistency: code can check every item in a list without asking the model to remember which items remain. Consistency is not the same as correctness. A mistaken filter or update rule can propagate through an entire batch.
For workflows with side effects, I’d look for:
A preview step showing which records or files will change.
Bounded execution, with limits on batch size, runtime and concurrency.
Explicit failure handling, so partial completion is visible.
Safe retry behavior, especially where repeating an action could duplicate a write.
A recovery path, through rollback or another documented repair process.
These are adoption criteria, not claims that Droid provides each control. Factory’s sandbox description alone is insufficient to assess every connected tool’s approval and recovery behavior.
Selected Output Makes Auditability More Important
Factory says printed Script output is capped and full results are logged where the model can search them later. That separates the immediate reasoning context from the larger execution record.
This is a useful design choice: the model need not ingest every raw response to make progress. But the workflow must preserve enough information to recognize uncertainty. A summary that reports only successful updates could hide skipped records or failed checks unless the program explicitly includes them.
For operational work, I’d want returned output to include counts, failures and identifiers for follow-up inspection. The audit record should also make it possible to connect the generated script with tool arguments, results and errors. Those are practical recommendations derived from selective output, not verified descriptions of Droid’s logging interface.
Factory’s related work on agent data context is covered in our report on its Typedef acquisition. For Script mode, the immediate issue is how much retrieved data the workflow retains and how much evidence it shows the model.
Before adopting the default for a long-running workflow, developers should compare completion quality, total cost, wall-clock time and recovery behavior on their own representative tasks. A smaller context is valuable when it removes repetitive intermediate material. The stronger implementation is one that preserves the exceptions and evidence needed to make the next decision safely.
Frequently Asked Questions
3 questions
1
Does One Script Mean One Tool Call?
No. Script is the model-facing invocation that runs a JavaScript workflow. Factory says that workflow can invoke hundreds of underlying tools in one model request.
2
Can Script Access Files or the Network Directly?
Factory says the sandbox has no filesystem, network or system access of its own. Access to external resources goes through Droid’s tools and their permissions.
3
Is Droid Faster Than Codex?
Factory’s reported GPT-6.1 Sol comparison put Droid 10% slower per passed task than Codex. Its reported speed advantage over Claude Code used a different model, Opus 5.5.
