nestonexStart a project How do you stop an AI feature from costing more than it is worth?
Send each step to the cheapest model that can actually do it. Most steps in a pipeline are mechanical and a small model handles them fine; only a few genuinely need the strongest one. Routing by difficulty, with spend metered per step, is usually most of the gap between a viable feature and an abandoned one.
Because it is the easiest thing to build. You pick the best model, wire it to everything, and the feature works. The bill only becomes a problem later, once usage is real.
By then the cost is distributed across dozens of call sites and nobody can say which ones are worth what. The feature gets quietly limited or switched off, not because it failed but because nobody could defend the spend.
Three things, roughly. How deterministic the step is: reformatting, extraction and classification are far more forgiving than open-ended generation. How much context it has to hold at once. And what happens if it gets it wrong.
A step that reformats a known structure can go to the smallest model available. A step making a judgement that shapes everything downstream should not. Most pipelines are mostly the former, which is the whole opportunity.
A budget meter that tracks spend per step is what turns routing from a guess into a control. You find out which steps actually dominate cost, and they are rarely the ones you expected.
Pair it with a cap per user per day. Usage is never evenly distributed, and one heavy user on one day can generate most of a month's spend. A daily cap makes the worst case a known number rather than an open question.
When every step is genuinely hard. A pipeline that is one difficult reasoning call has nothing to route, and the honest answer is that the feature costs what it costs.
It also does not help if you have not measured. Routing chosen by intuition tends to move cheap steps around while leaving the expensive one untouched.
Swift Builder generates a genuinely running website from a chat prompt. An orchestrator plans the steps and writes no code itself, Claude Code runs headless inside a per-project Docker sandbox, and a proxy maps the sandbox dev server out as a live preview.
Cost-aware routing plus per-step metering is what holds a whole site build to a $3 to $5 target. Building a site involves many small decisions and a few hard ones, and paying top rate for all of them is the difference between a product and a demo.
It depends entirely on the mix of steps, but where most of a pipeline is mechanical the saving is usually large enough to change whether the feature is viable. On Swift Builder it is a substantial part of holding an entire site build to a few dollars.
Only if you route a step that needed the stronger model. The point is matching capability to difficulty, not downgrading everything. Reformatting and extraction are largely indifferent to model size; open-ended judgement is not.
Yes, per user per day rather than only watching a global budget. Usage is heavily skewed, so a single enthusiastic user can produce most of a month's cost. A per-user daily cap turns an unbounded worst case into a predictable one.
Measure first. Meter spend per step to find where cost actually concentrates, then look at how deterministic each step is and what a wrong answer costs. Routing chosen without measurement usually optimises the wrong steps.