On this page · 12 sections
- The problem in one paragraph
- Step 1: decide what you are actually charging for
- Step 2: instrument the meter before you price anything
- Step 3: run the arithmetic on real rates
- Step 4: take the discounts that are already on the table
- Step 5: cap the user who costs 100 times the average
- Step 6: write the repricing clause before you need it
- India-specific considerations
- What good looks like after 90 days
- FAQ
- How eCorpIT can help
- References
Summary. On 30 July 2026 OpenAI cut GPT-5.6 Luna by 80%, to $0.20 per million input tokens and $1.20 per million output tokens, and cut Terra by 20%, to $2.00 and $12.00. Thirty-two days later, on 1 September 2026, Anthropic's introductory rate for Claude Sonnet 5 expires and the model moves from $2 per million input and $10 per million output to $3 and $15, a 50% rise. Two of the three largest model vendors moved their published rates in opposite directions inside five weeks. If your AI feature is priced as a flat per-seat add-on, both moves land straight on gross margin, and neither one reaches the customer. Salesforce showed the alternative in its results for the fiscal year ended 31 January 2026: it reported processing more than 19 trillion tokens to date, up 5x year over year, and invented a billing unit above the token, the Agentic Work Unit, with 2.4 billion delivered. This is a working guide to metering an AI feature, choosing the unit you charge for, running the margin arithmetic on real published rates, and capping the user who consumes 100 times the average.
The problem in one paragraph
A per-seat subscription assumes each seat costs roughly the same to serve. AI features break that assumption. Two users on the same plan can differ by two orders of magnitude in tokens consumed, because one asks three questions a week and the other has wired your feature into a nightly script. Under a flat fee, the heavy user is subsidised by everyone else, and your cost of goods sold moves every time a vendor changes a rate you do not control. The fix is not complicated, but it has four parts that have to be built together: an event stream you can meter, a billable unit customers understand, a price with headroom for rate changes, and a cap.
Step 1: decide what you are actually charging for
Three units are in use across the market, and they trade off differently.
| Billable unit | What the customer sees | Where it breaks |
|---|---|---|
| Raw tokens | Direct pass-through of vendor pricing; easy to reconcile against your bill | Customers cannot forecast spend, because they cannot predict token counts before running the task |
| Actions, credits or work units | A countable business event: one document summarised, one ticket resolved, one agent run | You absorb variance inside each unit; a hard task and an easy task cost you differently but bill the same |
| Outcomes | A resolved ticket, a booked meeting, a qualified lead | Attribution disputes, and revenue that arrives long after the compute cost |
| Seats plus an included allowance | Familiar to buyers, predictable revenue | Overage design becomes the whole product decision; the allowance is where margin lives or dies |
| Compute time | Session-hours or container-hours, as Anthropic bills Claude Managed Agents at $0.08 per session-hour | Punishes your own latency improvements unless you reprice |
Salesforce's answer is the second row, and it is instructive because the company published the arithmetic behind it. Marc Benioff, Chair and CEO of Salesforce, said on 25 February 2026: "We've consumed nearly 20 trillion tokens, and converted them into more than 2.4 billion agentic work units to date, moments where AI wasn't just reasoning, it was delivering real work." The company reported Agentforce annual recurring revenue of $800 million, up 169% year over year, across more than 29,000 deals. The token is the input cost; the Agentic Work Unit is the thing on the invoice. That gap is where a vendor price change gets absorbed.
The practical test for choosing a unit: can a customer estimate next month's bill within about 20% before they run anything? If not, the unit is too close to the token.
Step 2: instrument the meter before you price anything
You cannot price what you have not measured, and retrofitting a meter after launch means guessing at your own history. Emit a metering event for every billable action, and record five fields at minimum: the customer or workspace ID, the billable unit count, the model and route used, the input, cached-read and output token counts as returned by the provider, and a timestamp.
Both major providers return the numbers you need in the response. Anthropic's usage object separates input_tokens, output_tokens, cache_read_input_tokens and cache_creation_input_tokens, and adds a server_tool_use block that counts server-side tool calls such as web_search_requests. Store all of them. Aggregating only total tokens destroys your ability to see whether a margin problem is caused by volume, by a cache-hit rate that fell, or by a routing change.
On the billing plumbing, Stripe charges 0.7% of Billing volume on its pay-as-you-go plan, with annual tiers at $620, $1,500, $2,950 and $5,750 per month covering up to $100,000, $250,000, $500,000 and $1,000,000 of monthly Billing volume respectively, and 0.67% on volume above the tier. The Meters API is included in Billing pricing with up to 100 million events per month, which is enough for most products if you meter the business action rather than every token. Stripe now routes advanced usage-based billing to Metronome, which it acquired and sells as a Stripe product. Card processing sits on top at 2.9% plus 30 cents per successful charge.
Budget for that stack when you set price. A feature priced at a 40% gross margin before payment fees is at roughly 36% after them.
Step 3: run the arithmetic on real rates
Here is the same workload costed against published August 2026 rates. The workload: a support-assistant feature handling 100,000 conversations a month, at roughly 3,700 tokens per conversation, which is the figure Anthropic uses in its own customer-support worked example. Split it 3,000 input and 700 output for the calculation.
| Route | Input cost | Output cost | Vendor cost for 100,000 conversations |
|---|---|---|---|
| Claude Haiku 4.5 at $1 / $5 per MTok | 300M tokens | 70M tokens | $650 |
| GPT-5.6 Luna at $0.20 / $1.20 per MTok, after the 30 July cut | 300M tokens | 70M tokens | $144 |
| GPT-5.6 Luna at the pre-cut $1.00 / $6.00 per MTok | 300M tokens | 70M tokens | $720 |
| Claude Sonnet 5 at the introductory $2 / $10 per MTok | 300M tokens | 70M tokens | $1,300 |
| Claude Sonnet 5 from 1 September 2026 at $3 / $15 per MTok | 300M tokens | 70M tokens | $1,950 |
| GPT-5.6 Terra at $2 / $12 per MTok, after the 20% cut | 300M tokens | 70M tokens | $1,440 |
Anthropic publishes its own version of this calculation and lands at roughly $37.00 per 10,000 tickets on Haiku 4.5. The table above works out to $65 per 10,000 on the same model, and the gap is worth understanding rather than averaging away: it comes entirely from the assumed input-to-output split. Anthropic's example assumes proportionally less output than the 3,000-to-700 split used here. Output tokens cost five times input on Haiku 4.5, so the split, not the total, drives the bill. Measure your own ratio before you price.
Now put a price against it. Charge $0.05 per resolved conversation and 100,000 conversations bills $5,000. On the Luna route the vendor cost is $144, a gross margin of about 97%. On the September Sonnet 5 route it is $1,950, a margin of about 61%. Same price, same product, same month. The difference is entirely a routing and rate-card decision, and it is why the unit on the invoice must not be the token.
Three things fall out of that table. The cheapest route is not automatically the right one, because a weaker model that needs two attempts costs more than a stronger one that needs a single pass. A 50% rate rise on a route you depend on removes roughly a third of the margin at these ratios. And a price cut on a competitor's model is a reason to re-run the routing decision, not a reason to cut your own price.
Step 4: take the discounts that are already on the table
Both vendors publish structural discounts that most teams underuse.
| Mechanism | Anthropic | OpenAI |
|---|---|---|
| Cache read | 0.1x base input price; pays for itself after one read on the 5-minute cache (1.25x write) or two reads on the 1-hour cache (2x write) | Cached input published as a separate, lower column on every model row |
| Batch | 50% off both input and output; Claude Opus 5 drops from $5 / $25 to $2.50 / $12.50 per MTok | Batch tier published at half the standard rate, for example GPT-5.6 Sol at $2.50 / $15.00 |
| Flexible or slower tier | Not offered as a separate tier | Flex processing published at half the standard rate |
| Speed premium | Fast mode for Opus 5 and Opus 4.8 at $10 / $50 per MTok, not available with the Batch API | Priority processing published at roughly double the standard rate |
| Stacking | Batch and prompt caching discounts can be combined; multipliers stack with data residency | Tiers are published per model and per processing class |
The caching multipliers are worth stating precisely, because the payback point is not obvious. A 5-minute cache write costs 1.25x base input, a 1-hour cache write costs 2x, and a cache hit costs 0.1x. So a system prompt read twice within five minutes is already cheaper cached. A system prompt read once an hour is not.
There are two traps here. Anthropic notes that Claude 4.7 and later models use a newer tokenizer that "produces approximately 30% more tokens for the same text," so a like-for-like per-token comparison across model generations understates the newer model's cost. And on Anthropic's first-party API, requesting US-only inference through inference_geo applies a 1.1x multiplier across input, output, cache writes and cache reads. If your customer contract promises US-only processing, that 10% is a cost of the promise and belongs in the price.
Step 5: cap the user who costs 100 times the average
Every usage-priced product eventually meets an account that generates more cost than revenue. Design for it before launch, not during the incident.
A workable set of controls, in the order they should fire:
- A per-request ceiling. Anthropic exposes
max_content_tokenson the web fetch tool precisely so a single fetch cannot pull a 500 kB PDF worth roughly 125,000 tokens into context. Set equivalent limits on any user-supplied input.
- A per-customer daily budget in your own metering layer, evaluated before the provider call, not after the invoice.
- A soft cap that degrades rather than blocks: route the account to a cheaper model once it passes a threshold, and tell the customer that is what happened.
- A hard cap with a human in the loop for enterprise accounts, because silently cutting off a paying customer is worse than an unexpected support ticket.
- Alerting on margin per customer, not just total spend. Total spend rising with revenue is health; one account's cost curve detaching from its revenue curve is the thing to catch.
Server-side tools deserve their own line in the budget because they are billed outside token pricing. Anthropic charges $10 per 1,000 web searches on the Claude API on top of standard token costs, and bills code execution at $0.05 per hour per container beyond a monthly allowance of 1,550 free hours per organisation, with a five-minute minimum per execution. A feature that quietly runs three searches per request has a floor cost of 3 cents per request before a single token is counted.
Step 6: write the repricing clause before you need it
Model prices are going to move again. Put the mechanism in the contract and the product at launch:
- Publish the price in your unit, never in tokens, so a vendor's rate card is not visible on your invoice.
- State a review cadence in the terms, for example a quarterly price review with 30 days' notice, rather than promising a fixed rate indefinitely.
- Keep a routing layer between your product and the provider so a rate change is a configuration change, not a release. The same argument applies as in any hybrid model routing decision: the value of the abstraction shows up on the day a price moves.
- Track cost per unit as a first-class product metric next to activation and retention, and review it monthly. A margin that erodes 2 points a month is invisible in a quarterly review and obvious in a monthly one.
- Re-run the routing decision on every vendor announcement, including the ones that lower prices. The 30 July cut made Luna viable for workloads that were previously routed to a mid-tier model; a team that never re-ran the comparison kept paying the old rate for no reason.
The discipline is unglamorous and it is the whole game. Pricing an AI feature is not a launch decision, it is a monthly operating routine.
India-specific considerations
Two practical points for teams building from India.
Metering events are personal data when they are tied to an identified user. Under the Digital Personal Data Protection Act 2023, a usage log that records which employee at a customer ran which query, and retains it indefinitely for billing history, is processing that needs a lawful basis and a retention limit. Separate the two stores: keep an aggregate, customer-level meter for billing that carries no per-user identifier, and a short-retention per-user log for debugging. That split also makes the billing meter far cheaper to keep, which matters when Stripe's included allowance is 100 million events a month.
Second, price in the customer's currency and cost in dollars, and hold the gap deliberately. Model rates are published in USD by both Anthropic and OpenAI. A rupee-denominated price list against a dollar-denominated cost base carries currency risk on top of vendor-rate risk, and it compounds: a rate rise and an adverse exchange rate move in the same quarter can take a 60% margin into the forties without a single product change. Teams that already run this discipline on cloud spend, as covered in attributing AI cost to the team that spends it, can reuse the same reporting; the unit changes, the mechanics do not.
What good looks like after 90 days
A team that has done this well can answer six questions from a dashboard rather than a spreadsheet: what does one billable unit cost us today; what did it cost 30 days ago; which customers have a negative unit margin; what share of input tokens are cache reads; what would a 50% rate rise on our primary route do to blended margin; and how long would it take to move traffic to the fallback route. If any of those needs a manual query, the meter is not finished.
FAQ
How eCorpIT can help
eCorpIT builds the metering, routing and margin reporting behind AI features so a vendor rate change is a configuration change rather than a quarter-end surprise. Our senior engineering teams instrument the billable unit, wire per-customer budgets and caps before launch, and set up the cost-per-unit reporting most teams only build after the first bad month. We are an ISO 27001:2022 certified, CMMI Level 5 organisation, and we design applications aligned with DPDP Act requirements so usage logs are separated from billing meters. If you are pricing an AI feature now, talk to us, or see how we approach AI gateway and model routing and comparing the current frontier models.
References
- OpenAI, Pricing, OpenAI API documentation.
- OpenAI Developer Community, Announcing a major price drop for 5.6 Terra and Luna and Fast mode for 5.6-Sol, 30 July 2026.
- Anthropic, Pricing, Claude Platform documentation.
- Anthropic, Prompt caching, Claude Platform documentation.
- Anthropic, Batch processing, Claude Platform documentation.
- Anthropic, Customer support agent guide, Claude Platform documentation.
- Salesforce, Salesforce Delivers Record Fourth Quarter Fiscal 2026 Results, 25 February 2026.
- Stripe, Stripe Billing pricing.
- Stripe, Usage-based billing, Stripe documentation.
- Stripe, Meters, Stripe API reference.
Last updated: 3 August 2026.