Droid 1.0 puts tool orchestration into code
Factory released Droid 1.0 on October 29, making JavaScript tool orchestration the default for supported models. Its design gives developers a practical reason to examine which work belongs in model context and which belongs in ordinary code.
Spec sheet
- Release
- Droid 1.0; 29 October 2026
- Execution
- Sandboxed JavaScript calling tools
- Cloudflare approach
- Server-side search and execute tools
- Anthropic approach
- Code-based MCP discovery and execution
Three layers of the same design problem
Factory puts this machinery inside a complete coding agent. Cloudflare’s February 20 Code Mode announcement applies it to a server exposing Cloudflare’s own services. Anthropic’s November 4, 2025 engineering article describes an implementation pattern for agents using Model Context Protocol tools. These are different purchasing and engineering choices. Buying an agent delegates more of the execution loop to a vendor. Connecting a server leaves the surrounding agent intact. Adopting a pattern means maintaining that loop yourself.
The shared architectural question is where intermediate work happens. Anthropic describes discovering tool definitions as needed and processing results inside an execution environment. Cloudflare exposes search and execution through two tools, with code running in a Worker isolate. For a hypothetical report that reads many records and returns a total, the model needs the answer and relevant exceptions. Giving it every record introduces another interpretation step. That step is useful when judgment is required; arithmetic and pagination usually need a clearer contract.
Three different meanings of efficiency
Cloudflare’s roughly 1,000-token figure measures the tool-definition surface. Factory’s Linear example uses a modeled direct-calling baseline. Anthropic’s token-saving example illustrates a workflow design. None of those quantities is interchangeable. A smaller initial description can coexist with expensive retries. A large reduction in intermediate data can coexist with an unchanged final answer. The relevant comparison depends on whether the bottleneck is discovery, repeated model requests, execution time or correcting an unsuccessful result.
A useful evaluation therefore has several denominators. Cost per attempted task answers a budgeting question. Cost per correctly completed task answers an operational question. Time until the first result differs from time until a reviewer accepts it. If a script completes nine writes and fails on the tenth, a retry that repeats every write may look efficient in token accounting while creating cleanup work. This hypothetical failure belongs in the test design, alongside the successful batch.
The sandbox is only one boundary
Factory says Script has no direct filesystem, network or system access; it can invoke tools. Cloudflare’s execution uses authenticated requests under approved permissions. Anthropic assigns sandboxing, resource limits and monitoring to the implementation. The analytical distinction is between containing code and controlling consequences. An isolated program can still request an authorized change. Permission scope determines what that change can affect, while approval placement determines whether a person sees it before execution.
That distinction also changes what a useful trace contains. A final summary cannot explain which operation failed halfway through a batch. For a production evaluation, the interesting evidence includes attempted operations, returned identifiers, partial completion and the path used to resume. Logging everything is not automatically the right answer either: a trace can contain the same sensitive records that were deliberately kept outside model context. Retention and reviewer access are part of the design decision.
The practical choice is therefore about ownership as much as speed. A hosted integration suits a bounded service surface; a complete agent supplies a broader workflow; a custom execution layer offers control over both. More control also creates more places to maintain policy and diagnose failure. For teams choosing after Droid’s release, the useful comparison is the smallest system that can complete their real workflow with a recoverable record of its actions.
| Dimension | Droid 1.0 | Cloudflare Code Mode | Anthropic pattern |
|---|---|---|---|
| Layer | Coding-agent harness | Cloudflare API server | Agent implementation design |
| Execution | Script JavaScript sandbox | Worker isolate | Developer-provided environment |
| Discovery | Tools callable from Script | Search API definitions | Read tool files as needed |
Claim check
Our read Opinion
We favor code orchestration for repetitive operations with explicit success conditions and a manageable recovery path. The strongest reason is a clearer division between judgment and execution, not an impressive token ratio. For an initial deployment, we would prioritize a visible approval boundary and replayable failures over maximizing batch size. We would change our mind if matched workflow tests showed that extra debugging, approvals and recovery consistently erased the savings or reduced accepted-task reliability.
What we're watching
- On November 8, we will check whether Factory publishes reproducible workflow traces beyond its modeled examples.
- On November 15, we will review the three approaches for documented approval placement and partial-batch recovery.
Sources
- Droid 1.0: Building a Frontier Harness · Factory · 29 Oct
- Code Mode: give agents an entire API in 1,000 tokens · Cloudflare · 20 Feb
- Code execution with MCP: Building more efficient agents · Anthropic · 4 Nov