Attribute cost per feature or customer
Splitting gateways along the boundary you want to measure, so “what did this feature cost us” has an answer.
A provider invoice tells you what you spent. It does not tell you which feature spent it, which customer drove it, or which team to talk to about it — because every request in it was made with the same key.
Salyro can answer that, but only if the question is asked before the traffic runs. This guide is about making that decision deliberately.
The decision comes first
Usage and cost accumulate per gateway. That single fact determines everything else: the breakdown you can read later is exactly the split you configured earlier, and no finer.
There is no retroactive attribution. Traffic recorded under one gateway stays recorded under it, and creating a second gateway afterwards separates what happens next rather than what already happened. Gateway layout is a modelling decision with a deadline.
Choose the boundary you want to measure
Pick the one you will actually be asked about:
| Boundary | A gateway per… | Answers |
|---|---|---|
| Feature | product surface or job | “what does the summariser cost us” |
| Customer | tenant or account | “what does this customer cost to serve” |
| Team | owning team | “which team's spend is growing” |
| Environment | environment | “how much of this is production” |
These compose, and in practice they multiply: a gateway per feature inside production, alongside a separate gateway for development, is a normal layout. See Separate your environments with gateways for that half of it.
The constraint on how far to take it is operational rather than technical. Each gateway carries its own provider credentials and its own keys, so twenty gateways means twenty credentials to rotate. Split where you will genuinely ask the question.
Setting it up
Create a gateway per boundary
Name each one for the thing it measures. The name is what appears beside every figure you read afterwards.
Connect provider credentials to each
Credentials belong to a single gateway and are not shared, so each gateway gets its own — from the same provider account if that is how you are set up.
Issue a key per gateway and route each code path to its own
This is the step that does the actual attribution. A request is attributed to the gateway whose key made it, so the code path that serves a feature has to carry that feature's key.
Read the breakdown
Usage is available by gateway, and within a gateway by model, by provider and over time — so you get both “what did this feature cost” and “what is it spending it on”.
How the number is produced
Salyro counts input and output tokens for each request and computes a cost from an internal price catalogue for that model, with prices kept per period so a past request's cost does not move when a provider changes its rates.
That figure is a measurement, and it is worth being clear about what it is not: the invoice comes from your provider, against your own provider account. Salyro does not bill you for model usage and does not receive the provider's invoice. Expect the two to agree closely and to reconcile them against the provider when precision matters.
What this is not
Rate limits per API key do exist, and they are the one control that applies here — but they cap request rate rather than spend, so they bound how fast a runaway path can cost you money rather than how much.
For what each figure means and how it is derived, see Usage & costs.