A Manager's Real Dilemma
Last month, a friend of mine who runs a SaaS business invited me for drinks. His product integrates a large model API and serves more than twenty enterprise customers. During quarterly financial settlement, he discovered that AI invocation costs had risen 170% quarter-over-quarter, while revenue barely moved. He wanted to figure out: which customer was burning the money? Which feature had gone out of control? Nobody could answer. The engineers said "the logs have invocation records," but mapping those records to customers, features, and costs would require writing scripts that run for three days.
This isn't a technical problem—it's a governance problem. When AI costs shift from "negligible" to "impacting gross margin," a manager without a usage attribution mechanism is like driving a long-haul trip in a car without a fuel gauge—you only panic when the tank is nearly empty.
Why Usage Attribution Is a Management Problem, Not Just a Technical One
Many teams' first instinct is "have engineering add some logging." But the real difficulty of usage attribution lies in process and collaboration:
First, unclear lines of responsibility. A new frontend feature, a product manager changing prompts, or a customer making excessive calls—three causes of cost spikes, requiring three completely different responses. Without attribution, retrospective meetings turn into finger-pointing sessions.
Second, missing cost perspectives. Engineers see token counts, the boss sees the billing amount, and sales sees "how much quota the customer used." When these three perspectives don't align, there's no basis for pricing and renewal negotiations.
Third, invisible risk exposure. Abnormal growth in a major customer's invocation volume could be business expansion, or it could be prompt injection or freeloading. Without real-time attribution, by the time you discover the problem, the damage is already done.
The essence of usage attribution is tagging every API call with "who is this, for what purpose, and how much did it cost." With these tags, budgets, routing, and rate limiting can all be applied with precision.
Three Implementation Approaches: Attribution and Governance Paths from Coarse to Fine
Approach 1: Tiered API Keys—The Simplest Attribution Granularity
The most straightforward approach is to distribute different API keys by dimension: one key per customer, one key per feature module, one key per environment (dev/test/production).
The benefit is that attribution comes naturally—bills are split by key, so you can see at a glance how much cost each customer or feature contributed. Setting strict limits on development environment keys institutionally prevents low-level accidents like "test code blowing through the production quota."
However, applying directly to model vendors for multiple keys carries management overhead, and you'll have to build the routing, quotas, and alerting for multiple keys yourself. With a gateway service like ThisToken.AI, teams can create and manage multiple keys and channels under a unified entry point, with each channel bound to independent quotas and purpose tags. Attribution and management are handled in a single console, with no need to maintain your own key ledger.
Approach 2: Unified Gateway + Request Tags—A Fine-Grained Cost Ledger
When key tiering isn't granular enough (say you want to know "which step of the prompt pipeline in Customer A's contract review feature costs the most"), you need to tag each individual request: customer ID, feature module, operation type, and operator.
This approach requires all AI calls to go through a unified gateway entry point. The gateway records tags, model, and token consumption while forwarding requests, and converts them into costs. What managers get is a ledger that can be sliced by any dimension: by customer, you know who is losing you money; by feature, you know which module needs prompt optimization; by model, you know whether to shift some traffic to a cheaper model.
The value of ThisToken.AI's gateway in these scenarios is that it merges "recording—pricing—routing" into a single layer. Teams don't need to repeat instrumentation in every business service, nor maintain price conversion logic for each model themselves. For managers, this means the attribution data is inherently trustworthy—it doesn't depend on some engineer remembering to write logs.
Approach 3: Model Whitelists + Tiered Routing—Let Attribution Results Drive Decisions
The endpoint of attribution isn't reports—it's action. When your ledger tells you "Customer A's summarization feature can be fully handled by a low-cost model," you need a mechanism to execute that decision. That's where model whitelists and routing governance come in.
The specific approach is to configure different available model whitelists for different channels/customers:
- High-value customers with high-complexity tasks → high-capability models in the whitelist
- Internal testing, batch processing, and summarization tasks → whitelist limited to low-cost models only
- Sensitive data scenarios → whitelist excludes models from specific regions or of specific types
With ThisToken.AI's managed channels and whitelist configuration, these policies can be enforced uniformly at the gateway layer rather than scattered across business code. This brings two management benefits: first, policy changes go through approval, so no engineer can secretly swap models at midnight and double your costs; second, when a model fails or raises prices, operations only needs to adjust the routing configuration—business teams are unaffected.
This also applies to independent developers: you alone are the entire "collaboration process," and whitelists and channel quotas serve as your self-restraint mechanism, preventing one customer's abnormal traffic from dragging down your entire project.
Budget Governance Checklist
Check off each item on this list before going live:
| Check Item | Question | Suggested Owner |
|---|---|---|
| Attribution dimension definition | Can every call be traced to a customer/feature/operator? | Product + Engineering jointly |
| Key and channel isolation | Do production and test use different keys and quotas? | Engineering lead |
| Per-customer limits | Does each customer have daily/monthly call caps and overage alerts? | Operations |
| Model whitelists | Have available models per channel been approved and documented? | Technical lead |
| Cost reporting cadence | Who reviews the attribution ledger, and how often? Who gets notified of anomalies? | Manager to specify |
| Pricing calibration mechanism | Is attribution data regularly fed back to sales/pricing decisions? | Manager to lead |
| Fallback plans | Has degradation routing for primary model failure or overage been rehearsed? | Operations + Engineering |
The last two items are the most easily overlooked. If attribution data just sits in a dashboard, governance degenerates into post-hoc blame assignment; and a fallback plan that has never been rehearsed is as good as nonexistent.
Conclusion: Get the Accounting Right Before Talking About Growth
Gross margin management for AI services is, at its core, about turning "a fuzzy aggregated API bill" into "clear customer-level costs." The earlier you do this, the lower the cost—trying to retrofit attribution after the bill spirals out of control means facing the awkward reality that historical data can't be retroactively reconciled.
If your team is ready to take this step, start with a unified gateway entry point: register a ThisToken.AI account, create your first rate-limited channel, get the attribution tagging mechanism running, and within a week you'll see your first cost ledger sliced by customer.
Start building your usage attribution system: https://api.thistoken.ai/register
---
Every example in this post runs with a single API key — get yours at https://api.thistoken.ai/register and start in minutes.
Token.AI を試してみませんか?
プロジェクトレベルの API Key を作成し、コンソールでチャネルを有効にして、ルーティング、予算、監査ログを設定しましょう。
注册 ThisToken.AI 并获取 API Key