If your agent bill looks wrong for a task a search filter could handle, the problem may be the model, not the prompt. A 2026 Rails API test found that splitting planning, implementation and review across four models dropped multi-agent cost from $5.65 to $2.66 on the same specification.
What the multi-agent cost test measured
Multi-agent cost routing assigns each coding task to the cheapest model that can finish it, and a 2026 Rails API test reported $2.66 for a four-model split against $5.65 for one premium model on the same prompt. Both builds targeted the same locadora API specification; only the agent arrangement differed.
The test comes from a July 2026 video by the Brazilian developer channel mano deyvin. The author created two blank Ruby on Rails API projects with the --api flag, pasted the same specification into both, and ran them in parallel inside Traycer, a desktop tool that coordinates multiple coding agents in one workspace.
The two configurations
Each run built the same locadora API spec from a blank --api Rails project; the only variable was how models were assigned to tasks.
| Run | Agent arrangement | Reported cost |
|---|---|---|
| Split | Four models routed per task | $2.66 |
| Single | One premium model | $5.65 |
What the specification covered
The specification was about 100 lines of product rules, mixing domain modelling with technical constraints. It defined the entities and behaviours the agents had to implement, then fixed the tooling and quality bar.
- user, movie, category and subcategory models
- an age-18 restriction on adult categories
- category visibility scoped per user across search, filters and pagination
- a romantic comedy that must appear in both comedy and romance
- a psychological horror film that must sit in horror and in its psychological subcategory
- hidden categories that must not leak through any endpoint
Technical rules covered RSpec tests with 90% coverage, RuboCop, Postgres in Docker, primary keys on every table, database-level integrity, a user identified by an X-User-Id header, and Swagger documentation generated from request specs.
Limits of the evidence
Neither run was a controlled benchmark, so the dollar figures should be read as one developer's recorded session rather than as a measured saving. Three gaps stand out.
- The author states openly that he had not tested the split before recording and assumed it would work.
- The two runs executed simultaneously in the same Traycer session, so load and model latency overlapped.
- No repeat runs or alternate prompts were reported.
Treat the dollar figures as one developer's recorded experience, not an independent study.
FAQ
- Is the $2.66 figure a benchmark result? No. It is a single recorded experience from one developer, not an independent study.
- Were the two runs isolated from each other? No. They ran simultaneously in the same Traycer session, so load and latency overlapped.
- Did both runs use the same specification? Yes. Both blank Rails API projects received the same locadora API specification; only the agent arrangement differed.
- What tooling did the test use? Two
--apiRuby on Rails projects run in parallel inside Traycer, with RSpec, RuboCop, Postgres in Docker and Swagger documentation as specified requirements. - Should I plan a split routing setup around these numbers? Only as an anecdote. The author had not tested the split before recording, so the result should be validated with your own repeated runs.
How task routing split the work between four models
Task routing assigned planning and code review to Claude, complex implementation to GLM 5.2, simple repetitive work to DeepSeek v4 Pro, and access-control auditing to the Fable model. The orchestrator read the brief and produced a ticket breakdown before delegating anything.
Who each model is
Claude is Anthropic premium Claude Code, run through Claude Code in this test. GLM 5.2 is Zhipu AI's multilingual model, and DeepSeek v4 Pro is DeepSeek's coding-focused model; both ran through OpenCode, an open-source terminal coding agent. The transcript names the auditor only as "Fable 5," so this article does not guess at a vendor or version for it. The author routed all four through OpenRouter, an API aggregator that exposes many models behind one billing account, so token spend could be read in one place.
The four-way split
| Model | Assigned work | Served by |
|---|---|---|
| Claude | Planning and code review | Claude Code |
| GLM 5.2 | Complex implementation | OpenCode |
| DeepSeek v4 Pro | Simple repetitive work | OpenCode |
| Fable model | Access-control auditing | OpenRouter |
How the routing played out, in order:
- The orchestrator read the brief.
- It produced a ticket breakdown before delegating anything.
- Planning and code review went to Claude.
- Complex implementation went to GLM 5.2.
- Simple repetitive work went to DeepSeek v4 Pro.
- Access-control auditing went to the Fable model.
All four ran through OpenRouter, so token spend landed on a single billing account. Background on the aggregator model is in OpenRouter's documentation, terminal-agent usage is covered in the OpenCode repository, and per-token pricing for the Claude Code is published in Anthropic pricing page.
FAQ
- Why one model for planning and review? Claude handled both, so the same model checked the plan it helped shape.
- Why give the cheap model only simple work? DeepSeek v4 Pro was reserved for simple repetitive tasks, keeping its cheaper tokens off the hard implementation.
- Why route everything through OpenRouter? It puts all four models behind one billing account, so token spend can be read in one place.
- Who made the Fable model? The transcript names it only as "Fable 5," so no vendor or version is assumed here.