How do hard budget limits work?
A budget has a warn threshold and a stop threshold. The gateway checks it before routing; a request that would exceed the stop threshold is refused, recorded as blocked by budget and never reaches a provider.
FinOps guide
LLM cost management before the invoice
LLM cost management works best before the invoice. Skyfix enforces budgets for teams, keys, workflows and end users at the gateway, warns as a limit approaches, stops a request that would exceed a hard limit, and records the savings from caching and routing instead of estimating them.
- Budgets at the gateway
- Warn and stop
- Recorded savings
01
Budgets at the gateway
A budget applies to a workspace, a team, a workflow, an end user or a tag, over a daily or monthly window, with a warn threshold and a stop threshold. Budgets are strict by default: the gateway checks the budget after inspection and before routing, so a request that would cross the hard limit is stopped before any provider is called and before any cost is incurred. The budgets view shows how many are enforced, which are over their soft limit, which are at their hard limit and how many requests were stopped.
02
Run-out forecast and alerts
Each budget shows when it will run out at the current rate of spend, so a team sees that it will hit its limit next Tuesday rather than discovering it on Tuesday. Governance alerts fire when a budget is near or at its limit and route to chat, email or webhooks through the same alert configuration as approvals and posture findings.
03
Cutting cost without losing control
Three levers reduce spend inside policy. Response and semantic caches answer repeated requests without a provider call where policy allows. Routing sends a task to the lowest-cost model that is eligible for it, by alias mapping or by Garuda's task classification, and never to a model that policy denies. Promotional pricing from the catalog applies automatically. Each lever produces its own ledger line, so the savings are recorded against the list price rather than estimated from a baseline.
- Cache hits are recorded as hits with the cost avoided.
- A routed-down request records the model chosen and the reason.
- Promotional rates and their savings appear separately from the list price.
04
Agent and tool-loop budgets
An agent that loops over tool calls can spend more in a minute than an application spends in a day. Because MCP tool calls, A2A tasks and skill steps are governed requests, they draw from the same budgets as model calls, and a workflow budget caps an entire agent run across every call it makes. The cost cockpit shows unit cost per session, workflow run, tool call and end user, so a runaway loop is visible as a cost and not only as a log.
05
Evidence for every blocked or downgraded request
A request stopped by a budget, served from cache or routed to a lower-cost model leaves a ledger entry with the budget that applied, the status at the time, the decision and the trace ID. Finance can reconcile the FOCUS export against the ledger; engineering can open the trace and see the budget check on the waterfall.
FAQ
Questions this page answers
Can budgets apply per end user?
Yes. End users are identified per request, so a budget can cap what one person spends through a shared application key, daily or monthly.
How are cache and routing savings measured?
Each cache hit, lower-cost route and promotional price is a separate ledger line against the catalog list price, so savings are recorded per request rather than estimated from a baseline.
Do budgets work with bring-your-own-key providers?
Yes. Bring-your-own-key traffic flows through the same gateway and is priced from the same catalog, so the same budgets, attribution and evidence apply while you keep custody of the provider account.
What happens to a request over budget?
It is stopped at the gateway with a clear refusal, recorded with the budget and trace ID, and counted in the budget's blocked-requests figure. Nothing is sent to a provider.