FeedDiscussion
Salman Parvez
Self-taught full-stack engineer. Founder of ML Systems, a Rhode Island construction tech company. Shipped a React Native app to both stores
Paid model as fallback rather than default is the whole trick, and it is worth naming why it works: most agent runs are not doing anything that needs a frontier model. Routing, extraction, formatting and the boring middle steps are well within a small model's range, and the expensive calls are a minority you can route to deliberately. The number I would love to see alongside total spend is the fallback rate over time, because that is the metric that tells you whether the arrangement is stable or slowly degrading into always paying. It is also the early-warning signal when a provider changes something upstream. One caution for anyone copying the seven-provider chain: failing over between models is not transparent. Output shape, refusal behaviour and tool-call formatting all shift, so a run that falls through to provider five can complete and produce something the next step cannot parse. Validating each response against a schema on every path is what keeps a cost optimisation from becoming an intermittent correctness bug.
Forty to fifty runs a day for under five dollars is a useful counterweight to the cost guides, and it matches what we see: most agent spend comes from design choices, not from the model price list.
The part I would underline is your list of failures that report themselves as something else. A billing error that looks like a rate limit, or a scheduler that quietly stops, costs more than tokens ever will because nobody notices for days. A per-run record of which provider answered, under what limit, and whether the output was used is cheap to build and pays for itself the first week.
When we scope agent work for clients, that run log is part of the definition of done, not a later nice to have.
The list at the end — billing errors disguised as rate limits, missing credentials, a scheduler that silently stopped — is the part I'd pull out and put first. Every one of those is a failure that reports itself as something else, and the fix isn't a better model, it's a record of what actually happened per run: which provider answered, under what limit, at what time, and whether the scheduler fired at all. Once each run leaves a claim with a source and a timestamp, a scheduler that quietly died shows up as a gap in the record instead of a suspiciously calm week.