For two years, model prices mostly went one way: down. That's no longer something to count on. Several current models have scheduled price changes printed right on their providers' pricing pages:
| Model | Today (per 1M tokens) | Scheduled | From |
|---|---|---|---|
| Gemini 4 Argon | $2 input · $10 output · $0.10 cached | $4 · $20 · $0.20 | December 1, 2026 |
| Gemini 3.8 Flash | $0.75 input · $3.75 output · $0.075 cached | $1.50 · $7.50 · $0.15 | January 1, 2027 |
| GPT-5.6 Sol | Promotional pricing | Promotion has no fixed end date | Runs "at least through November 21, 2026" |
Sources: Gemini API pricing and OpenAI API pricing, read October 23, 2026. Standard paid tier, short-context rates.
Same usage, double the cost
Take a fictional customer on a $29/month plan who uses 3M input and 0.6M output tokens a month on Gemini 4 Argon. Nothing about their behaviour changes on December 1:
| Fictional customer | November | December |
|---|---|---|
| Input: 3M tokens | $6.00 | $12.00 |
| Output: 0.6M tokens | $6.00 | $12.00 |
| AI cost | $12.00 | $24.00 |
| AI contribution on $29 | $17.00 | $5.00 |
Contribution drops by 70% with no change in the product. Customers who use more will flip from profitable to loss-making overnight, and you'll only notice if your cost numbers are right on both sides of the date.
Two ways cost tracking gets this wrong
- One price per model, edited in place. Change it on December 1 and every report that recalculates from tokens now prices November at December's rate. Your history quietly doubles.
- One price per model, edited late. Forget to change it and December is undercounted by half, and it looks like your best month for margin.
Both come from the same design flaw: treating a price as a property of the model, when it's a property of the model at a point in time.
Price each call at the rate in effect when it ran
- Store prices as versions with an effective-from instant (and optionally an effective-to).
- When an event arrives, pick the version whose effective-from is the latest one at or before the event's timestamp, not the time you process it.
- Store the cost and the ID of the version used next to the event. Don't recompute it later.
- Never edit or delete a version. A new rate is a new version.
- If no version covers the event, the cost is unknown, not zero and not the nearest price.
This is how AgentMargin's workspace pricing works. Price versions are append-only: PostgreSQL rejects updates and deletes. Each usage event stores the version it was priced with, and adding a new version never reprices events that are already stored.
POST /v1/prices HTTP/1.1
Authorization: Bearer am_YOUR_LOCAL_WORKSPACE_KEY
Content-Type: application/json
{
"model": "gemini-4-argon",
"effectiveFrom": "2026-12-01T00:00:00.000Z",
"inputMicrosPerMillion": "4000000",
"outputMicrosPerMillion": "20000000",
"cachedInputMicrosPerMillion": "200000",
"sourceNote": "ai.google.dev/gemini-api/docs/pricing, read 2026-10-23"
}Amounts are integer USD microdollars per million tokens: $4.00 is 4000000. November events keep resolving to the November version, and events from December 1 resolve to the new one. If the new version is added after December events have already been ingested, those events keep the cost they were stored with. Costs are immutable, so add scheduled prices before the date.
A checklist for the next price change
- Not done: List every model you call, and check its pricing page for scheduled or promotional rates.
- Not done: Record each future rate as a version with its exact effective instant, in UTC.
- Not done: Include the cached-input rate. It changes too, and a missing one should make cached events unknown, not free.
- Not done: Write the source and the date you read it into the version's note.
- Not done: After the change, compare a week of tracked cost against the provider's invoice.
- Not done: Re-check which customers fall below your margin floor at the new rate.
