Forge ·
Introducing Forge
Frontier intelligence at a fraction of the cost. Forge pairs a frontier model’s judgment with faster, cheaper models that do the volume of the work, and brings the whole team to you as one agent.
What Forge is
Forge is a model you pick in Dev404, the same way you pick any other. Behind it is a small team: a frontier model that leads, and faster models that work under it. You don’t manage that team. You give Forge a task, and you get one agent in one session that plans, builds, tests and reports, with its running cost shown as it works.
The idea behind it is simple. On a typical engineering task, most of the work isn’t the hard thinking. It’s reading code, running tests, writing the parts that follow from decisions already made, and checking the result. A frontier model is worth its price for the plan, the interfaces and the judgment calls. For everything else it’s more model than the job needs. Forge keeps the frontier model on the parts that need it, and hands the rest to models that are faster and cost far less.
Forge is included with Dev Pro and above.
How it works
The lead decides
The lead is a frontier model. It reads your request and the codebase, decides the approach, and splits the work into well-scoped pieces. It keeps the decisions that need judgment for itself: the architecture, the user experience, anything ambiguous. Those are settled before any piece is handed out, so the models that build never have to guess.
The contract comes first
When pieces share an interface, such as an API and the app that calls it or a schema and its queries, the lead writes the contract as code before anyone starts: the shared types, and failing acceptance tests that pin down how it should behave. Every piece starts from that contract and can’t change it. Each piece also owns a set of files, so pieces working in parallel never step on each other.
Each piece goes to the right model
Forge works in three tiers:
| Tier | Model | Takes |
|---|---|---|
| Scout | A fast, low-cost model | Reading, searching, running tests and checks, and mechanical edits a brief fully specifies |
| Build | A strong coding model | Code within decisions the lead has made: features, endpoints, components, tests and fixes |
| Lead | The frontier model | Pieces that need judgment: an architectural choice, an unclear requirement, a bug whose cause isn’t known |
The lead picks a tier for each piece, and a router can move a piece up when it needs more than the lead expected. It never moves one down. Independent pieces run in parallel, each in its own copy of the repository, and their work is applied back to the lead’s checkout when they finish.
Nothing stays stuck
A supervisor watches each piece while it works. If a model starts going in circles, rewriting the same file, repeating a failing command or drifting from its brief, it is steered back on course. If it is still stuck, it first asks the frontier model for a diagnosis, and only moves up a tier if that doesn’t help. Most stalls are cleared by a short consult rather than by handing the whole piece to a more expensive model.
Every result is checked before the lead sees it
When a piece comes back, it goes through a verification gate. If there is a contract, the contract’s tests decide: the piece passes only if they pass and it stayed inside its files. Without one, the result is judged against its brief using the evidence, meaning the checks that ran and the changes themselves rather than the model’s own account of them. A result that falls short is sent back once with what’s missing. One that still isn’t clearly right goes to an independent reviewer.
The lead owns the finish
Once the pieces are in, the lead runs the project’s checks on the combined result itself. Its final answer is then checked against what you asked for and reviewed in full against the evidence. Only then does Forge tell you it’s done.
One agent, one session
None of this shows up as a crowd of agents. Every action, the lead’s and the team’s, appears in your session as Forge’s own, the way it would for any single model, and Forge talks about the work as its own. You see one running cost too, updated as the work happens.
Where the savings come from
The savings come from where the tokens go. The frontier model spends its tokens on understanding, deciding and reviewing. The volume, reading files, running commands and writing code to a clear spec, runs on models that cost a fraction as much per token.
- Each model keeps its own cached context, so handing a piece off never throws away the lead’s.
- Small fixes stay with the lead when explaining them would take longer than making them.
- Every task has a spending target. As a task approaches it, Forge leans harder on the cheaper tiers and stops reaching for the frontier model.
Every decision is measured
Each decision Forge makes about a task is recorded: which tier took a piece, when a model was steered or consulted, whether a result passed the gate. Each one is later labelled with what actually happened. Did the piece finish? Did the lead’s checks pass on it? Did the final review agree? That record is what we tune Forge from, so routing gets better at picking the cheapest model that will succeed and the gate gets better at catching work that isn’t done.