What goes into every estimate.
An AI bill depends on how you buy each model, how your app chains its calls, and which model each step really needs. Here is how much of that Infermaven reads, models and shows you, and when each number was counted.
Token prices are the easy part. We track every way you can buy a model.
What a model really costs depends on how you buy it: batch or on-demand, provisioned or pay-as-you-go, which tier, which region, which host. Our agents read vendors' own pricing pages every morning so your estimate reflects all of it.
- 20
- sellers' own pricing and model pages read by our agents every morningmeasured Oct 14, 2026
- 1,291
- seller-model listings tracked, because the same model is priced differently on every host2026-09-11 to 2026-10-14, 19 sweep runs
- ~950
- individual prices re-read from vendor pages in a single daymeasured Oct 13, 2026
- 37,521
- lines in one cloud price feed, parsed by code a few times a daymeasured Oct 14, 2026
What we price, for every model on every host
On-demand
Input, output and cache rates per host
Batch
Batch rates per model and host
Provisioned
PTU, GSU, MU and DBU hourly rates by commitment term
Service tiers
Standard, priority and flex where offered
Long context
Premiums above each vendor's context threshold
Regions
Global, multi-region and regional premiums
Billing units
DBUs and platform credits, with the dollar rate stated
Dates
Promo end dates, scheduled price steps and retirements
- Every morningAgents read each seller's own pricing and model pages.
- Through the dayCode re-reads machine-readable vendor price feeds.
- Before a price movesA person reviews and approves the change.
Coverage varies by seller. Prices read are not all confirmed against the catalogue yet, and each price in Infermaven shows when it was last confirmed against the vendor.
Your bill is not one model call. We price the whole app.
A production app chains retrieval, routing, retries, agent loops and parallel calls, with traffic that peaks. Infermaven models each of those parts, so the estimate matches what you will actually run, starting from defaults anchored to public production data.
- 1,844
- published LLMOps case studies our app architecture was checked againstmeasured Oct 14, 2026
- 10
- workload shapes to start from, from chat and RAG to agents and batch
- 21
- agent frameworks profiled for hidden token overhead, 4 measured from source
- 54
- default assumptions, each graded for how well it is sourced
What we model, beyond the token price
Routing and cascades
Cascade, fallback, canary and tier or custom splits
Parallel branches
Fan-out to several models, then join the results
Multi-phase pipelines
Up to 5 phases, each with its own model and tokens
Throughput and peaks
Steady, variable or spiky traffic, sized for the peak
Harness overhead
Tokens your agent framework adds to every call
Non-model nodes
7 kinds, from warehouses and human handoff to eval sinks and alerting
Delivery modes
On-demand, batch, provisioned, flex and priority
Workload profiles
Ready-made shapes with 22 sizing inputs you can change
- Token sizesAnchored to Microsoft's public Azure LLM inference traces.
- Load shapes and agent loopsFrom published research: Splitwise, DynamoLLM, AgentBench, SWE-bench, WebArena.
- Your numbers winEvery default is labelled with its source, and you replace it with your own.
Request volumes start as estimates until you enter yours. Harness overhead is measured for 4 of 21 frameworks, and the rest start at zero. The grading behind the 54 defaults is on workload assumptions & provenance.
Not every step needs a frontier model. Price each phase on the model it needs.
Most workloads are a chain of simpler jobs: retrieve, extract, classify, check, summarize. Infermaven breaks a workload into phases, shows public benchmark evidence for the job each phase does, and prices each one on the model and delivery mode you choose.
- 69
- models with public benchmark scores shown next to their pricesEpoch AI snapshot Oct 8, 2026
- 6
- named benchmarks, from Epoch AI, covering reasoning, math, code and long context
- 10
- workload types, each mapped to the public benchmark closest to its job
- 5
- routing policies, from cascades to tier splits, priced phase by phase
Ways to break a frontier workload apart
Retrieve, then answer
A light retrieval step feeds a stronger answer step
Extract, then validate
A cheap model extracts; a check catches its misses
Plan, act, summarize
Reserve the strongest model for planning only
Cascade
Try a smaller model first and escalate when needed
Tier split
Send each share of traffic to the tier it needs
Fallback and canary
Keep a backup model, or trial a new one on a slice
Mode per phase
Batch the offline phases, provision the steady ones
Compare options
See cost options side by side before you commit
- 1. SplitBreak the workload into phases, from a starter template or your own design.
- 2. MatchFor each phase, compare models on the benchmark that fits its job, with prices alongside.
- 3. PriceCost every phase on its model and delivery mode, then compare against one model for everything.
Savings depend on your workload: Infermaven shows the modelled difference, not a promised one. Benchmarks: GPQA Diamond, OTIS Mock AIME, FrontierMath, SWE-bench Verified, Terminal-Bench, Fiction.LiveBench 120k. Data from Epoch AI, shown with attribution.
Every figure has a date. None of them is typed in.
Every price in Infermaven carries the day it was last checked against the vendor, and so does every number on this page. A quote that draws on several prices shows the oldest date among them, never the newest.
Inside the product, every price shows its age
Studio and the Model Explorer put one of five labels beside every rate. These are the real labels, produced by the same code, on example dates. Hover one in the product and it tells you exactly what we know.
- verified 3h ago
Checked against the vendor's own page within the last 24 hours, which is our target for every price.
on hoverWe checked this rate against the provider at 20:39 UTC on Oct 15, 2026, 3h ago.
- verified Oct 3
Checked, but more than a day ago. Probably still right, and the label says we cannot promise it.
on hoverWe last checked this rate on Oct 3, 2026, 12 days ago. Our target is 24 hours. The price is probably still right, but we cannot promise it.
- verified Aug 21
Last checked more than 30 days ago. Re-verify it before you put it in front of a CFO.
on hoverWe last checked this rate on Aug 21, 2026, 55 days ago. That is more than 30 days. Re-verify it before you quote this number.
- not checked
A real vendor rate we have no check on record for. Grey, not red, because nothing decayed.
on hoverWe have not verified this rate against the provider yet. The price comes from our seeded catalogue. Treat it as a close estimate, not a confirmed quote.
- unverified
Part of the price comes from our own multiplier, on a tier the vendor sells but publishes no rate for.
on hoverPart of this price uses our own multiplier, not a rate the provider published. The provider does sell the tier. standard: Oct 15, 2026. batch: our multiplier, no published rate.
The figures on this page
Figures counted from the product, like workload shapes, frameworks and benchmarks, are read from its own code each time this page is built, so they cannot fall behind it. The figures below come from outside the code. Each one carries the day it was measured and how old it may get, and a scheduled check fails the moment one is past it.
“Checked and updated” is how often each number is observed and how its value here is refreshed. The last column is only the oldest a count may get before our check fails. Prices themselves are checked far more often: our agents read every seller's pricing page each morning, and code re-checks catalogue prices against the vendors a few times a day.
| Figure | Value | Measured | How | Checked and updated | Count expires after |
|---|---|---|---|---|---|
| sellers' own pricing and model pages read by our agents every morning | 20 | Oct 14, 2026 | Sellers in the morning sweep's seller matrix for that day. 19 were read and 1 was not reached. | Every morningThe sweep reads every seller daily. This count is re-taken from its files at least monthly. | 30 days |
| seller-model listings tracked, because the same model is priced differently on every host | 1,291 | Oct 14, 2026 | Distinct seller plus model identifier pairs across every seller-matrix file in the window. | Every morningGrows with each daily sweep. This count is re-taken from the sweep's files at least every two weeks. | 14 days |
| individual prices re-read from vendor pages in a single day | ~950 | Oct 13, 2026 | Approximate count of individual price values read in the 2026-10-13 morning sweep, across 216 priced offerings. Prices read, not all confirmed against the catalogue. | Every morningEach morning's sweep re-reads the prices. This count comes from one day's sweep and is re-taken at least monthly. | 30 days |
| lines in one cloud price feed, parsed by code a few times a day | 37,521 | Oct 14, 2026 | Items returned by Azure's retail price feed in one full sweep by the scheduled parser (38 pages). | A few times a dayThe parser reads the whole feed two to three times a day. A weekly check compares this figure with the latest full run. | 14 days |
| published LLMOps case studies our app architecture was checked against | 1,844 | Oct 14, 2026 | Case studies in ZenML's LLMOps Database the cost architecture was checked against: 1,844 checked by Neel before 2026-10-14, then every case study added since, reviewed monthly by a scheduled agent. ZenML listed 2,177 on Oct 14, 2026; 0 case studies are in the review ledger. | MonthlyA scheduled agent reviews every case study added to the corpus since the last run and raises this count by the number it checked. | 35 days |
| of 219 live price rows re-confirmed against the seller's own published page within 24 hours | 122 | Oct 15, 2026 | Current rows in offering_price on production that are IN EFFECT today (effective_from on or before today, effective_to null or later) and whose last_verified_at is under 24 hours old: 122 of 219, 56%. Corroborated from the pipeline's own side, which logged '122 of 362 offered rate(s) stamped' the same day - the catalogue read and the run log agree at 122. The other 97: 68 carry no source page for a verifier to re-read at all (PIPE-55, #606), and the rest were last confirmed more than a day ago. An earlier draft of this figure divided by 231, which counted 12 scheduled FUTURE price steps as live. | Every six hoursA scheduled verifier re-reads each seller's published prices and advances the date on every row it can confirm. The published count is re-taken from the database by hand at least fortnightly, because unlike the other figures here this one can FALL silently if the pipeline stops. | 14 days |
Want the method rather than the counts? How it works shows which of the four registers every number on a quote belongs to, and how to check us.
Price your AI before you build it.
Map your app, pick a model for each phase, and see the whole bill with an honest range. Free, no account needed.