Use case
How to reduce AI model costs without rewriting your application
The model your app calls today may not be the cheapest model that would still do the job.
The optimizer surfaces cheaper models that fit a workflow's actual usage pattern; reroute rules then apply that substitution in the request path, so your application code keeps calling the same endpoint while Spendline sends the request to the cheaper model underneath.
How Spendline does this
Because every call already passes through Spendline's proxy, a reroute rule can rewrite which model a request actually reaches without your application changing anything about how it calls the API. The optimizer's suggestions come from the same ledger used for cost attribution, so they reflect your actual traffic mix rather than a generic benchmark.
Why it matters
Swapping a model manually means finding every call site, testing the swap, and shipping a deploy, for a saving that might not even hold once real traffic hits it. Rerouting in the request path means the substitution can be made, measured, and reversed without touching application code.
Frequently asked questions
Does rerouting risk silently degrading quality?
A reroute rule is something you configure deliberately for a specific workflow after reviewing the optimizer's suggestion; it is not an automatic, unreviewed substitution applied everywhere.
Can rerouting cross providers, not just models within one provider?
Reroute rules operate on whichever providers you have proxied through Spendline, so a substitution can move traffic to a cheaper model on a different provider entirely, not only a cheaper tier of the same one.
See where this stands in your own setup
This page describes the mechanism. The 5 minute assessment scores your own attribution, enforcement, and reconciliation setup, so you know exactly which of these problems you actually have today.
Run the 5 minute assessment