Hard budget caps are easy to build and unpleasant to receive. The customer is usually in the middle of real work when the cap hits, and the product suddenly stops. Every hard cap that fires without warning becomes a support ticket and sometimes a churn conversation. There are better options between unlimited and off.
Three thresholds instead of one
We recommend three thresholds per tenant budget. At 80% the gateway emits a soft-cap webhook, which your product can turn into an in-app notice or an email to the account owner. At 90% the gateway starts routing requests to a cheaper fallback model. At 100% the gateway refuses with a quota response that your UI handles with an upgrade path, not an error screen.
Each threshold is a policy on the tenant's tier, so free, pro and enterprise tenants can have different budgets and different fallback behavior without any code changes in the application.
The fallback math
Consider a pro tenant with a $200 monthly model budget, on an assistant whose typical call is 12,000 input tokens and 800 output tokens. On Claude Sonnet 4.5 a call costs $0.0480. On Claude Haiku 4.5, at $1.00 input and $5.00 output per 1M, the same call costs $0.0160.
The first 90% of the budget buys 3,750 Sonnet calls. If the gateway refused at that point, the customer would be locked out. With a fallback, the last 10% of the budget buys 1,250 Haiku calls, so the customer keeps working for the rest of the month and the tenant never exceeds $200 of COGS.
Which features should degrade
Not every request should fall back. A cheaper model is usually fine for classification, extraction, routing and short replies. It is usually not fine for the one feature the customer bought the product for. Use the X-PalmSouq-Feature header to scope fallback rules: degrade the auto-tagging feature at 90%, keep the drafting feature on the frontier model until 100%, and show an upgrade prompt after that.
quotas:
tier: pro
monthly_budget_usd: 200
soft_cap:
at_percent: 80
webhook: "https://api.example.com/hooks/quota"
fallback:
at_percent: 90
features: ["auto_tag", "summarize"]
chain: ["claude-sonnet-4.5", "claude-haiku-4.5"]
hard_cap:
at_percent: 100
respond: 429Tell the user what changed
Silent degradation erodes trust when users notice quality changes they cannot explain. The gateway adds a response header naming the model that actually served the request, so the product can show a small notice such as: you are on the faster model for the rest of this billing period, upgrade for full access. That one sentence turns a cost control into an upgrade path.
Rollout checklist
- Meter for two weeks and set budgets from real tenant cost, not guesses.
- Enable the 80% webhook first and confirm your product shows the notice.
- Pick one or two low-risk features for fallback and compare user feedback before and after.
- Only then enable the 100% hard cap, with the upgrade flow ready.
Measuring whether it worked
Three numbers tell you whether the policy is doing its job. The first is the share of tenants that reach the 80% notice in a month; if it is above roughly one in ten, your budgets are set too low for the plan price and the notice becomes noise. The second is the conversion rate from the notice or the fallback banner to an upgrade or an overage opt-in. The third is support tickets that mention quality after a fallback, which tells you whether the fallback model is acceptable for the features you scoped.
PALM SOUQ reports all three per tier in the quota view, next to the COGS each tier actually incurred, so product and finance look at the same page when they adjust the thresholds.
Nisha Pillai
Head of Customer Engineering, PALM SOUQ
BITS Pilani. Previously solutions architect at Wipro for generative AI rollouts. Runs onboarding, breaker tuning workshops and the 15-minute demo.