# OptimToken by OptimNow - Full Reference ## URL map Primary site: https://optimtoken.optimnow.io/ LLM pricing page: https://optimtoken.optimnow.io/ Cloud compute page: https://optimtoken.optimnow.io/compute Per-model pages: https://optimtoken.optimnow.io/models/{provider}/{model} — one static HTML page per model in the catalogue (262 on 2026-08-23), each carrying the full rate card, cost per request for the 8 use-case profiles, comparable models and Product/FAQPage/BreadcrumbList JSON-LD. Both path segments are slugified: lowercase, non-alphanumerics collapsed to "-" (e.g. /models/anthropic/claude-opus-4-5). Readable without JavaScript Compare tool: https://optimtoken.optimnow.io/compare — any 2-4 models side by side. Prebuilt head-to-head pages at /compare/{model-a}-vs-{model-b} Price barometer: https://optimtoken.optimnow.io/barometer — every change of 1% or more in the price we quote over the last 7 days, blended 30/70 before and after, in two parts: price changes, and moves flagged as a change of quoted host or an outlier listing. Most models are sold by several hosts at different rates and the site quotes one of them, so a flagged move is a change in the quoted figure, not evidence that a host changed its price. Also on the page: an index of the average quoted price since tracking began, the rules behind the figures, and the stealth-model watch list Weekly barometer pages: https://optimtoken.optimnow.io/barometer/weeks — one permanent page per completed ISO week at /barometer/{year}-w{week} (e.g. /barometer/2026-w40), readable without JavaScript Barometer RSS feed: https://optimtoken.optimnow.io/barometer/feed.xml — one item per week Guides index: https://optimtoken.optimnow.io/guides Guides: - [ARM against x86: what Graviton, Ampere and Axion save](https://optimtoken.optimnow.io/guides/arm-against-x86): The ARM discount clouds advertise is a discount against Intel. Measured at matched vCPU and memory, it halves against AMD. Current prices. - [Batch API economics: when the -50% applies](https://optimtoken.optimnow.io/guides/batch-api-economics): Batch APIs cut LLM token prices roughly in half, but only for async workloads and only where a batch rate is published. Worked examples, current prices. - [Vision, audio, agents: what each capability adds to the bill](https://optimtoken.optimnow.io/guides/capability-premium): What image input, audio and tool use add to an LLM bill, measured within each model maker's line-up and across the catalogue, and the shortlist each leaves. - [Context windows: what a million tokens costs to fill](https://optimtoken.optimnow.io/guides/context-window-economics): A million-token context window is a spec-sheet capability and an invoice line. What one full prompt costs across the catalogue, and what re-reading it costs. - [The cost of reasoning: what thinking models charge for output](https://optimtoken.optimnow.io/guides/cost-of-reasoning): Reasoning tokens are billed as output tokens, where prompt caching cannot reach them. What a thinking budget costs across the catalogue, at current prices. - [How we compute cost per request](https://optimtoken.optimnow.io/guides/cost-per-request-methodology): The exact formulas behind the list-price and after-discounts columns: token profiles, cache and batch rules, what the numbers exclude and where they mislead. - [LLM API pricing statistics: cheapest and median](https://optimtoken.optimnow.io/guides/llm-pricing-statistics): How many LLM APIs carry a token price, which are the cheapest and the dearest, and the median price per million tokens by tier and by licence. Rebuilt daily. - [Open weights against proprietary APIs: the cost gap in numbers](https://optimtoken.optimnow.io/guides/open-weights-vs-proprietary): Open-licensed models undercut proprietary APIs at matched quality across most of the range, but the open catalogue stops below the top tier. Live prices. - [Prompt caching: the discount nobody budgets for](https://optimtoken.optimnow.io/guides/prompt-caching-economics): Cache reads bill at a fraction of the input price, but the saving that reaches the bill is far smaller than the headline. Break-even by use case, live prices. - [Quality per dollar: the models that beat their price class](https://optimtoken.optimnow.io/guides/quality-per-dollar): A model's price class comes from its rate card, not its quality. Measured against Arena scores, most of the catalogue has a cheaper equal. Current prices. - [Bedrock, Vertex, Azure or direct: what the channel changes](https://optimtoken.optimnow.io/guides/where-to-run-a-model): The same model is sold by its model maker and by the hyperscalers. The token rate is identical on most comparisons; regions and commitment terms are not. MCP server docs: https://optimtoken.optimnow.io/mcp Machine-readable API spec: https://optimtoken.optimnow.io/openapi.json Complete URL list: https://optimtoken.optimnow.io/sitemap.xml The block between GUIDES-START and GUIDES-END is regenerated by scripts/prerender.mjs from scripts/guides/*.mjs on every build, so it cannot fall behind the published set the way a hand-kept list did. ## Product purpose OptimToken is a web app for comparing LLM API pricing and cloud compute pricing. It is designed for engineering, procurement, finance, and FinOps teams that need side-by-side cost analysis without building spreadsheets by hand. ## LLM pricing page ### Coverage - Hundreds of models when live provider data is available (exact count: meta.total in /api/llm-models) - Static fallback data for local development and API failures - Providers include OpenAI, Anthropic, Google, Meta, DeepSeek, Mistral, xAI, Cohere, Amazon, Alibaba, AI21 Labs, 01.AI, Perplexity, Inflection, Zhipu AI, and more ### Categories (price tier) - Frontier - Mid-tier - Budget - Image ### Openness (deployment freedom, derived from license) - Open source (OSI-approved: Apache 2.0, MIT) - Open weights (published but restricted: Llama, Gemma, Qwen, Mistral, CC-BY-NC) - Proprietary (API only) - Unknown (no license established) Category and openness are independent axes: a model can be frontier-priced and open-weight at the same time. ### Business view - Efficiency score based on percentile rank - Cost per request (list price) for eight preset workloads, displayed per 1,000 requests - Cost per request (after discounts), displayed per 1,000 requests: applies prompt-cache read pricing to the cached share of input tokens and batch API pricing for async workloads, where the provider publishes those rates - Monthly budget estimates for 10K, 100K, and 1M requests, shown as a range from the after-discounts unit cost (caching and batch implemented) up to the list-price one - FinOps Friendly badge next to qualifying models ### Technical view - Input price per 1M tokens - Output price per 1M tokens - Batch API price per 1M tokens (typically -50%, where published) - Prompt-cache read price per 1M tokens (where published) - Context window - Parameter count when known - Release date - Capability tags ### Efficiency score Formula: (ELO percentile x 0.6) + (price percentile x 0.4) Both percentiles are ranked across models with Arena ELO scores. Higher is better. ### FinOps Friendly badge "Production-ready models that don't blow the budget." All 4 conditions are required: 1. Quality — Arena ELO in the top 40% of ranked models 2. Value — efficiency score in the top 30% 3. Cost — list price among the cheapest 70% of ranked models 4. Stability — no preview, beta, or experimental label, not a frontier model released in the last 3 months, and no retirement announced by the model maker Every threshold is a relative percentile rather than a fixed number, so the badge recalibrates itself as the market moves. Criteria 1 and 3 are eliminating gates, not extra weight in the efficiency score: at the 60/40 blend a top-ranked model clears the efficiency threshold on quality points alone, which is how the single most expensive model in the catalogue used to earn the badge. The cost gate reads list prices only. Batch and cache discounts are conditional on the customer implementing them, so rewarding a published rate card would over-promise; those appear in the separate scenario-aware "after discounts" column. ### Use case presets Cache = share of input tokens assumed served from prompt cache in production. Batch = workload is async and assumed to use batch API pricing when published. | Use case | Input tokens | Output tokens | Cache | Batch | |---|---:|---:|---:|---| | Support Ticket | 1,500 | 500 | 60% | no | | Knowledge Q&A | 2,000 | 800 | 70% | no | | Meeting Summary | 10,000 | 1,200 | 10% | yes | | Marketing Content | 2,500 | 1,800 | 20% | no | | Coding Task | 3,000 | 2,000 | 50% | no | | Invoice Processing | 1,500 | 600 | 30% | yes | | Call Summary | 2,000 | 700 | 10% | yes | | Agent Workflow | 6,000 | 3,000 | 70% | no | ### LLM data sources and freshness - Pricing: OpenRouter API, refreshed at most every 24 hours (CDN cache) - Fallback pricing: static dataset regenerated daily from the live API - Quality: Arena (formerly Chatbot Arena / LMArena) ELO scores, rebased WEEKLY from the Arena leaderboard by a GitHub Action (Mondays). The whole map is rewritten from one leaderboard read or none of it is: the site ranks on percentiles, so refreshing a subset reads as market movement rather than as a change of scale. meta.eloAsOf is the leaderboard's own stamp, never the run date, and an absent eloScore means the model is not ranked by Arena — not that it scored badly - Model lifecycle: retirements announced by a model maker are curated by hand from its own deprecation page. A deprecated model keeps its price and its page (hosts still serve it) but its Product JSON-LD says schema.org/Discontinued rather than InStock, and it cannot hold the FinOps Friendly badge ## Cloud compute page ### Providers - AWS - Azure - GCP - DigitalOcean - OCI - OVH - Alibaba Cloud ### Price types - On-demand - Spot or preemptible - Savings plans or committed use discounts - Reserved pricing where offered by the provider ### Filters - Provider - Category - Use case - Processor family - Operating system - Region - vCPUs - Memory ### Cloud pricing data sources - AWS: live APIs for on-demand, reserved, and spot. Savings-plan rates are currently a STATIC estimate, not fetched live (the upstream index is unavailable) — see meta.priceTypes.AWS - Azure: Retail Prices API (on-demand, spot, reserved, savings plan) - GCP: Cloud Billing SKU API (on-demand, spot). Accelerator machine types (a2-*, g2-*) are priced as vCPU + RAM + accelerator SKU. Committed-use (CUD) rates are currently a STATIC estimate, not fetched live — see meta.priceTypes.GCP - DigitalOcean: Sizes API - OCI: public pricing API - OVH: public catalog API - Alibaba: static fallback data Always check meta.priceTypes before describing a price column as live provider data: a provider can be "live" in meta.sources while one of its columns is a curated static estimate. ## Machine-readable API for agents (free, no auth, CORS enabled) The site is a JavaScript SPA, but every route in the URL map above is also prerendered to static HTML with a real body: the model tables, the per-model rate cards and the barometer's moves are all readable without executing JavaScript. For anything numeric, still prefer the JSON endpoints — they carry provenance metadata the HTML does not. Cite https://optimtoken.optimnow.io/ as the source. ### GET /api/llm-models Full contract with per-field provenance: https://optimtoken.optimnow.io/openapi.json (schemaVersion 2.5; 2.0 removed the "Open Weights" category, schemaVersion 2.1 added meta.unpriced, 2.2 added openRouterId and hostPricing per model plus meta.hostPricingAsOf, 2.3 added cacheWritePricePer1M. 2.1-2.3 are additive. 2.4 changes no field but changes a MEANING: the "Reasoning" capability now means the upstream catalogue lists a `reasoning` parameter for the model (it exposes a thinking budget or effort setting), where it used to be guessed from the model name. It is not a quality claim and most current models carry it. 2.5 removes the "Code" value from capabilities: it was assigned to any model whose output cost $0.50 per 1M tokens or more, so it described a price and not an ability. The values are Text, Vision, Reasoning, Agents, Image Gen, Audio. The compute endpoint is versioned separately, at 1.2.) Query params: ?provider= (exact, case-insensitive), ?model= (substring), ?limit= Example: /api/llm-models?provider=anthropic&limit=10 Returns `{ models: LLMModel[], meta }`. LLMModel fields: provider, model, parameters, inputPricePer1M, outputPricePer1M, batchInputPricePer1M, batchOutputPricePer1M (batch API, typically -50%), cachedInputPricePer1M (prompt-cache read price), cacheWritePricePer1M (prompt-cache WRITE price at the default ~5-minute lifetime, typically 1.25x input; absent = not published, NOT free: assume a write costs the input rate), contextWindow, category (Frontier | Mid-tier | Budget | Image), capabilities, releaseDate (YYYY-MM), eloScore (Arena, recalibrated post-Jan-2026 scale for 2025+ models), license. Prices are USD per 1 million tokens. meta: schemaVersion, total (after filters), catalogTotal, source ("openrouter"), timestamp (ISO), eloAsOf (YYYY-MM-DD), unpriced (array). meta.unpriced (schemaVersion 2.1+) lists models the upstream carries with NO published token price — today its anonymous "stealth" evaluation endpoints. DO NOT read "unpriced" as free, and never as the cheapest option: no price is published, the eventual price is unknown, and prompts and completions are retained by the anonymous provider, which is a governance trade rather than a rate card. These entries are deliberately absent from `models`, have no page on this site, and are excluded from every ranking and cost estimate. Every stealth model so far was withdrawn or renamed within weeks. Each entry carries id, name, contextWindow, inputModalities and firstSeen — no price field at all. Name one as unpriced or leave it out; never quote a figure for it. Field provenance: prices, contextWindow, eloScore are [published] values from their sources; category, capabilities, license are [derived] by categorisation rules; parameters and releaseDate are [published] for curated major models and [estimated] otherwise. The openapi.json marks every field. ### GET /api/pricing Query params: ?region= (us-east | us-west | europe | asia-pacific), ?provider=aws,gcp (comma list), ?instanceType= (substring), ?limit= Example: /api/pricing?region=europe&provider=aws,azure&limit=50 Returns `{ instances: ComputeInstance[], meta }`. ComputeInstance fields: provider, instanceType, os, vCPUs, memory (GiB), onDemandHourly, onDemandMonthly, spot, savingsPlan1yr, savingsPlan3yr, reserved1yr, reserved3yr. Prices are USD; null means the provider does not offer that pricing tier. reserved1yr/3yr are EFFECTIVE HOURLY rates: Azure reservation term totals are divided by term hours (8,760/yr); AWS reserved is the published no-upfront hourly rate. onDemandMonthly is [derived] (hourly x 730). OCI spot is [derived]: 50% of on-demand, Oracle's published rule, on the shapes Oracle sells as preemptible capacity, and null on the others. meta: schemaVersion (1.2), region, timestamp, sources (per-provider "live" or "static"), sourceRegions (the region actually priced: DigitalOcean, OCI, and OVH public endpoints return a GLOBAL list price regardless of the selected region; static providers are estimated from US East with a multiplier), priceTypes, liveProviders, total, catalogTotal, errors. meta.liveProviders (schemaVersion 1.2+) is { live, expected } over the six live-capable providers (AWS, Azure, GCP, DigitalOcean, OCI, OVH; Alibaba is static by design). When live is below expected, part of the catalogue is a curated static estimate rather than provider data, and the response is cached for 30 minutes or less instead of the usual 24 hours. One exception: when the only provider missing is DigitalOcean, OCI or OVH, it keeps the 24 hours. Check it, and meta.sources for the provider concerned, before quoting a figure as current. meta.priceTypes is per-provider, per-column provenance and is finer-grained than meta.sources. For each provider it gives onDemand, spot, savingsPlan1yr, savingsPlan3yr, reserved1yr and reserved3yr, each one of: "live" fetched from the provider API this cycle "static" a curated estimate from the built-in catalogue, NOT fetched live "unavailable" no value — the provider does not sell that tier, or it is not modelled A provider marked "live" in meta.sources can still have a "static" column. As of schemaVersion 1.1 that applies to AWS savingsPlan1yr/3yr and GCP savingsPlan1yr/3yr (CUD). Cite those columns as estimates, not as provider data. GCP accelerator machine types (a2-highgpu-*, a2-megagpu-*, g2-standard-*) are priced as vCPUs x vCPU rate + memory x RAM rate + GPU count x per-GPU SKU rate, which reconstructs Google's published bundle price exactly. A shape whose accelerator rate cannot be resolved is omitted rather than published at a CPU-only price. a2-ultragpu-* and a3-* are not listed: their bundles include Local SSD, which is not yet modelled. ### Worked example: cost per request For Claude Sonnet 5 ($2.00/M input, $10.00/M output, cache read $0.20/M, batch $1.00/$5.00) on a Support Ticket workload (1,500 input + 500 output tokens, ~60% of input served from prompt cache, not batch-eligible): - List cost/request = 1500/1e6 x $2.00 + 500/1e6 x $10.00 = $0.008 - After-discounts input rate = 0.6 x $0.20 + 0.4 x $2.00 = $0.92/M - After-discounts cost/request = 1500/1e6 x $0.92 + 500/1e6 x $10.00 = $0.00638 - Monthly at 100K requests = ~$638 after discounts (x 100,000), up to $800 at list price For an async workload (batchEligible, e.g. Invoice Processing), substitute the batch input/output prices as the base rates before applying the cache share. ## Interface notes for agents - Root path `/` is the main LLM pricing comparison page - `/compute` is the cloud compute comparison page - `/compare` is the side-by-side tool; `/compare/{a}-vs-{b}` are prebuilt duels - `/models/{provider}/{model}` is one page per model — see the URL map above - `/barometer` is the price movement page for the last 7 days; `/barometer/weeks` lists the permanent weekly pages (`/barometer/{year}-w{week}`), and `/barometer/feed.xml` is their RSS feed - `/guides` and `/guides/{slug}` are the editorial FinOps guides - `/mcp` documents the MCP server; `/openapi.json` is the full API contract - `/sitemap.xml` enumerates every indexable URL on the site - `/llms.txt` is the concise crawler summary - `/llms-full.txt` is the detailed crawler reference - The site is free to use and does not require an account ## Guide articles, full text Every published guide as the plain text of its page, so an agent can read the findings here without fetching eight pages. Each entry opens with its URL, its publication date, the catalogue snapshot its figures come from, and its summary. The block between GUIDES-FULL-START and GUIDES-FULL-END is regenerated by scripts/prerender.mjs on every build; the figures are the ones the pages carry. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/arm-against-x86 Published: 2026-09-13. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: The ARM discount clouds advertise is a discount against Intel. Measured at matched vCPU and memory, it halves against AMD. Current prices. # ARM against x86: what Graviton, Ampere and Axion save A FinOps guide by OptimNow · list prices from the live OptimToken compute catalogue Every cloud sells an ARM line, and every cloud sells it on price. AWS has Graviton, Azure and Google both resell Ampere, Google has added its own Axion, and Alibaba builds Yitian. The number attached to all of them is roughly 20%. That number is checkable, so this guide checks it: same cloud, same vCPU count, same memory, on-demand Linux list price, and nothing else changed. The answer depends almost entirely on one thing nobody states, which is what you are comparing the ARM instance to. ## How the gap is measured here An instance pair qualifies when both rows come from the same provider, carry the same vCPU count and the same memory, and sit in the same burstable class. A burstable instance buys CPU credits rather than a dedicated core, so t4g is compared to t3 and never to c6i. Accelerated shapes are excluded: when a GPU sets the hourly rate, matching on cores compares the wrong component. The catalogue today yields 77 qualifying pairs across 33 ARM instance sizes and 4 clouds (AWS, Azure, GCP and Alibaba). Both sides of every pair come off the same rate card in the same region, so this is a ratio between two prices a customer sees on one screen. Regional multipliers apply to both rows and cancel. What the ratio cannot tell you is covered further down, and it is the part that decides the migration. ## Against Intel, the clouds agree Measured against Intel instances of the same size, the median discount is 19.2% across 53 pairs. The 4 clouds land within 4.9% of each other while selling 6 different ARM chip generations between them, which reads as a pricing convention rather than a measured cost of silicon. The pale bar is the median discount against Intel rows of the same size, the solid bar the median against AMD rows of the same size. Only clouds listing both comparators appear; Alibaba publishes no AMD line in this catalogue, so it is absent from the chart. ## Against AMD, it halves Same ARM instances, same method, different baseline: measured against AMD rows of the same size, the median gap is 10.6% across 24 pairs. That is under half the figure against Intel. The ARM discount, as published, is largely a discount against Intel, and AMD had already taken most of it. A business case built on the 20% headline while the estate runs on AMD is sized against a baseline it does not have. This is where the comparison matters for a FinOps team. The choice presented internally is "ARM or x86", and the rate card does not work that way: it prices three processors, not two. OptimNow's practice library makes the same point from the other direction, recommending that representative workloads be benchmarked on Intel, AMD and ARM before a family is picked, rather than on the two most familiar. ## Worked examples At 730 hours a month and a fleet of 50 instances, held for a year: ARM instance | Rate/hour | Against Intel | Against AMD | Annual saving vs Intel | Annual saving vs AMD t2a-standard-4 4 vCPU / 16 GB | $0.1540 | n2-standard-4 at $0.1942 20.7% cheaper | n2d-standard-4 at $0.1690 8.9% cheaper | $17,608 | $6,570 c6g.xlarge 4 vCPU / 8 GB | $0.1360 | c5.xlarge at $0.1700 20.0% cheaper | c6a.xlarge at $0.1530 11.1% cheaper | $14,892 | $7,446 The two right-hand columns are the same migration, costed against two different starting points. Neither is wrong. Which one applies is a question about the current estate, answerable from a tag or an instance-type inventory, and worth answering before the saving is put in a business case. ## The newest ARM chips carry the smallest discount Grouping the same pairs by silicon rather than by cloud shows the direction of travel. Each step below stays inside one cloud's own ARM line, so it compares two generations rather than two rate cards. All of it is measured against Intel to keep the baseline fixed. Graviton2 to Graviton3 moves the median from 20.0% to 15.0%. Ampere Altra to Axion moves the median from 20.7% to 7.5%. The discount shrinks as the silicon gets newer, which is the opposite of what a reader expecting a widening ARM advantage would predict. Each span runs from the smallest to the largest discount that generation reaches against a same-size Intel instance; the tick inside marks the median. Holding the comparator fixed is what makes the generations comparable: the AMD gaps in the section above are roughly half these, and the generations do not carry the same mix of the two. The clearest case sits on GCP. c4a-standard-2 (2 vCPU / 8 GB) lists at $0.0898 an hour against $0.0845 for n2d-standard-2, the AMD row of the same size. The ARM instance costs 6.3% more, not less, and the same holds at the other matched size. A team that moved to ARM on GCP expecting the headline, from an AMD starting point, moved to a more expensive instance. The catalogue carries the price and not the reason. Newer cores priced on what they deliver, rather than discounted for the architecture, would produce this pattern. That reading is a hypothesis, not a measured result. ## What a rate card cannot tell you Everything above measures price per vCPU-hour. It says nothing about how much work a vCPU does, and the two are not the same question. A Graviton3 core and a Graviton2 core both count as one vCPU on the bill. They do different amounts of work per hour. That is the most plausible explanation for the narrowing above: the newer generations charge more per hour because they deliver more per hour. OptimToken publishes prices, not benchmarks, so treat the direction as an observation with a stated limit rather than a measured price-performance result. The practical consequence is that a same-size swap is the wrong migration in both directions. Moving from Ampere Altra to Axion at an unchanged size raises the bill, because the newer generation is the dearer row of the two. Sizing the target fleet on observed utilisation, rather than mapping it one-for-one, is where the rest of the saving sits. ## What the migration costs - Multi-architecture builds. Container images, Lambda packages and any compiled dependency need an arm64 target. Interpreted runtimes and bytecode move with a configuration change; anything linking x86-specific binaries does not. - Commitments strand. Reserved instances scoped to an instance family, and resource-based committed use discounts, do not follow a workload from Intel to ARM. A term signed on the old family is a real cost of the move, and a term with months left to run is the reason a technically ready migration waits. Where the architecture is still in flux, a spend-based commitment trades a few points of discount for the freedom to move. - Managed services move separately. The same processor choice exists on RDS, ElastiCache and OpenSearch, on their own schedules and their own rate cards. The EC2 estate is not the whole of it. - Not every cloud offers the choice. DigitalOcean and OVH list no ARM instance in this catalogue. OCI lists ARM shapes carrying different memory per core than the x86 shapes beside them, so no like-for-like pair clears the rule above and no gap can honestly be quoted. ## Where this leaves a shortlist Take a team running general-purpose or compute-optimised Linux workloads with no x86-specific dependencies. For that team, ARM is the cheaper row at every matched size on 3 of the 4 clouds measured here (AWS, Azure and Alibaba). At 50 instances held for a year, the table above puts the saving at $14,892 to $17,608 against Intel. Two corrections to the 20% framing. First, measure the gap against the processor you run today. Second, check which ARM generation you are moving to, because the newest is not the cheapest and on GCP it is the more expensive option at some sizes. Both checks take an afternoon against an instance inventory, and the first alone moves the size of the business case by a factor of 1.8. The full rate card, including the spot and commitment columns this guide leaves aside, sits on the cloud compute pricing table. Figures on this page are recomputed from the compute catalogue on every build, at on-demand Linux list prices for the US East region group. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own estate sized against the processor families you are already paying for, OptimNow runs that review. ## Questions this guide answers ### How much cheaper is Graviton than Intel? On the 2026-10-04 OptimToken compute catalogue, AWS Graviton instances list a median 19.2% below Intel instances with the same vCPU count and memory, at on-demand Linux list prices. Across all 4 clouds measured, the median ARM discount against Intel is 19.2% over 53 matched pairs. ### Is ARM cheaper than AMD? By less than the usual headline. On the 2026-10-04 OptimToken compute catalogue, ARM instances list a median 10.6% below AMD instances of the same size across 24 matched pairs, against 19.2% below Intel. On GCP the ARM row can cost more: c4a-standard-2 lists at $0.0898 an hour against $0.0845 for n2d-standard-2, 6.3% more. ### Do newer ARM chips carry a bigger discount than older ones? No, the discount shrinks as the silicon gets newer. On the 2026-10-04 OptimToken compute catalogue, measured against same-size Intel instances: Graviton2 to Graviton3 moves the median from 20.0% to 15.0%. Ampere Altra to Axion moves the median from 20.7% to 7.5%. The likeliest reason is that newer cores do more work per hour, which a rate card cannot show. ### Which clouds sell ARM instances? On the 2026-10-04 OptimToken compute catalogue, AWS, Azure, GCP and Alibaba list ARM instances with a same-size x86 twin to compare against, giving 77 matched pairs. OCI sells ARM shapes with no same-size x86 twin, so no gap can be quoted. DigitalOcean and OVH list no ARM instance at all. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/batch-api-economics Published: 2026-08-14. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: Batch APIs cut LLM token prices roughly in half, but only for async workloads and only where a batch rate is published. Worked examples, current prices. # Batch API economics: when the -50% applies A FinOps guide by OptimNow · prices from the live OptimToken catalogue A batch tier sells the same model at roughly half the token price, on one condition: you submit a file of requests and get the results back asynchronously. Prompt caching cuts a larger percentage, but only off input tokens. Batch is the discount that applies to output as well, which is why it moves a bill that generation dominates. What it costs instead is latency, and it is not offered on every model. This guide shows where the −50% is real, with numbers from current prices. ## What batch pricing is A batch API is not a faster way to send a batch of requests: it is a slower one. You upload a job, typically a JSONL file of requests. The host, the company that runs the model and sells it by the token, schedules the job on spare capacity. It commits to returning results within a stated window, 24 hours at OpenAI, Anthropic, Google and Mistral. In exchange, both input and output tokens are billed at a discount, typically 50%. The host wins because batch jobs smooth out its GPU utilization; you win if, and only if, nobody is waiting on the answer. ## Which workloads qualify The test is one question, whether anybody needs the result before tomorrow. If not, batch it. Four classes of back-office work pass that test: - Invoice and document processing: extraction runs on documents that arrived in a queue, not on a person in a chat window. - Call and meeting summaries: the recording is finished; the summary can land an hour later. - Evaluations and backfills: regression suites, re-scoring historical data, enrichment of an existing corpus. - Content generation at volume: product descriptions, translations, tagging. What never qualifies: anything interactive. Support chat, coding assistants, agent loops that chain on each other's output: a 24-hour ceiling is meaningless there. Of the 8 use-case presets on the pricing table, 3 are marked batch-eligible for this reason: meeting summary, invoice processing and call summary. ## Who publishes batch prices The −50% is published for a minority of the catalogue. Today, 70 of 290 models on OptimToken publish batch rates. A batch tier is not a property of the model, it is a property of the model maker's billing: it clusters in a handful of catalogues and is absent from the rest. The 10 largest model makers by catalogue size. The pale bar is every model from that model maker, the dark bar is the subset publishing a batch rate. OpenAI, Google, Mistral and Anthropic price at least 30% of their own catalogue at a batch rate. DeepSeek (1 of 14) and xAI (1 of 7) publish one or two isolated rows. That is a model decision rather than a billing policy, and should not be read as batch support. Alibaba, Zhipu, MiniMax and Moonshot publish none at all, across 64 catalogued models between them. For those model makers the strategy is a low list price rather than a discount tier, which is a reasonable answer to the same problem and a very different one to plan around. If your shortlist sits entirely in that last group, batch is not a lever you have. ## When a batch rate exists, it is almost always half The rate is the predictable part. Of the 70 models publishing a full batch tier, 68 price it at exactly 50% off a 30/70 blend of input and output. The median is 50%. Unlike prompt-cache rates, which spread across the whole range, batch pricing has converged on one number. Discount measured on a 30/70 input-output blend, the same weighting the pricing table ranks on. Counts the 70 models that publish a batch rate; the 220 that publish none are the subject of the chart above. The other 2 publish a different rate, and a migration is costed off the published rate, not off the headline. DeepSeek V4.1 Flash (42%) and Grok 4.3 (20%) publish a batch rate below the headline. The check is one subtraction against the list price, and it belongs in the migration plan rather than after it. ## Worked example: invoice processing at 100K requests/month Using the Invoice Processing preset (1,500 input + 600 output tokens per request, an async workload), at 100,000 requests per month: Model | Cost/req (list) | Cost/req (batch) | Monthly (list) | Monthly (batch) | Batch saves Claude Sonnet 5 | $0.0090 | $0.0045 | $900 | $450 | $450 (−50%) GPT-5.5 | $0.025 | $0.013 | $2.5K | $1.3K | $1.3K (−50%) DeepSeek V4 Flash 0731 | $0.000408 | not published | $41 | $41 | $0 (no batch rate) Two lessons. First, when batch rates exist, the saving is real money at volume: no code changes to the prompts, just a different submission path. Second, a cheap model at list price can still undercut an expensive model at batch price. DeepSeek V4 Flash 0731 at the price we quote ($0.016/M in, $0.64/M out) costs 11.0x less than Claude Sonnet 5's batch rate for this extraction-style workload. That quoted price is Relace's rate, for a build quantized to fp4, one of 24 hosts selling the model; the model page lists the others. Batch discounts are an optimisation within a model choice, not a substitute for making the model choice well. Compare the two side by side before assuming the discount settles it. ## The caveats that bite in production - The SLA caps the wait; it makes no promise about how fast a job finishes. Jobs often complete in minutes, but the only guarantee is the window, 24 hours at the 4 model makers named above. Downstream steps must tolerate the worst case. - No streaming. Results arrive as a completed file. If your pipeline expects token streams, it needs a second, non-streaming path. - Job size and queue limits. Hosts cap requests per batch and enqueued tokens per model. A month-end invoice spike can hit those caps exactly when you need throughput. - Results expire. Output files are retained for a limited period: collection must be automated, not manual. - Batch × cache interaction is murky. Prompt-cache discounts are published for the standard tier; few hosts publish a batch-tier cache-read rate. The after-discounts column on the pricing table assumes the standard cache rate under batch, which is the conservative reading (the formula is here). ## When not to bother Skip batch when the workload is interactive, or when a deadline sits closer than the SLA window. Skip it too when the monthly spend is small. An engineer-day of pipeline work does not pay back on a $40/month job, and at that scale a budget model at list price is the better lever. And never batch-migrate a workload before checking whether a cheaper model would beat the discount outright. The pricing table sorts by cost after discounts per use case for exactly that question. The order of work follows FinOps maturity. A team at Crawl, with no per-workload token bill yet, starts by measuring which jobs are async and what they cost at list. A team at Walk or Run, with that allocation in place, reads the saving off the table above and schedules the migration against it. Figures on this page come from the 2026-10-14 price snapshot and rebuild nightly. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own async workloads sized against the batch and cache rates you are entitled to, OptimNow runs that review. ## Questions this guide answers ### Does the batch API always give 50% off? Only where a batch rate is published, and then almost always. On the 2026-10-14 OptimToken catalogue snapshot, 68 of the 70 models with a full batch tier price it at exactly 50% off a 30/70 blend of input and output. The median discount is 50%. The discount is smaller than half on 2 models. ### How many LLMs have a batch API price? On the 2026-10-14 OptimToken catalogue snapshot, 70 of the 290 models publish both a batch input and a batch output rate. Batch pricing clusters by model maker: OpenAI, Google, Mistral and Anthropic price at least 30% of their own catalogue at a batch rate, while Alibaba, Zhipu, MiniMax and Moonshot publish none. ### Which workloads can use batch pricing? Any workload where nobody waits on the answer: invoice and document processing, call and meeting summaries, evaluations and backfills. Interactive work such as support chat, coding assistants and agent loops never qualifies. On the 2026-10-14 OptimToken catalogue snapshot, 3 of the 8 use-case presets on the pricing table are marked batch-eligible: meeting summary, invoice processing and call summary. ### Is a batch discount worth more than switching to a cheaper model? Often not. On the 2026-10-14 OptimToken catalogue snapshot, an invoice-processing request costs $0.0045 on Claude Sonnet 5 at its batch rate and $0.000408 on DeepSeek V4 Flash 0731 at list price. The list-price model is 11.0x cheaper with no discount applied. Batch is an optimisation within a model choice, not a substitute for making the model choice well. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/capability-premium Published: 2026-10-04. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: What image input, audio and tool use add to an LLM bill, measured within each model maker's line-up and across the catalogue, and the shortlist each leaves. # Vision, audio, agents: what each capability adds to the bill A FinOps guide by OptimNow · prices from the live OptimToken catalogue A product team says the feature needs to read screenshots. Someone then asks what vision costs, and the catalogue appears to answer: models that accept images carry a median blended price 2.87x the models that do not. That number is real and it is the wrong one to budget against. It compares model makers, not capabilities. This guide separates the two on 282 priced models. The cost that remains is the size of the shortlist each requirement leaves. ## Four capabilities, all read from upstream facts OptimToken reads capability tags from upstream model metadata. Image input and audio come from the model's declared input and output modalities. Tool use and a reasoning control come from the parameters the model accepts. Those four are facts about the model, so they can be priced. Until 5 October 2026 the catalogue also carried a Code tag. It was assigned from a price threshold, so asking what Code adds to the bill would have returned the threshold. This guide never priced it, and the tag has since been removed. ## Most of the catalogue-wide premium is a mix effect Capabilities can cluster by model maker. A model maker whose entire line-up is multimodal and priced for enterprises puts every one of its models on the with-vision side. One selling small text models puts every one of its models on the other. Across the catalogue, the gap between the two sides then includes the gap between those two companies. Compare inside one model maker's catalogue instead and the premium shrinks. Of the model makers with at least 2 models on each side, the median ratio between their vision models and their text-only models is 1.34x, against 2.87x across the catalogue. In 2 of 8 the ratio sits below 1, meaning that model maker's vision models are the cheaper half of its own line-up. Median blended price of the model maker's vision models divided by the median of its text-only models. 1.00x is parity. Model makers with fewer than 2 models on either side are excluded, because one unusual row would set the ratio. Across model makers the ratio runs from 0.57x to 2.23x, so image input is not free everywhere. Whose model you buy decides more of the bill than the capability does. ## Counter-example: dropping a capability can raise the bill The usual FinOps instinct is to treat model selection as rightsizing, and to stop paying for what the feature does not use. On this catalogue that instinct misfires at 2 of the 8 model makers with enough models to compare. At Zhipu the median vision model costs $0.986 per 1M blended tokens against $1.720 for its text-only models, so removing image input from the requirement moves the shortlist to the more expensive half. At Google, the cheapest model accepting images is Gemma 3 4B at $0.085 per 1M blended tokens. Drop the image requirement and the cheapest thing on the same shelf is Gemma 2 27B at $0.650, a 7.65x gap in the wrong direction. Compare them side by side. The price follows the model's position in the line-up. The capability came with it. ## What a requirement costs instead: the shortlist If the rate card does not price capability, something else does. Every requirement removes models from consideration. A thinner shortlist costs you the competition that was holding the price down. Each requirement applied on its own to the whole catalogue, not stacked. The pale bar is every priced model, the dark bar is the subset meeting that one requirement. Read as a shortlist, the four requirements are not comparable at all. Tool use leaves 249 of 282 models, 88% of the catalogue. The cheapest model carrying it is Mistral Nemo at $0.030 per 1M blended tokens, against $0.012 for Summarize, the cheapest model overall. Requiring tool use multiplies the floor by 2.47x. ## Worked example: the audio requirement Audio behaves differently. It is the requirement worth planning around. Across the catalogue, 26 of 282 models accept or produce it, 9% of the total. The catalogue-wide price ratio is 2.10x, below image input's 2.87x, so on a rate-card reading audio looks the cheaper requirement. The cheapest model that handles audio is MiMo-V2.6-Flash at $0.238 per 1M blended tokens, against $0.012 for Summarize with no capability requirement at all. Adding audio to the specification multiplies the floor by 19.83x. Concentration compounds it. Google makes 14 of the 26 audio models, 54% of the shortlist, spread across 8 model makers in total. A requirement met by one model maker on most of the shortlist is a negotiating position as much as a technical choice, and it belongs in the risk register next to the cost estimate. Where audio is a minority of requests, a router is the cheaper structure. Send the audio requests to a model that handles them and leave the rest on the catalogue floor. Paying the audio floor on every call buys audio for calls that carry none. ## How to use this when choosing a model These steps assume a team that already tags requests by type, the Walk stage in FinOps maturity terms. A team still reading one monthly invoice has nothing to route yet, and request-level tagging comes first. - Specify capabilities per request type rather than per feature. One multimodal model for a workload that is 5% images sets the floor for the other 95%. - Check the model maker's own ladder before paying for a capability. Within a line-up the premium ran a median 1.34x for image input, and went the other way at 2 of 8 model makers. - Count the shortlist, then look at its concentration. A requirement that leaves 26 models, most from one model maker, is a different risk than one that leaves 249. - Set the quality bar before the capability list. The bar belongs to the product owner; the model choice is the cheapest path that clears it. Capability tags say what a model accepts. They say nothing about how well it does the job. These are the prices we quote, on a 30/70 input-output blend (the formula is here). They do not include what a capability costs in tokens once it is used. An image is billed as input tokens when it reaches the model, and a long screenshot is a long prompt. Price the payload with that formula; this guide prices the shortlist only. Figures on this page come from the 2026-10-14 price snapshot and rebuild nightly. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own model shortlist sized against the capabilities your workload uses, OptimNow runs that review. ## Questions this guide answers ### Do models with image input cost more? Across the catalogue, yes. Inside one model maker's line-up, the premium is smaller. On the 2026-10-14 OptimToken catalogue snapshot, models accepting images carry a median blended price 2.87x that of models that do not. Comparing within each model maker that has at least 2 models on each side, the median ratio falls to 1.34x, and at 2 of 8 model makers the vision models are the cheaper half. Most of the catalogue-wide gap measures the difference between model makers, not the price of the capability. ### How many models support audio? On the 2026-10-14 OptimToken catalogue snapshot, 26 of 282 priced text models accept or produce audio, 9% of the catalogue. The cheapest is MiMo-V2.6-Flash at $0.238 per 1M blended tokens, against $0.012 for Summarize with no capability requirement, so requiring audio multiplies the price floor by 19.83x. ### Does requiring tool use narrow the choice of model? Barely. On the 2026-10-14 OptimToken catalogue snapshot, 249 of 282 priced models accept tool-use parameters, 88% of the catalogue, and the cheapest of them is Mistral Nemo at $0.030 per 1M blended tokens. The cheapest model overall is Summarize at $0.012, so requiring tool use multiplies the floor by 2.47x. ### What does a capability requirement cost? The shortlist rather than the rate. Each requirement removes models from consideration, and the floor rises with it. On the 2026-10-14 OptimToken catalogue snapshot: tool use leaves 249 of 282 models and a floor 2.47x the catalogue floor; a reasoning control leaves 209 of 282 models and a floor 4.20x the catalogue floor; image input leaves 177 of 282 models and a floor 1.00x the catalogue floor; audio leaves 26 of 282 models and a floor 19.83x the catalogue floor. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/context-window-economics Published: 2026-09-20. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: A million-token context window is a spec-sheet capability and an invoice line. What one full prompt costs across the catalogue, and what re-reading it costs. # Context windows: what a million tokens costs to fill A FinOps guide by OptimNow · prices from the live OptimToken catalogue A context window is advertised as a capability: 1M tokens, 400K, 200K. The number says what the model will accept and nothing about what filling it costs, and the two facts are published in different places. An input rate is quoted per 1M tokens, so for any model that accepts a 1,000,000-token prompt, the published input price is the price of one full-length request. Nothing has to be multiplied. Every figure below comes from the 2026-10-14 catalogue snapshot and is recomputed nightly. ## What one million tokens costs On that snapshot, 104 of the 280 priced models accept a prompt of 1,000,000 tokens or more. Filling that prompt once costs $0.016 on DeepSeek V4 Flash 0731 and $30.00 on GPT-5.5 Pro. That is 1,875x across models sold on the same advertised capability. The median is $0.75. The cheap end is Relace's rate for a build quantized to fp4, one of 24 hosts selling DeepSeek V4 Flash 0731. Reviewed against the catalogue on 2026-10-11. At publication, on the 2026-09-20 snapshot, 89 of 265 models accepted the prompt and the fill ran from $0.03 to $30.00, a 1,000x spread. On the 2026-10-14 snapshot it is 104 of 280, from $0.016 to $30.00, 1,875x. The dear end held; the cheap end is whichever host lists the lowest input rate that day, so the spread moves with it. Take $0.01 of input per request as the budget line. It is an assumption chosen to stand for one interactive call, not a figure measured from any deployment. At that budget DeepSeek V4 Flash 0731 gives you 62.5% of a 1,000,000-token prompt and GPT-5.5 Pro gives you 0.03%. The 4 cheapest and 4 dearest of the 104 models accepting a 1,000,000-token prompt. The bars at the foot are drawn at a minimum width; the printed figure is the value. OpenRouter publishes an exact context_length for every model and the OptimToken table rounds it for display. The models labelled 1M are not all the same size. The label covers 1,000,000, 1,048,576 (2^20, the value most model makers ship), 1,050,000 and 1,310,720. A cost computed by multiplying the label would be wrong by up to 24% on the last of those. Every figure on this page is anchored to exactly 1,000,000 tokens. That prompt fits every model counted here, because the rounded label only carries an M suffix from 1,000,000 upward, and its cost is the published input rate with no arithmetic applied. ## The second read is where the bill is decided A long context is rarely read once. Agent loops, multi-turn chat and document Q&A re-send the accumulated history on every call, and it is billed as input each time. Per token, input is the cheaper side: across the 280 priced models here, output costs 4.0x input at the median. That price signal is why teams look at the output rate first, and why the input line is the one that grows with conversation length. Prompt caching is the published lever. A cache-read rate charges a fraction of the input price for tokens already held in the cache. Among the 104 models accepting a 1M prompt, 92 publish one, at a median 90% off the input rate. The pale bar is every priced model in the band, the dark bar is the subset publishing a cache-read rate. Bands are read off the rounded window label, which is precise enough to sort a model into a band. In the under 100K band, 4 of 19 models publish a cache-read price, against 92 of 104 at 1M and above. Model makers selling a large window mostly also sell the discount that makes re-reading it affordable. That is a pattern in the 2026-10-14 snapshot, not a policy any model maker has stated, and it is measured on published rate cards rather than on negotiated ones. ## Worked example: 10 reads of the same context The 10 reads are an assumption, not a measurement. They stand for one document held across a short agent run or a chat session that keeps referring back to it. The first read is billed at the input rate in every case, because there is nothing cached yet. Model | Window | Fill once | Cache read | 10 reads, no cache | 10 reads, cached DeepSeek V4 Flash 0731 | 1M | $0.016 | $0.016 | $0.16 | $0.16 (−0%) Gemini 3.7 Flash | 1M | $0.75 | $0.075 | $7.50 | $1.42 (−81%) Qwen3.5-Flash | 1M | $0.065 | not published | $0.65 | $0.65 (no cache rate) GPT-5.5 Pro | 1M | $30.00 | not published | $300.00 | $300.00 (no cache rate) Prices are per 1M tokens, which at this prompt size is per request. Compare DeepSeek V4 Flash 0731 and GPT-5.5 Pro side by side for the full rate cards, output and cache rates included. ## Where the discount is not available Of the 104 models accepting a 1M prompt, 12 publish no cache-read rate at all. For those the tenth read costs what the first did. The dearest of them, GPT-5.5 Pro, fills at $30.00, so 10 reads is $300.00 with no published discount to apply. The cheap end has the same gap. Qwen3.5-Flash fills a 1,000,000-token prompt for $0.065 and publishes no cache rate either. Across 10 reads it costs $0.65, which is less than what 61 of the 92 models with a published cache rate charge over the same 10 reads. A missing cache rate is a reason to run the arithmetic, not a reason to drop the model. ## What to do with this Context selection is a cost decision as much as a quality one. The levers below come from OptimNow's FinOps practice library and apply from the first production workload, not only at scale: - Minimum viable context: one document, not the corpus. One file, not the repository. - Rolling window: keep the last N turns. Cheap to implement, and it loses long history. - Summarization checkpoints: compress the history into a summary as the conversation approaches the limit. - Retrieval precision: broad-match RAG puts marginally relevant fragments into every prompt. Tune top-k and the relevance threshold. - Set max_tokens on every call. Unbounded responses are the most common avoidable overrun. These matter most where one workload sends large prompts repeatedly. On an estate at Crawl maturity, with no per-feature cost allocation in place, measure the average prompt size before optimising it. The practice library lists an average prompt size above the design estimate as a detection signal in its own right, and that measurement comes before any lever. Pull the average input tokens per request for your largest AI feature from last month's usage export and multiply by the published input rate for the model it runs on. If that figure sits above your output spend, the window is your cost driver. Figures on this page come from the 2026-10-14 price snapshot and rebuild nightly. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own prompt sizes and cache rates measured against the models you already run, OptimNow runs that review. ## Questions this guide answers ### How much does it cost to fill a 1M-token context window? Exactly the model's published input price per 1M tokens, because a 1,000,000-token prompt is one million input tokens. On the 2026-10-14 OptimToken catalogue snapshot, that runs from $0.016 on DeepSeek V4 Flash 0731 to $30.00 on GPT-5.5 Pro: a 1,875x spread across the 104 models that accept the prompt, with a median of $0.75. ### How many LLMs accept a 1,000,000-token prompt? On the 2026-10-14 OptimToken catalogue snapshot, 104 of the 280 priced text models advertise a context window of 1M tokens or more. The rounded label covers real windows from 1,000,000 up to 1,310,720 tokens, so every figure in this guide is anchored to exactly 1,000,000 tokens. ### Does prompt caching make a long context cheaper to re-read? Where a cache-read rate is published, yes. Of the 104 models with a 1M window, 92 publish one on the 2026-10-14 OptimToken catalogue snapshot, at a median 90% off the input price. The first read is always billed at the full input rate; only re-reads of the same prefix get the cache rate. ### Which 1M-context models publish no cache-read price? Of the 104 models accepting a 1M prompt, 12 publish no cache-read rate on the 2026-10-14 OptimToken catalogue snapshot, so for them every re-read is billed at the full input price. They include the dearest window in the catalogue, GPT-5.5 Pro at $30.00 per full prompt, so 10 reads of the same context cost $300.00 with no discount to apply. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/cost-of-reasoning Published: 2026-09-27. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: Reasoning tokens are billed as output tokens, where prompt caching cannot reach them. What a thinking budget costs across the catalogue, at current prices. # The cost of reasoning: what thinking models charge for output A FinOps guide by OptimNow · prices from the live OptimToken catalogue A reasoning control used to be something you shopped for. It is now standard equipment. Of the 290 models in the OptimToken catalogue, 216 expose one, which means the model accepts a thinking budget or an effort setting on the request. The shortlist question has moved with it. What matters is no longer which models can think, but what the thinking costs on the model you already picked. That answer sits on the output side of the rate card. ## Reasoning tokens are output tokens A model that reasons before answering generates the reasoning. Those tokens are billed at the output rate whether or not the API returns them to you. They also never appear in the prompt you wrote, so an estimate built from prompt length misses them completely. The rate card already shows the effect. Output is priced at 5x input or more on 48% of the 209 reasoning-capable models, against 20% of the 71 that carry no reasoning control. At the steep end the split is sharper: of the 35 models pricing output at 8x input or more, 33 expose a reasoning control. Frontier is left off the chart: only 2 of its 31 models carry no reasoning control, which is too few for a share to mean anything. Ratio measured on the prices we quote. ## What a thinking budget costs Take the Knowledge Q&A preset from the pricing table, at 2,000 input tokens and 800 output tokens per request. Add 1,000 thinking tokens, a round budget chosen for the arithmetic rather than measured from any workload. The median reasoning-capable model then costs 78% more per request, on an identical prompt and an identical answer back to the user. What sets the size of that increase is the output-to-input ratio. The table prices the highest Arena-ranked reasoning model in each ratio band on the same request: Model | Output vs input | Output $/1M | Cost/req | Cost/req +1,000 thinking | Uplift | Monthly at 100,000 req DeepSeek V4 Pro 0423 | under 2x | $1.9105 | $0.0034 | $0.0053 | +56% | $344 → $535 Qwen3.7 Max | 2x to 5x | $4.425 | $0.0065 | $0.011 | +68% | $649 → $1.1K Claude Opus 5.5 | 5x to 8x | $20.00 | $0.024 | $0.044 | +83% | $2.4K → $4.4K Kimi K3 | 8x and above | $10.00 | $0.0095 | $0.019 | +106% | $946 → $1.9K The uplift follows the ratio and not the price level. Claude Opus 5.5 charges $20.00 per 1M output tokens and takes +83%. Kimi K3 charges $10.00 and takes +106%. The cheaper model absorbs a thinking budget worse than the dearer one, which is what a blended input-output price hides. Put DeepSeek V4 Pro 0423 and Kimi K3 side by side if your workload is reasoning-heavy and the quality gap is one you can measure. ## The discounts do not follow the tokens Prompt caching discounts input tokens, and a thinking budget spends output tokens. The two levers sit on different halves of the bill, and the half that grows under reasoning is the one caching cannot reach. Take the same Knowledge Q&A request, across the 163 reasoning-capable models whose published cache-read rate lowers the figure. Caching removes a median 21.0% of the bill with no thinking budget. At 1,000 thinking tokens it removes 11.5%. The dollars caching saves do not change: the input side of the request is identical in every row. The bill grows, so the same saving covers less of it. That decides how the number should be reported. A team quoting its caching programme as a percentage will watch the percentage fall while the programme works as designed. The budget at which the share halves is the list cost of the request expressed in output tokens. It is a per-model figure, at a median of 1,300 thinking tokens, and it sits under 2,000 for all 163 models measured. Model | Caching removes (no thinking) | Caching removes (+1,000 thinking) | Thinking budget that halves the share DeepSeek V4 Pro 0423 | 35.6% | 22.9% | 1,800 tokens Qwen3.7 Max | 23.9% | 14.2% | 1,467 tokens Claude Opus 5.5 | 21.0% | 11.5% | 1,200 tokens Kimi K3 | 2.7% | 1.3% | 946 tokens One published discount does reach an output token, and it is the batch tier. Of the 209 reasoning-capable models, 60 publish a batch output rate, at a median 50% off list. The constraint is the one batch always carries: nobody can be waiting on the answer. That rules out the interactive shapes, agent loops, coding assistants and tool-calling chains, whatever their thinking budget. On scheduled reasoning work, such as document classification with a verification pass or an evaluation suite, it halves the thinking bill and the mechanics are here. ## Where this does not apply The argument assumes output costs more than input, which is not universal. DeepSeek V4 Pro 0423 prices output at 2.00x input, so 1,000 thinking tokens add 56% to the request rather than the 78% the median model takes, and it is the highest Arena-ranked reasoning model priced under 2x. At the flat end of the catalogue, one model prices a thinking token at exactly the rate of a prompt token (Nemotron 3.5 Content Safety). On those rows a thinking budget costs the same as the equivalent number of prompt tokens, and the output rate decides nothing. Check the ratio first. The tag itself needs one caveat. It records that the model accepts a reasoning parameter, read from the upstream catalogue. It does not say thinking is on by default, how many tokens a given effort setting spends, or that the model is any good at reasoning. Until 2026-09-21 this site inferred the tag from the model's name, which tagged an image generator, a model maker called Thinking Machines and a model whose name contains "pro4". The name rule found 46 models on that day. The parameter finds 216 today. That correction is what made this page possible, and it is also why the population is broad enough that the tag is a weak filter now. ## What to measure Three checks, in the order they pay off. Set an explicit thinking budget or effort level on every call. An unbounded reasoning budget is the token equivalent of an unbounded max_tokens, and the default setting is rarely the cheapest one your accuracy target allows. Then log realised output tokens per request against the estimate the feature was costed on. Reasoning spend can grow with no change to your code and none to your prompt, which makes it the line an estimate built from the request misses. Last, when the shortlist is down to two models, compare them on the output rate rather than a blended one. The median reasoning-capable model prices output at 4.2x its input, so a 30/70 blend already understates the output side of a workload that thinks. Ask for the ratio. Figures on this page come from the 2026-10-14 price snapshot of 280 priced models and rebuild nightly. Thinking budgets are stated in output tokens rather than estimated from a workload. The hub holds no data on how many reasoning tokens a given model spends, and inventing that number would put a guess underneath every figure above. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want your own reasoning workloads costed against the output rates you are paying, OptimNow runs that review. ## Questions this guide answers ### Are reasoning tokens billed as input or output? As output, at the model's output rate, whether or not the API returns the reasoning text to you. They do not appear in the prompt, so any cost estimate built from prompt length misses them entirely. On the 2026-10-14 OptimToken catalogue snapshot, 48% of the 209 reasoning-capable models price output at 5 times input or more, against 20% of the 71 models with no reasoning control. ### How much does a thinking budget add to a request? On the 2026-10-14 OptimToken catalogue snapshot, adding 1,000 thinking tokens to a Knowledge Q&A request (2,000 input, 800 output tokens) costs the median reasoning-capable model 78% more. The size of the increase follows the output-to-input price ratio, not the absolute price: a cheap model with a steep ratio takes a larger percentage than an expensive model with a flat one. ### Does prompt caching reduce the cost of reasoning tokens? No. Caching discounts input tokens and reasoning spends output tokens, so the saving in dollars is unchanged while the bill grows. On the 2026-10-14 OptimToken catalogue snapshot, across 163 reasoning-capable models with a working cache-read rate, caching removes a median 21.0% of a Knowledge Q&A request with no thinking budget and 11.5% once 1,000 thinking tokens are added. The share halves at a median of 1,300 thinking tokens, and under 2,000 for 163 of those models. ### Which discount applies to reasoning tokens? The batch tier, and only where it is published. On the 2026-10-14 OptimToken catalogue snapshot, 60 of the 209 reasoning-capable models publish a batch output rate, at a median 50% off list. Batch requires that nobody is waiting on the answer, which rules out agent loops, coding assistants and tool-calling chains whatever their thinking budget. ### How many models support reasoning? On the 2026-10-14 OptimToken catalogue snapshot, 216 of the 290 catalogued models expose a reasoning control, meaning the model accepts a thinking budget or effort setting on the request. The tag does not mean reasoning is enabled by default, and it is not a quality claim. It was read from model names until 2026-09-21, which found 46 models and included an image generator; it is now read from the upstream parameter list. ### Is there a case where the output rate does not dominate? Yes, where output is priced close to input. On the 2026-10-14 OptimToken catalogue snapshot, DeepSeek V4 Pro 0423 prices output at 2.00 times input, so 1,000 thinking tokens add 56% to a Knowledge Q&A request against 78% for the median reasoning-capable model. Check the ratio before applying the conclusion. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/cost-per-request-methodology Published: 2026-08-16. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: The exact formulas behind the list-price and after-discounts columns: token profiles, cache and batch rules, what the numbers exclude and where they mislead. # How we compute cost per request A specification, not an estimate. These are the formulas behind every cost-per-request figure on this site. Every model row carries two cost figures: Cost / 1K req (list price) and Cost / 1K req (after discounts). The table prints them per 1,000 requests so a column of them can be compared without counting zeros. The formulas and worked examples below are per single request, so multiply by 1,000 to land on the table's figure. They answer different questions, and the gap between them is the only part of the number you control. This page gives both formulas in full and the assumptions behind them. More usefully, it lists the things they leave out on purpose, because that is where a budget built on them goes wrong. ## The list-price formula Cost per request at the price we quote, with no optimisation assumed: cost = (inputTokens / 1,000,000) x inputPrice + (outputTokens / 1,000,000) x outputPrice That is the whole of it. The token counts come from the use-case profile you pick in the scenario bar; the prices come from the catalogue. Nothing else enters. Worked, on Claude Sonnet 5.5 (Anthropic, $2.00/M in, $10.00/M out) at the Support Ticket profile: Component | Tokens | Rate /1M | Cost Input | 1,500 | $2.00 | $0.0030 Output | 500 | $10.00 | $0.0050 Cost per request (list price) | | | $0.0080 ## The after-discounts formula Same request, priced as if you had implemented the two optimisations the model publishes a rate for. Four rules, applied in order: - Batch substitution. If the use case is asynchronous and the model publishes both batch rates, the batch input and output rates replace the list rates outright (where that discount is real). - Cache read on the hit-rate share. The profile's cache hit rate is the fraction of input tokens billed at the published cache-read rate; the remainder bills at whatever rate rule 1 left in place (what that discount is worth). - Cache write, amortised. A token can only be read from the cache after it has been written there, and models that publish a write rate charge more for it than for ordinary input. The formula assumes one token written for every 5 read. A written token is one of the cache misses, already billed at the input rate by rule 2. What is added is the premium: the published write rate minus that input rate, never below zero. Under batch the write rate is taken as published, because no model publishes a batch rate for it. A model that publishes a read rate but no write rate is assumed to write at the ordinary input rate: premium zero. - Fall back, never invent. A model that publishes no batch rate keeps list prices for rule 1. A model that publishes no cache-read rate has its cached share billed at the ordinary input rate, which makes the discount zero and leaves no write to charge. And if the write premium outweighs the read saving, the input side is billed uncached, since caching that does not pay is caching you would not switch on: the figure is never above list. writePremium = max(0, cacheWriteRate - inputRate) (0 when no write rate is published) writtenShare = min(hitRate / 5, 1 - hitRate) effectiveInput = cacheReadRate x hitRate + inputRate x (1 - hitRate) + writePremium x writtenShare effectiveInput = min(effectiveInput, inputRate) cost = (inputTokens / 1,000,000) x effectiveInput + (outputTokens / 1,000,000) x outputRate The 5 is a modelling assumption, not a published figure: how often a cached prefix is re-read before it must be rewritten is a property of your traffic. In a conversation, each turn re-reads the earlier turns and writes its own, which works out to (n - 1) / 2 reads per write over n turns, so 5 corresponds to a 11-turn session. A prompt shared by all requests under steady traffic does far better, and the same prompt at low volume does worse, because entries expire between requests. A write rate is published by 43 of the 288 priced models. Rule 4 is the one that matters when reading the table. The after-discounts column is never lower than what the published rates allow, so where a model publishes nothing, the two figures are identical and the table prints a dash in place of the second one. A dash means "nothing published", not "no savings available". The same request, now at the Support Ticket profile's 60% cache hit rate (this profile is synchronous, so no batch rate applies): Component | Tokens | Rate /1M | Cost Input, cache hit (60%) | 900 | $0.10 | $0.000090 Input, cache miss | 600 | $2.00 | $0.0012 Cache write premium, amortised (1 write per 5 reads) | 180 | $0.50 | $0.000090 Output | 500 | $10.00 | $0.0050 Cost per request (after discounts) | | | $0.0064 Claude Sonnet 5.5 publishes a cache-write rate of $2.50/M, 1.25x its input rate, so the written tokens cost the difference on top of the input rate their cache miss already paid. A 20.3% reduction, entirely from prompt caching. Note where it comes from: output is untouched, so the saving is bounded by the input share of the request before caching is even discussed. An asynchronous profile exercises both rules. At Meeting Summary (10,000 in, 1,200 out, 10% cache hit, batch-eligible) the batch rates replace list on both sides first, and the cache rate then applies to 10% of input: Component | Tokens | Rate /1M | Cost Input, cache hit (10%) | 1,000 | $0.10 | $0.000100 Input, cache miss (batch rate) | 9,000 | $1.00 | $0.0090 Cache write premium, amortised (1 write per 5 reads) | 200 | $1.50 | $0.000300 Output (batch rate) | 1,200 | $5.00 | $0.0060 Cost per request (after discounts) | | | $0.015 $0.032 at list, $0.015 after discounts: 51.9% off. The monthly figure is this number multiplied by your volume and nothing else. At 100,000 requests a month, $3.2K becomes $1.5K. Do not read 51.9% as typical. This example was chosen because it publishes both a cache and a batch rate, which only 70 of 288 priced models do. The median model on this profile saves 6.4%, for the reason set out in the next section. ## How much the after-discounts column is worth Measured across the 288 models carrying both prices, counting only those that receive a discount for that profile. Knowledge Q&A moves furthest at 21.0%; Marketing Content moves least at 3.9%. The ordering rewards cache hit rate rather than batch eligibility. Batch is the larger discount, half off a 30/70 blend of both sides on 68 of the 70 models publishing it. But it can only apply to the 70 models publishing a batch rate, so on an asynchronous profile the median model still gets nothing from it. A high cache hit rate pays out on every model publishing a cache rate. That is why the Meeting Summary example above saved 51.9% while the median model on the same profile saves 6.4%. The example publishes batch rates; 218 of the 288 priced models do not. Use case | Tokens in / out | Cache hit | Batch | Models discounted | Median saving Support Ticket | 1,500 / 500 | 60% | No | 198 of 288 | 20.3% Knowledge Q&A | 2,000 / 800 | 70% | No | 199 of 288 | 21.0% Meeting Summary | 10,000 / 1,200 | 10% | Yes | 204 of 288 | 6.4% Marketing Content | 2,500 / 1,800 | 20% | No | 198 of 288 | 3.9% Coding Task | 3,000 / 2,000 | 50% | No | 198 of 288 | 10.4% Invoice Processing | 1,500 / 600 | 30% | Yes | 224 of 288 | 11.2% Call Summary | 2,000 / 700 | 10% | Yes | 204 of 288 | 4.3% Agent Workflow | 6,000 / 3,000 | 70% | No | 198 of 288 | 18.0% These hit rates are modelling assumptions, not measurements of your traffic. They are the single biggest lever on the after-discounts column, so treat that column as a shape rather than a quote. ## Which models can be discounted at all Of the 288 priced models, 209 publish at least one discount rate. The other 79 publish neither and therefore have an after-discounts cost identical to list. That is a disclosure gap, not a pricing fact: a model may well have a batch endpoint with no published rate card. Where the table shows a dash, the correct reading is that we have nothing to quote. ## What these numbers deliberately exclude Every exclusion below is a decision, not an oversight. Each one would have made the figure look better and less true. - Your negotiated rates. These are public list prices. Committed spend, marketplace agreements and enterprise terms all sit outside them, and on an enterprise contract they are the largest single difference between this page and the invoice. - Your real cache behaviour. The write is charged at one per 5 reads and the hit rates assume steady traffic. At 10,000 requests a month a request arrives about every 4 minutes against a typical 5-minute cache lifetime, so entries expire between calls, writes multiply and the after-discounts figure is optimistic. Longer-lived cache tiers, sold at a higher write rate, are not modelled at all. - Retries and failures. A request that errors after generating output is billed. Timeouts, tool-call loops and validation retries are real line items that no token profile models. - Reasoning tokens. On models that think before answering, the reasoning trace bills as output and can dwarf the visible answer. The profiles here count the answer. - The system prompt, past the profile. Input tokens are the profile's assumption, not your prompt. A long system prompt, a tool schema or a RAG context window can multiply the input side. - Everything that is not tokens. Fine-tuning, embeddings, storage, egress, the compute you run around the model, and the engineering time to implement the caching this page credits you for. - Throughput and rate limits. Two models at the same cost per request are not equivalent if one needs three times the concurrency to hold your latency target. ## Using the number honestly - Compare with it; do not budget with it. Ranking models against one another is what a common set of assumptions is good for. A committed monthly figure needs your own token counts. - Measure your input-output split before trusting any saving. Caching cannot touch output, so an output-heavy workload has a low ceiling however good the hit rate. - Treat an identical column pair as missing data. Check the documentation of the host you buy from before concluding a model has no discount path. - Re-run after any model switch. Discount coverage is a model maker's billing policy, not a property of the model, so a migration can change the optimisation case even when the headline rates look similar. For a team at Crawl maturity the first step is splitting the bill into input, output, cache reads and cache writes, before any model is swapped. A team at Walk or Run already holds that split and can run the four rules on its own token counts instead of the presets. Every decision on this page depends on that split. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. ## Questions this guide answers ### What is the difference between list price and after-discounts cost per request? List price is the request's input and output tokens at the price we quote, with nothing else. After discounts swaps in the batch rate when the workload is asynchronous and a batch rate is published, bills the cached share of input at the cache-read rate, and adds the cache-write premium. On the 2026-10-14 OptimToken catalogue snapshot, 209 of the 288 priced models publish at least one discount rate. For the other 79 the two figures are identical. ### Which use case saves the most after discounts? On the 2026-10-14 OptimToken catalogue snapshot, Knowledge Q&A saves the most: a median 21.0% across the models that receive a discount on that profile. Marketing Content saves the least, at 3.9%. Cache hit rate decides the order, not batch eligibility, because batch only applies to models that publish a batch rate. ### What does a dash in the after-discounts column mean? It means the model publishes no cache-read or batch rate, so there is nothing to quote. It does not mean no saving exists: a model may have a batch endpoint with no published rate. On the 2026-10-14 OptimToken catalogue snapshot that applies to 79 of the 288 priced models. ### Can I budget with the after-discounts cost per request? Use it to compare models, not to commit a budget. It assumes modelled cache hit rates and one cache write per 5 reads, and it leaves out negotiated rates, retries, reasoning tokens and everything that is not tokens. On the 2026-10-14 OptimToken catalogue snapshot, the worked example, Claude Sonnet 5.5, drops from $0.032 to $0.015 per Meeting Summary request, 51.9% off. That is not typical: only 70 of the 288 priced models publish a batch rate. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/llm-pricing-statistics Published: 2026-10-05. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: How many LLM APIs carry a token price, which are the cheapest and the dearest, and the median price per million tokens by tier and by licence. Rebuilt daily. # LLM API pricing statistics: cheapest and median A FinOps guide by OptimNow · prices from the live OptimToken catalogue This page puts numbers on LLM API pricing: how many models carry a token price, which are the cheapest and the dearest, what the median model costs, and how wide each price tier is. Every figure is recomputed from the OptimToken catalogue when it refreshes, once a day. Each sentence that states one carries the date of the snapshot it describes, which is 2026-10-14 for this version. These are statistics of the prices OptimToken quotes: one host's rate per model, in USD per 1M tokens, at list price. What that covers and what it leaves out is set out under How these figures are calculated. ## Key figures on 2026-10-14 - As of 2026-10-14, the OptimToken catalogue quotes a token price for 280 LLM APIs from 41 model makers: 31 Frontier, 107 Mid-tier and 142 Budget. - As of 2026-10-14, the cheapest of 280 token-priced LLM APIs in the OptimToken catalogue is Mistral Nemo (Mistral), quoted at $0.029 per 1M input tokens and $0.03 per 1M output tokens, which is $0.03 on the blended price (30% input, 70% output). - As of 2026-10-14, the most expensive of 280 token-priced LLM APIs in the OptimToken catalogue is o1-pro (OpenAI), quoted at $150.00 per 1M input tokens and $600.00 per 1M output tokens, which is $465.00 on the blended price (30% input, 70% output). - As of 2026-10-14, the median price across 280 token-priced LLM APIs in the OptimToken catalogue is $0.42 per 1M input tokens and $1.94 per 1M output tokens, and the median blended price (30% input, 70% output) is $1.47. - As of 2026-10-14, quoted prices run from $0.016 to $150.00 per 1M input tokens and from $0.03 to $600.00 per 1M output tokens. - As of 2026-10-14, the median blended price (30% input, 70% output) per 1M tokens is $0.78 for the 35 open-source models, $0.73 for the 71 open-weights models, $4.09 for the 126 proprietary models and $0.93 for the 48 models with no established licence. - As of 2026-10-14, a batch rate is published for 70 of 280 token-priced models (25%) and a prompt-cache read rate for 198 (71%); 64 carry both and 76 carry neither. ## How many models, and who makes them Price tier | Models | Share | Model makers All tiers | 280 | 100% | 41 Frontier | 31 | 11% | 6 Mid-tier | 107 | 38% | 23 Budget | 142 | 51% | 35 As of 2026-10-14, the model makers with the most token-priced models are OpenAI (49), Alibaba (33) and Google (20). The catalogue also lists 8 image models. An image model's rate is not comparable with a text model's token price, so none enters the figures on this page. Also left out: 2 rows with no usable price on one side. ## What a million tokens costs As of 2026-10-14, the median price per 1M tokens by price tier is: Frontier, $5.00 input and $25.00 output (31 models); Mid-tier, $1.20 input and $4.40 output (107 models); Budget, $0.15 input and $0.59 output (142 models). As of 2026-10-14, the median token-priced model is quoted 4.0x as much for output tokens as for input tokens. Price tier | Models | Median input | Median output | Median blended | Input range | Output range All tiers | 280 | $0.42 | $1.94 | $1.47 | $0.016 to $150.00 | $0.03 to $600.00 Frontier | 31 | $5.00 | $25.00 | $19.00 | $2.50 to $150.00 | $15.00 to $600.00 Mid-tier | 107 | $1.20 | $4.40 | $3.41 | $0.04 to $4.35 | $2.00 to $14.00 Budget | 142 | $0.15 | $0.59 | $0.46 | $0.016 to $1.00 | $0.03 to $1.98 The blended price (30% input, 70% output) is the mix the pricing table ranks on. A tier is a price band, assigned from the quoted price alone. It is not a quality grade: the cheapest Frontier model is the lowest price in the top band, whatever it scores. Which models beat their price band is the subject of the quality per dollar guide. Snapshot of 2026-10-14. One band per power of ten of the blended price (30% input, 70% output); a band includes its lower bound. The highlighted band holds the median model. As of 2026-10-14, 122 of 280 token-priced models (44%) are quoted below $1 per 1M tokens on the blended price. ## The cheapest and the dearest models Model | Model maker | Input, per 1M | Output, per 1M | Blended | Quoted host Mistral Nemo | Mistral | $0.029 | $0.03 | $0.03 | DeepInfra (fp8 build) Ling 3.0 Flash | inclusionai | $0.021 | $0.063 | $0.05 | Novita Llama 3.1 8B Instruct | Meta | $0.05 | $0.08 | $0.071 | Groq Mistral Small 3 | Mistral | $0.05 | $0.08 | $0.071 | DeepInfra (fp8 build) Nex-N2.5-Mini | nex-agi | $0.025 | $0.10 | $0.077 | Nex AGI The price quoted for Mistral Nemo on 2026-10-14 is DeepInfra's rate for a quantized fp8 build, one of 5 hosts selling the model. Mistral, the model maker, charges $0.15 per 1M input tokens and $0.15 per 1M output tokens. Each figure is the price OptimToken quotes for the model, which is one host's rate: another host can charge more or less for the same model. Each model's page lists every host selling it; the quoted hosts above are from the 2026-10-14 read. Where a model runs, and what the channel changes, is covered in a guide of its own. As of 2026-10-14, the cheapest model in each price tier, ranked on the blended price and quoted per 1M tokens, is: Frontier, GPT-5.4 (OpenAI) at $2.50 input and $15.00 output; Mid-tier, Seed 1.6 (ByteDance) at $0.25 input and $2.00 output, level with 3 other models; Budget, Mistral Nemo (Mistral) at $0.029 input and $0.03 output. The cheapest model of each tier, on each of the 3 prices: Tier | On input, per 1M | On output, per 1M | On the blended price All tiers | DeepSeek V4 Flash 0731 $0.016 | Mistral Nemo $0.03 | Mistral Nemo $0.03 Frontier | GPT-5.4 $2.50 | GPT-5.4 $15.00 (6 others at this price) | GPT-5.4 $11.25 Mid-tier | Qwen3.8 27B $0.04 | Seed 1.6 $2.00 (8 others at this price) | Seed 1.6 $1.47 (3 others at this price) Budget | DeepSeek V4 Flash 0731 $0.016 | Mistral Nemo $0.03 | Mistral Nemo $0.03 As of 2026-10-14, the lowest input price, $0.016 per 1M tokens, is quoted for DeepSeek V4 Flash 0731 (DeepSeek), whose output is quoted at $0.64 per 1M tokens: 70 of the 280 models are cheaper on the blended price. And the dearest: Tier | On input, per 1M | On output, per 1M | On the blended price All tiers | o1-pro $150.00 | o1-pro $600.00 | o1-pro $465.00 Frontier | o1-pro $150.00 | o1-pro $600.00 | o1-pro $465.00 Mid-tier | MiMo-V2.6-Pro-UltraSpeed $4.35 | GPT-5.2 $14.00 (3 others at this price) | GPT-5.2 $10.32 (3 others at this price) Budget | Sonar $1.00 | DeepSeek V4 Pro 0813 $1.98 | DeepSeek V4 Pro 0423 $1.62 ## Open source, open weights and proprietary Openness is read from the licence, and it is a separate axis from the price tier. Open source means published weights under an OSI-approved licence with no field-of-use limit. Open weights means published weights under a licence that restricts something. Proprietary means API only. A model with no licence on record is counted on its own, as unknown, and assumed to be neither. Openness | Models | Share | Median input | Median output | Median blended Open source | 35 | 13% | $0.29 | $1.00 | $0.78 Open weights | 71 | 25% | $0.20 | $0.95 | $0.73 Proprietary | 126 | 45% | $1.25 | $5.50 | $4.09 Unknown | 48 | 17% | $0.28 | $1.20 | $0.93 As of 2026-10-14, the median open-weights model is quoted below the median proprietary model, which costs 5.6x as much on the blended price. Each of those medians is taken on the price OptimToken quotes, which is one host's rate per model. On the 2026-10-14 read of host prices, among the models sold by more than one host, the dearest host charged a median 1.8x the cheapest across 24 open-source models, 1.8x the cheapest across 31 open-weights models, 1.00x the cheapest across 70 proprietary models and 1.3x the cheapest across 4 models with no established licence. Rows are openness groups, columns are price tiers. The accent marks a group with no model in the Frontier tier. As of 2026-10-14, none of the 31 Frontier models is open source or open weights: 27 are proprietary and 4 carry no established licence. These medians compare groups of different models, at whatever quality each group holds. The comparison at matched quality, and what a licence buys beyond the price, is in Open weights against proprietary APIs. ## Batch and cache rates As of 2026-10-14, a batch rate is published for 70 of 280 token-priced models (25%) and a prompt-cache read rate for 198 (71%); 64 carry both and 76 carry neither. A cache write rate, the price of storing a prompt in the cache before it can be read back, is published for 44 of them. When each discount applies, and what it is worth on a real workload, is covered in Batch API economics and Prompt caching. ## What moved From 7 Oct to 14 Oct 2026: 3 price changes (2 up, 1 down) among 282 models compared. 29 other moves are flagged as a change of quoted host or an outlier listing. Since tracking began on 2026-08-15, the price OptimToken quotes has changed at least once for 60 of the 323 models tracked: 468 changes in all, up to 2026-10-14. Of those changes, 207 are established as a change of quoted host, a test that needs both days' host prices, archived from 2026-08-30. For the other 263 models, the quoted price has not changed since the first day in the archive. A price change, here as on the barometer, is a move in the price we quote that is not flagged as a change of quoted host or as an outlier listing. The price barometer lists every move of the latest window with its thresholds, and each completed week keeps a page of its own. ## How these figures are calculated - Source. Prices are list prices in USD per 1M tokens, read once a day from OpenRouter's public model list. Negotiated rates, committed-use discounts and provisioned capacity are not visible in them. - One price per model. OptimToken quotes one price per model: the rate of one host, the one OpenRouter uses as its reference for the model. A model can be sold by more than one host at more than one rate, so these are statistics of quoted prices, not of every host's price. On the 2026-10-14 read of host prices, 129 of the 280 token-priced models with host data were sold by more than one host, and for 30 of those the dearest host charged at least twice the cheapest. - Population. The statistics cover the 280 models in the Frontier, Mid-tier and Budget tiers that carry a price on both input and output. Image models are left out. - Median. The middle value once the models are ranked on a price. With an even number of models it is the mean of the 2 middle values. The input, output and blended medians are computed separately, so the blended median is not the blend of the other 2. - Blended price. One figure per model, weighted 30% input, 70% output. Your own workload has its own token mix: the cost per request methodology prices 8 of them. - Model makers. Counted from the maker named in the catalogue, ignoring capitalisation. - Refresh. The page is rebuilt from the catalogue once a day. A figure quoted from it is a figure of its date. ## How to cite this page The dataset behind this page is published under Creative Commons Attribution 4.0. Quote a figure with its date, because the figures change: OptimToken by OptimNow, LLM API pricing statistics, snapshot of 2026-10-14, https://optimtoken.optimnow.io/guides/llm-pricing-statistics The same catalogue is available as JSON at /api/llm-models and through the MCP server. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want these list prices set against what your own contracts charge, OptimNow runs that review. ## Questions this guide answers ### What is the cheapest LLM API? As of 2026-10-14, the cheapest of 280 token-priced LLM APIs in the OptimToken catalogue is Mistral Nemo (Mistral), quoted at $0.029 per 1M input tokens and $0.03 per 1M output tokens, which is $0.03 on the blended price (30% input, 70% output). The price quoted for Mistral Nemo on 2026-10-14 is DeepInfra's rate for a quantized fp8 build, one of 5 hosts selling the model. Mistral, the model maker, charges $0.15 per 1M input tokens and $0.15 per 1M output tokens. As of 2026-10-14, the cheapest model in each price tier, ranked on the blended price and quoted per 1M tokens, is: Frontier, GPT-5.4 (OpenAI) at $2.50 input and $15.00 output; Mid-tier, Seed 1.6 (ByteDance) at $0.25 input and $2.00 output, level with 3 other models; Budget, Mistral Nemo (Mistral) at $0.029 input and $0.03 output. ### How much do LLM APIs cost per million tokens? As of 2026-10-14, the median price across 280 token-priced LLM APIs in the OptimToken catalogue is $0.42 per 1M input tokens and $1.94 per 1M output tokens, and the median blended price (30% input, 70% output) is $1.47. As of 2026-10-14, quoted prices run from $0.016 to $150.00 per 1M input tokens and from $0.03 to $600.00 per 1M output tokens. As of 2026-10-14, the median price per 1M tokens by price tier is: Frontier, $5.00 input and $25.00 output (31 models); Mid-tier, $1.20 input and $4.40 output (107 models); Budget, $0.15 input and $0.59 output (142 models). ### Are open-weight models cheaper than proprietary ones? As of 2026-10-14, the median open-weights model is quoted below the median proprietary model, which costs 5.6x as much on the blended price. As of 2026-10-14, the median blended price (30% input, 70% output) per 1M tokens is $0.78 for the 35 open-source models, $0.73 for the 71 open-weights models, $4.09 for the 126 proprietary models and $0.93 for the 48 models with no established licence. Each of those medians is taken on the price OptimToken quotes, which is one host's rate per model. On the 2026-10-14 read of host prices, among the models sold by more than one host, the dearest host charged a median 1.8x the cheapest across 24 open-source models, 1.8x the cheapest across 31 open-weights models, 1.00x the cheapest across 70 proprietary models and 1.3x the cheapest across 4 models with no established licence. ### What is the most expensive LLM API? As of 2026-10-14, the most expensive of 280 token-priced LLM APIs in the OptimToken catalogue is o1-pro (OpenAI), quoted at $150.00 per 1M input tokens and $600.00 per 1M output tokens, which is $465.00 on the blended price (30% input, 70% output). ### How many LLM APIs publish batch and prompt-cache prices? As of 2026-10-14, a batch rate is published for 70 of 280 token-priced models (25%) and a prompt-cache read rate for 198 (71%); 64 carry both and 76 carry neither. A cache write rate, the price of storing a prompt in the cache before it can be read back, is published for 44 of them. ### How often do LLM API prices change? Since tracking began on 2026-08-15, the price OptimToken quotes has changed at least once for 60 of the 323 models tracked: 468 changes in all, up to 2026-10-14. Of those changes, 207 are established as a change of quoted host, a test that needs both days' host prices, archived from 2026-08-30. From 7 Oct to 14 Oct 2026: 3 price changes (2 up, 1 down) among 282 models compared. 29 other moves are flagged as a change of quoted host or an outlier listing. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/open-weights-vs-proprietary Published: 2026-08-30. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: Open-licensed models undercut proprietary APIs at matched quality across most of the range, but the open catalogue stops below the top tier. Live prices. # Open weights against proprietary APIs: the cost gap in numbers A FinOps guide by OptimNow · prices from the live OptimToken catalogue The argument for open-licensed models arrives as a price argument: publish the weights, let anyone serve them, watch the rate drop. The numbers support that, up to a point, and the point is sharper than the argument suggests. This guide measures the gap three ways: across every model, at matched quality, and at the ceiling where the open models run out. ## Openness is not a price tier Two things about a model are easy to run together. One is what it costs: Frontier, Mid-tier or Budget, read from the rate card. The other is whose hardware can run it, read from the licence. Open source means OSI-approved terms with no field-of-use limit. Open weights means published weights under a licence that restricts something. Proprietary means API only, and Unknown means no licence is recorded. Of 290 priced models today, 35 are open source, 71 are open weights, 134 are proprietary and 50 carry no established licence. The unknown group stays unknown rather than guessed. Blended 30/70 input-output mix, the same weighting the pricing table ranks on. Medians across every priced model in the group, at all quality levels. Read straight off, the proprietary median of $4.38 sits 5.9x above the open median of $0.741. That is the number most often quoted, and on its own it proves little. The two groups are not the same models at different prices; they are different models. Proprietary catalogues carry the frontier tier, plus every superseded flagship still on sale behind it. The open groups sit almost entirely in the middle of the market. ## The quality-matched comparison, and the ceiling Arena scores give a common yardstick, on 72 of 290 priced models (27 open, 45 proprietary), scored as of 2026-10-08. Splitting the ranked models into score bands shows why the median comparison misleads. It also shows the finding that matters more than any price ratio on this page. Highest band first. The pale bar is every ranked model in the band, the dark bar the open-licensed subset. The best-ranked open model is GLM 5.3 at 1478 (Open source, Apache 2.0). Above that score sit 11 proprietary models and no open ones: Claude Opus 5.5 (1507), Claude Fable 5 (1504), Claude Fable 5.1 (1501), Claude Opus 4.6 (1498), among others. For a workload that needs quality above 1478 on this benchmark, openness is not a lever. No price buys an open model there, because none exists. ## Below the ceiling, the gap is large Inside the overlap the comparison becomes fair, and it is worth running per model rather than per group. For each ranked proprietary model, take every open model with an equal or better Arena score, then the cheapest of those. Of the 45 proprietary models, 34 have such a match. Of those 34 matches, 34 are cheaper, at a median of 17.6x. One caveat belongs next to that figure. DeepSeek V4 Flash 0423 is the cheapest qualifying substitute in 16 of the 34 matches, and 2 model makers account for every substitute in the set (Zhipu, DeepSeek). The gap sits in 3 aggressively priced models, not across the open catalogue. Read it as "3 open models are priced far below their measured rank", not as "open licensing is cheaper". It is also fragile: those rates are set by whoever serves the weights, and they move. Reviewed against the catalogue on 2026-10-11. At publication, on the 2026-08-30 snapshot, the open substitute was cheaper in 35 of 36 matches at a median 17.5x, with one model the cheapest answer in 19 of them. On the 2026-10-14 snapshot it is 34 of 34 at 17.6x, with DeepSeek V4 Flash 0423 the cheapest answer in 16. The direction held; the median held, and the paragraph above says why a figure measured on one host's rate does that. How fragile is measurable. Each price above is the price we quote, which is the rate of one host: a company that runs the model and sells it by the token. Of the open models priced here, 55 are sold by more than one host. Repeat the matched test pricing every open model at its cheapest host and the median gap is 41.9x. Price them at their dearest and it is 6.3x, on the same models and the same day. The proprietary side barely moves under the same treatment: the hosts of a proprietary model charge one rate, a median spread of 1.00x measured below. So treat the 17.6x as the middle of a range you land in by choosing a host, not as a rate card. Which host a price belongs to, and what else the choice changes, is a guide of its own. ## What crossing the ceiling costs At the top of the open range the rule reverses. The best open model, GLM 5.3, sits at 1478 and $3.381 blended. Better ranked and cheaper than it are 2 proprietary models: Gemini 3.7 Flash (1486, $2.85 blended), Gemini 3.6 Flash (1482, $2.85 blended). A buyer picking the strongest open model available is paying more for less measured quality than a mid-tier proprietary model on the same page. ## What that costs at volume The Knowledge Q&A preset (2,000 input + 800 output tokens per request), at 1,000,000 requests per month: Model | Openness | ELO | List in / out per 1M | Cost/req | Monthly at 1M req GLM 5.3 | Open source | 1478 | $0.07 / $4.80 | $0.0040 | $4.0K Gemini 3.7 Flash | Proprietary | 1486 | $0.75 / $3.75 | $0.0045 | $4.5K o1 | Proprietary | 1402 | $15.00 / $60.00 | $0.078 | $78.0K DeepSeek V4 Flash 0423 | Open source | 1436 | $0.091 / $0.182 | $0.000328 | $328 Whose rate: DeepSeek V4 Flash 0423's quoted rate is DeepInfra's (a build quantized to fp8); the model maker publishes no rate of its own. The first two rows are the ceiling trade: GLM 5.3 is the best open model on offer, Gemini 3.7 Flash the cheapest thing that outranks it. Compare them side by side before the licence decides it. The last two are the widest matched gap in the catalogue, o1 against DeepSeek V4 Flash 0423 at 301x. Of the 10 widest gaps, 8 sit on proprietary models released at least 12 months before this snapshot. Read a multiple that size as a signal about a model your workloads have outgrown, not as the going rate for proprietary inference. ## The licence is not the price, it is the exit Every price on this page is a hosted API rate, open models included. Publishing weights does not make inference free. It makes the serving market competitive, and someone still runs the GPUs. What the licence buys is optionality: the right to move the same model onto your own hardware if the rate moves, the host withdraws it, or data residency rules out the API. "Competitive" is measurable. Across the models sold by more than one host, an open model's dearest host charges a median 1.8x its cheapest (n=55). For proprietary models the same figure is 1.00x (n=73): you pay what the model maker charges, wherever you buy it. That is the licence showing up in the price before anyone self-hosts anything. One side of this comparison is a negotiation and the other is a rate card. It also cuts the other way: 48 of the open models priced here have no rate from their own model maker in our data. Every rate quoted for them comes from another host, with no model maker's rate to fall back on if that host withdraws. That right is not uniform, which is why open source and open weights are kept apart. Of the 27 ranked open models, 10 carry OSI-approved terms (Apache 2.0 or MIT). The other 17 carry a licence that restricts something: an acceptable-use clause, a monthly-active-user threshold, or a non-commercial term. Both are self-hostable. Only one is unconditionally deployable in a commercial product, and the check is a licence read, not a category glance. Pricing the exit is a separate exercise, and the per-token gap is a poor guide to it. Self-hosting swaps a variable per-token bill for a fixed per-hour one. GPUs bill whether or not they serve traffic, and storage is extra. So is the operations work that TCO calculators leave out: driver and inference-stack upgrades, capacity sizing, preemption handling, model revalidation on every update, on-call. OptimNow's practice reference puts the crossover for a dedicated deployment at roughly 200M to 500M tokens per day, depending on model size and quantisation, with 0.5 to 2 dedicated ML-Ops FTE. Below those volumes, and below FinOps Run maturity, that reference finds the managed API the cheaper answer even when the per-token rate is higher. ## What to do with this - Check the ceiling before the price. If the workload needs quality above 1478, the open question is closed and the decision is which proprietary model. - Run the substitution per workload, not per catalogue. The median 17.6x is a distribution, not a rate. Your shortlist may sit in the part of it where the gap is small or negative. - Name the host before you quote the price. An open model's rate is a range across hosts, not a number: the median gap between the cheapest and dearest is 1.8x. A business case built on the cheapest rate is built on one host's pricing decision. - Read the licence before the roadmap. Open weights and open source are different commercial positions, and the difference only appears in production. - Treat these as list prices, not spend. Arena is one general benchmark; treat a gap under roughly 20 points as noise. Figures on this page come from the 2026-10-14 price snapshot and rebuild nightly. Host prices are from the 2026-10-14 read. Filter the pricing table by Openness in the Business view to run this against your own shortlist. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want the self-hosted question priced against 90 days of your own usage data, OptimNow runs that review. ## Questions this guide answers ### Are open models cheaper than proprietary APIs? Across the whole catalogue, yes, though the headline overstates it. On the 2026-10-14 OptimToken catalogue snapshot, the median proprietary model costs 5.9x the median open source or open weights one ($4.38 against $0.741 per 1M tokens blended). The two groups are mostly different models at different quality levels. Matched on Arena score, 34 of 34 proprietary models with an open equal have a cheaper one, at a median 17.6x. ### What is the highest-ranked open model? By Arena score on the 2026-10-14 OptimToken catalogue snapshot (scores as of 2026-10-08), GLM 5.3 at 1478, licensed Apache 2.0 (Open source). Above that score sit 11 proprietary models and no open ones. For a workload that needs quality above 1478, openness is not a lever. ### Does the host change the price of an open model? Yes, by a wide margin. On the 2026-10-14 OptimToken catalogue snapshot, among models sold by more than one host, an open model's dearest host charges a median 1.8x its cheapest. For proprietary models the figure is 1.00x. Pricing each open model at its cheapest or its dearest host moves the matched median gap from 41.9x to 6.3x. ### What is the difference between open source and open weights? Open source means published weights under OSI-approved terms with no field-of-use limit, such as Apache 2.0 or MIT. Open weights means published weights under a licence that restricts something: an acceptable-use clause, a user-count threshold or a non-commercial term. Both can be self-hosted. On the 2026-10-14 OptimToken catalogue snapshot, 10 of the 27 Arena-ranked open models are open source and 17 are open weights. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/prompt-caching-economics Published: 2026-08-16. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: Cache reads bill at a fraction of the input price, but the saving that reaches the bill is far smaller than the headline. Break-even by use case, live prices. # Prompt caching: the discount nobody budgets for A FinOps guide by OptimNow · prices from the live OptimToken catalogue Of the discounts published on an LLM rate card, prompt caching carries the largest percentage. Across the 203 models on OptimToken that publish a cache-read price, the median is 89% off input. It is also the narrowest: it applies to input tokens only, and only to the share of them that repeats. At the hit rates modelled for the 8 use-case presets on the pricing table, the median saving that reaches an invoice runs from 3.3% on Call Summary to 21.0% on Knowledge Q&A. ## The discount is not one number Rate cards do not agree on what a cache read costs. The 3 most common published rates are 10%, 20% and 25% of the list input price, and the full range runs from 0% off to 99% off. Of the 290 models, 87 publish no cache-read price at all, which in practice means no cache discount to plan around. Published cache-read price against list input price, per model. The headline band, 90% off or better, covers 102 of the 203 models that publish a rate. Two consequences for model selection. A cache-heavy architecture is worth more on some models than others, so the cache rate belongs in the comparison alongside input and output. And a switch between two similarly priced models can change the cache economics without changing the list price at all. ## Why the headline never reaches the bill A cache read discounts input tokens. It does nothing to output tokens, and output is where most of the money goes on a typical workload. Two multipliers sit between the headline and the invoice: the share of the bill that is input, and the share of input that is a cache hit rather than a fresh read. Median across the 203 models publishing a cache-read rate, for the 8 use-case presets on the pricing table. The dark bar is the ceiling: what caching would save if every input token were a hit. The green bar is the saving at each profile's modelled hit rate. The ceiling matters as much as the realised figure. Even at a perfect hit rate, the median saving tops out at 56.3% on Meeting Summary, the most input-heavy profile, and sits at 19.6% on Marketing Content, where long outputs dominate. The 89% is a discount on input tokens, not on the bill, and those are different budgets. ## Worked example: an agent workflow at 100,000 requests/month The Agent Workflow preset models 6,000 input and 3,000 output tokens per request, at a 70% cache hit rate. Agent loops re-send a large stable prefix (system prompt, tool definitions, prior turns) on every call, which is the pattern caching was designed for. Model | Cache discount | Cost/req (list) | Cost/req (cached) | Monthly (list) | Cache saves Claude Opus 5 | 90% | $0.105 | $0.086 | $10.5K | $1.9K (18.0%) GPT-5.5 | 90% | $0.120 | $0.101 | $12.0K | $1.9K (15.7%) On Claude Opus 5, caching returns $1.9K a month at this volume, against a list rate of $5.00/M input and $25.00/M output. A saving of that size pays for a caching project at this volume. It is also 18.0% of the bill, not 90%. GPT-5.5 returns the same $1.9K, from the same input price and the same 90% cache rate, but against a larger bill, so it lands at 15.7%. The cache rate is identical on both rows. The output price decides what it is worth. Compare the two side by side before assuming the cache rate settles the choice. ## The same model, a workload where it does not pay Hold the model still and change the workload. On the Marketing Content profile (2,500 in, 1,800 out, 20% hit rate), the same Claude Opus 5 saves 3.9%: $225 a month instead of $1.9K. The cache rate did not change. The workload writes long outputs from short, mostly fresh prompts, so there is little input to discount and little of it repeats. Generation-heavy work with varied prompts is the case where a caching project does not repay the effort of building it. ## The cache price that saves nothing For 5 models the catalogue quotes a cache-read price identical to the list input price, among them DeepSeek V4 Flash 0731, Schematron V2 Turbo, Schematron V2 Small, Qwen3.6 35B A3B. The quoted price is one host's rate, and on these rows that host lists the two fields at one figure. The field is populated, so a spreadsheet that scores a model on whether a cache price exists scores these as cache-friendly. The discount is 0%. Compare the cache rate against the input rate, and never test for the presence of a rate. ## The write premium, which most business cases leave out Every figure above uses published read prices only, so each is a ceiling on the saving rather than the saving. Writing to the cache is billed separately, and above the standard input rate. Business cases leave the write out, and it decides whether caching pays at all. Anthropic publishes ×1.25 on input for a 5-minute entry and ×2 on input for a 1-hour entry. Other model makers structure it differently, and some fold the write into the standard input price, so treat these as Anthropic's published terms rather than a market rate. They are the only 2 numbers on this page not computed from the catalogue. The hub's own Cost/req (after discounts) column does charge the write, which is why it can sit slightly above the read-only figures on this page. It assumes one token written for every 5 read. The write is billed at the model's published write rate where there is one, and at the ordinary input rate where there is not (the full formula). The premium sets a break-even: a cached prefix has to be read enough times inside its lifetime to earn back what the write cost. Against the read rates published today: Published read rate | Models at this rate | Break-even, 5-minute cache | Break-even, 1-hour cache 10% of input | 88 | 2 calls | 3 calls 20% of input | 28 | 2 calls | 3 calls 25% of input | 23 | 2 calls | 3 calls 75% of input | 1 | 3 calls | 6 calls Read the table as a floor, not a target. At the least favourable rate in the catalogue (1 model at 75% of input), 6 calls sharing one prefix are enough; at the 3 most common rates, 3 calls. On a high-traffic path the break-even is reached in the first minute. It also names the failure case exactly. A workload whose calls arrive further apart than the cache lifetime never reaches the second read. Every call writes a fresh entry, and the prefix bills at ×1.25 or ×2 of input instead of ×1. Cached, that endpoint costs more than leaving it alone. The variables are request rate and prefix stability, not prompt size: a large prompt cached once an hour loses money, and a small one cached every second makes it. ## What to check before budgeting a caching saving - Compute the input share of your own bill first. Caching cannot save more than that share, whatever the discount. On the Marketing Content profile the median model spends 74% of the request on output, so the ceiling is set before caching enters the discussion. - Measure the hit rate, do not assume it. The gap between the two bars in the chart above is entirely hit rate. The API reports cache-read and cache-write tokens separately; that ratio is the number to track. - Check the prefix is stable byte for byte. A timestamp, a session ID or a reordered tool list at the top of a prompt invalidates the entry. This is the most common reason a measured hit rate lands far below the modelled one. - Match the cache tier to the traffic pattern. The longer tier costs twice the input rate to write. It pays only when calls are spread out enough to need it and frequent enough to reach break-even. - Recheck after any model switch. Published discounts run from 0% to 99% across this catalogue, so a migration can change the caching business case even when list prices look similar. For an organisation early in its FinOps practice, the useful first step is measurement rather than optimisation: split the bill into input and output, then into cache reads and writes. Teams already tracking that split can move to the break-even test per endpoint. These figures are list prices from the current snapshot, not audited spend, and they assume the token presets on the pricing table rather than your own traffic. Batch is the other published discount, and the one that reaches output tokens: when the −50% applies covers it. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. ## Questions this guide answers ### How much does prompt caching save? On the input tokens it covers, a median 89% off the list input price, across the 203 models on the 2026-10-14 OptimToken catalogue snapshot that publish a cache-read rate. The saving on the whole bill is far smaller, because caching never touches output. At the modelled hit rates the median saving runs from 3.3% on Call Summary to 21.0% on Knowledge Q&A. ### How many LLMs publish a prompt caching price? On the 2026-10-14 OptimToken catalogue snapshot, 203 of the 290 models publish a cache-read price and 87 publish none. Published discounts run from 0% to 99% off input. In 5 cases the cache price equals the input price, so the discount is 0%. ### Does prompt caching reduce output token costs? No. A cache read discounts input tokens only. On the 2026-10-14 OptimToken catalogue snapshot, even at a perfect hit rate the median saving tops out at 56.3% of the bill on Meeting Summary, the most input-heavy use case. On Marketing Content, where long outputs dominate, the ceiling is 19.6%. ### When does prompt caching cost more than it saves? When calls sharing a prefix arrive further apart than the cache lifetime. Every call then writes a fresh entry at Anthropic's published 1.25x of input for a 5-minute cache or 2x for a 1-hour cache, and no call reaches the cheap second read. Against the read rates published on the 2026-10-14 OptimToken catalogue snapshot, 6 calls sharing one prefix inside its lifetime are enough to break even at the least favourable rate. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/quality-per-dollar Published: 2026-08-23. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: A model's price class comes from its rate card, not its quality. Measured against Arena scores, most of the catalogue has a cheaper equal. Current prices. # Quality per dollar: the models that beat their price class A FinOps guide by OptimNow · prices from the live OptimToken catalogue OptimToken files every model into a price class: Frontier, Mid-tier or Budget. The label comes from the price we quote for the model and from nothing else. Quality is measured separately, by the LMArena preference score. This guide puts the two side by side and asks which models deliver more quality than their price suggests, and which charge a premium the scores cannot justify. Of the 290 models in the catalogue, 72 carry both a price and an Arena score. Everything below is computed from those 72. ## A price class is not a quality tier Frontier spans 1324 to 1507 on Arena. Budget spans 1211 to 1475. On one axis, the classes overlap across most of their range. Price class comes only from the price we quote (see the category rules on the pricing table). Arena scores are a separate input, last updated 2026-10-08. Of the 72 ranked models, 50 sit in the band where Frontier and Budget overlap (1324 to 1475 on Arena). Inside it, blended list prices run from $0.1547 to $46.50 per 1M tokens: a 301x spread across models the benchmark cannot tell apart. On average, paying more still buys quality, since the class medians rank in the expected order. A shortlist is not made of averages. For an individual model, the class label predicts the bill and little else. ## What the efficiency score measures The pricing table's Efficiency score joins the two axes into one number. Each ranked model is placed twice, by Arena score and by blended list price, and the score is 60% of the quality rank plus 40% of the price rank. The weighting leans toward quality, so a cheap model with a weak score cannot climb on price alone. GLM 5.3 Flash tops it today at 83, on Arena 1475 and $0.6408 per 1M blended. Both halves are relative, so the ranking moves as prices do. Score = 60% quality percentile + 40% price percentile, ranked among the 72 models carrying an Arena score. ## The substitution test The same question in cash terms: whether, for each ranked model, a cheaper model with an equal or better Arena score exists. Substitutes are drawn only from models still on sale. A deprecated model can be on your bill; it should not be on your shortlist, and OptimToken marks the deprecations model makers announce in the pricing table. The answer is yes for 64 of the 72 ranked models, at a median premium of 5.5x on the blended price. Priced on a workload's own token mix, the individual premiums move; the worked examples below are costed on one such mix. One caveat carries more weight than the aggregate: DeepSeek V4 Flash 0423 ($0.1547 per 1M blended) is the cheapest answer in 28 of those 64 cases. This is a single model, licensed Apache 2.0, sitting far below the price of its measured quality, not a broad menu of substitutes. Rule it out for licensing or data-residency reasons and most of that headroom goes with it. Reviewed against the catalogue on 2026-10-11. At publication, on the 2026-08-23 snapshot, the test was failed by 63 of 74 ranked models at a median premium of 11.5x; on the 2026-10-14 snapshot it is 64 of 72 at 5.5x. The share with a cheaper equal held. The median premium fell: it is measured against whichever cheap model carries a high Arena score that day, and that model's quoted price moves with its quoted host. ## Worked example: the three largest premiums The three largest premiums among models still sold today, costed on the Support Ticket preset (1,500 input + 500 output tokens per request) at 100,000 requests per month. The premium column is the ratio of the two monthly costs before rounding: Paying for | Cheaper equal | Monthly | Monthly (alternative) | Premium GPT-5.2 Arena 1435 | DeepSeek V4 Flash 0423 Arena 1436 | $963 | $23 | 42.3x Claude Opus 4.8 Arena 1474 | GLM 5.3 Flash Arena 1475 | $2.0K | $50 | 39.7x Claude Opus 4.5 Arena 1470 | GLM 5.3 Flash Arena 1475 | $2.0K | $50 | 39.7x These figures are the cost of inference only: tokens at the public list price. They include no cache or batch discounts, no negotiated rates, and nothing around the API call. Self-hosting an open-weights model is a different cost structure entirely, GPUs instead of tokens, and the open-weights guide prices that gap. These are substitution candidates, not recommendations. Arena measures general preference on open-ended prompts, not your workload. What a gap this size does support is an evaluation on your own traffic, costed against one month of the premium column above. ## Where the premium is real The test cuts both ways. Of the 62 ranked models still on sale, 8 have no cheaper equal anywhere in the catalogue. For those, the price buys measured quality nothing else offers for less. Claude Opus 5.5 sits at the top, at Arena 1507 and $15.20 per 1M blended. Its efficiency score is only 66, because the score rewards value, not capability. If an evaluation says a workload needs that level, a low efficiency score is no argument against it: the substitution does not exist. Compare the two ends of the range to see what the money buys. ## Old models keep their launch price Among the 15 models paying 20x or more, 13 were released at least 12 months before this snapshot: 87% of the group, against 38% across the whole ranked population. In this catalogue the pattern holds: model makers rarely reprice an old model downward. They release a new one and leave the old rate card in place. Of the 15, 9 sit on models whose maker has already announced retirement. The useful habit is an inventory, not a negotiation. For a team at Crawl maturity, the list of which model each workload pins is the first artefact to build. At Walk and Run, checking that list against the catalogue quarterly is a standing control. A workload pinned to a 2-year-old model pays an old price for old quality, and neither half shows up in the invoice. ## What these numbers do not say - Arena is one benchmark, and a general one. It says nothing about latency, tool calling, structured output or languages other than English. Treat a gap under roughly 20 points as noise. - Coverage is partial. Only 72 of 290 catalogued models carry an Arena score. A model missing here is unranked, not bad. - The price axis is a 30/70 blend. A workload with a different token mix reorders it, which is why the table's cost columns run on use-case profiles instead. - Switching costs money. Prompt rework, re-evaluation and a second vendor relationship are real. The gaps above are large enough to survive that. Whether a 1.5x gap is depends on the migration's engineering cost, which this page does not price. The pricing table's FinOps Friendly badge applies a stricter version of this test; 11 of the 72 ranked models hold it today. Sort the pricing table by Efficiency for the full ranking, and check the cost columns against your own token mix before acting on any of it. Figures on this page come from the 2026-10-14 price snapshot and rebuild nightly. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. ## Questions this guide answers ### Does a more expensive LLM mean better quality? Only on average. On the 2026-10-14 OptimToken catalogue snapshot the price-class medians rank Frontier above Mid-tier above Budget on Arena, but Frontier and Budget models overlap from 1324 to 1475. Of the 72 ranked models, 50 sit in that band, where blended list prices run from $0.1547 to $46.50 per 1M tokens: a 301x spread across models the benchmark cannot tell apart. ### Is there a cheaper LLM with the same quality? For most ranked models. On the 2026-10-14 OptimToken catalogue snapshot, 64 of the 72 have a cheaper model, still on sale, with an equal or better Arena score. The median premium is 5.5x on the blended price. One model, DeepSeek V4 Flash 0423, is the cheapest answer in 28 of those cases, so ruling it out for licensing or data-residency reasons removes most of that headroom. ### What is the OptimToken efficiency score? It is 60% of a model's Arena quality percentile plus 40% of its blended-price percentile, ranked among the 72 models carrying an Arena score on the 2026-10-14 OptimToken catalogue snapshot (Arena scores as of 2026-10-08). GLM 5.3 Flash tops it at 83. The best-ranked model with no cheaper equal, Claude Opus 5.5, scores 66, because the score rewards value, not capability. ### Do older LLMs cost more than newer models of the same quality? In this catalogue, yes. Model makers rarely reprice an old model downward: they release a new one and leave the old rate card in place. On the 2026-10-14 OptimToken catalogue snapshot, 13 of the 15 models paying 20x or more over a cheaper equal were released at least 12 months earlier. That is 87% of the group, against 38% of the whole ranked population. ------------------------------------------------------------------------ URL: https://optimtoken.optimnow.io/guides/where-to-run-a-model Published: 2026-09-06. Figures from the 2026-10-14 catalogue snapshot; the page rebuilds nightly. Summary: The same model is sold by its model maker and by the hyperscalers. The token rate is identical on most comparisons; regions and commitment terms are not. # Bedrock, Vertex, Azure or direct: what the channel changes A FinOps guide by OptimNow · prices from the live OptimToken catalogue Most models on a shortlist are sold in more than one place. Claude is on Anthropic's own API, on AWS Bedrock and on Google Vertex. GPT-5.6 is on OpenAI's API, on Azure AI Foundry and, since 2026, on Bedrock. This guide calls each of those places a channel. Procurement starts by asking which channel is cheapest. Across the models the hub tracks, that question has a dull answer, and the differences worth negotiating are elsewhere. ## How many channels sell a model The hub keeps a hand-checked list of where each model is sold. It covers 59 of the 290 models in the catalogue. By channel count, 21 are sold through 4 channels, 22 through 3, 16 through 2. The list says where a model can be bought, and nothing about the price there. The pale bar is all 59 models, the dark bar is the ones that channel carries. Every model is on OpenRouter, because that is where the hub reads its prices. Of the 59, 6 have no direct API from their model maker. Llama 4 Maverick, Llama 4 Scout, Nova Premier 1.0, Nova Micro 1.0 and 2 more are sold only through other channels. Meta publishes Llama weights and runs no service of its own, and Amazon sells Nova through Bedrock alone, so for those a cloud is the only shop. ## The price does not move Every night the hub reads the rate each host publishes for a model. A host is a company that runs the model and sells it by the token: the model maker, a cloud platform like Amazon Bedrock, Azure or Vertex, or an independent host. For 28 models both the model maker and at least one of those clouds publish a rate, which gives 62 comparisons. Of those, 54 are identical, input and output, to the cent. Take Claude Fable 5, sold through 4 channels and priced by 5 hosts on 2026-10-14: Host | Input /1M | Output /1M | Blended 30/70 | Against the model maker Anthropic (model maker) | $10.00 | $50.00 | $38.00 | same Claude Platform on AWS | $10.00 | $50.00 | $38.00 | same Azure | $10.00 | $50.00 | $38.00 | same Amazon Bedrock | $10.00 | $50.00 | $38.00 | same Google | $10.00 | $50.00 | $38.00 | same Moving that workload from the model maker to a cloud saves nothing on the rate. The clouds charge the model maker's own rate. Every cloud does the same, to the cent, for 21 of the 28 proprietary models that the model maker and at least one cloud both price. The 8 comparisons that do differ deserve a read before anyone concludes that a cloud marks the model up. Of them, 5 sit at exactly 10% above the model maker's rate. AWS documents a 10% premium on regional endpoints for recent Claude models, against its global ones. So the likeliest reading is an endpoint choice, not a markup. The hub cannot see which endpoint each row prices, so treat that as a lead to check. The other 3 gaps are wider, and a gap that wide is the signature of two different products: hosts list a cheaper asynchronous tier and a dearer priority tier next to the standard one. Check that both rows are the same tier before you act on the gap. ## Where the host is the whole price decision That flat price is a feature of proprietary models. Split the 59 by licence and the two halves behave differently. The 45 proprietary models have a median of 2 hosts and a median gap of 1.00x between the cheapest and the dearest. The 14 open-weights and open-source models have a median of 4 hosts and a median gap of 1.45x. One model maker setting a price is a rate card. More than one host serving the same downloadable weights is a market, and a market has a spread. DeepSeek V3.2 is the widest case: 12 hosts, from $0.2794 per 1M tokens at GMICloud to $4.05 at SambaNova. That is 14.5x for the same weights, and here the host decides the bill. The cheap end is not free of catches, because hosts differ on quantization, context limit and throughput, so test the cheapest one on your own prompts before you budget on it. Compare the two examples side by side. Command A is the opposite case: sold through 4 channels, and exactly one of them publishes a price the hub can read. A channel can carry a model without telling you what it costs there. Four logos on a slide are not four quotes. ## What does move: where the model runs A model bought through a cloud runs only where that cloud serves it, and the map differs by model. On Bedrock, Claude Haiku 4.5 is served in 12 regions and R1 in 3. Of the 16 models on the checked list, 2 have no European region at all: DeepSeek V3.2 and R1. From the 2026-10-12 sweep of 18 Bedrock regions. Bedrock is the only channel that publishes this per model, so it is the one shown. Global inference profiles are not counted: they route anywhere, which is not an answer to a residency question. A model can win the benchmark and fit the budget and still be unusable for a workload that must keep its data in Europe. A team that finds this out at deployment, after the shortlist has closed, has nothing left to swap in. Check the map while the shortlist is still open. ## Where the channels part ways: commitment terms Same price, different regions. The third difference appears when the workload is large enough to reserve capacity. The three clouds sell reserved inference on terms that do not line up, and this is where a channel choice becomes hard to undo: | AWS Bedrock | Google Vertex | Azure AI Foundry Commitment scope | Locked to one model | One publisher, any of its models | Pooled units, any model Upgrade mid-term | No | Within the publisher | Yes Overflow past reserved capacity | Build the failover yourself | Pay-as-you-go by default | Opt-in spillover per deployment Cost attribution | IAM principal, inference profiles, project tags | Billing labels, BigQuery export | Resource tags, cost analysis Read the top row against a model roadmap that moves every few months. A commitment locked to one model is stranded the day its successor ships, and the two prices you compared at the start were identical anyway. This is the FinOps Foundation's GenAI capacity framing, as distilled in OptimNow's practice library: commitment terms, not token rates, are where a channel decision gets expensive. Size any reservation to average load, with a spillover path for the peaks. That sizing needs a load curve, which a team at Walk or Run maturity holds and a team at Crawl does not: without one, stay pay-as-you-go until the first 90 days of usage are in. ## Running the check on your own shortlist - Compare prices within one tier. A batch or flex row against a standard row is a different product, not a channel saving. - For a proprietary model, compare terms, not prices. Commitment scope, spillover, cost attribution and regions carry the whole difference. - For an open-weights model, pick the host. Then test the cheap end on your own prompts, because quantization and context limits vary at the same price. - Check regions before the shortlist closes. Residency rules eliminate models late and silently. - Keep an exit. Three channels means you can move; one host plus a term commitment means you cannot. Figures on this page come from the 2026-10-14 catalogue snapshot and the 2026-10-14 host prices, and rebuild nightly. The pricing table filters by Available on, and every model page lists its hosts with the rate each one publishes. The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills. If you want a channel and commitment review run against your own inference usage, OptimNow does that work. ## Questions this guide answers ### Is a model cheaper on Bedrock, Vertex or Azure than from its model maker? For most comparisons, no. On the 2026-10-14 OptimToken catalogue snapshot, with host prices read on 2026-10-14, the model maker and at least one cloud both price 28 models, which gives 62 comparisons. Of those, 54 are identical to the cent on input and output. Another 5 sit at exactly 10% above the model maker's rate, which matches the premium AWS documents on regional endpoints. ### How many places sell the same LLM? On the 2026-10-14 OptimToken catalogue snapshot, the hub's hand-checked availability list covers 59 of the 290 models. By channel count, 21 are sold through 4 channels, 22 through 3, 16 through 2. Of the 59, 6 have no direct API from their model maker and are sold only through other channels. ### Why does an open model cost different amounts from different hosts? Because many hosts serve the same downloadable weights, which makes a market, and a market has a spread. On the 2026-10-14 OptimToken catalogue snapshot, the 14 open source and open weights models on the checked list have a median of 4 hosts and a median 1.45x gap between the cheapest and the dearest. The 45 proprietary models have a median of 2 hosts and a gap of 1.00x. ### Is every model on AWS Bedrock available in a European region? No. On the 2026-10-14 OptimToken catalogue snapshot, using the 2026-10-12 sweep of 18 Bedrock regions, 2 of the 16 models on the checked list have no European region: DeepSeek V3.2 and R1. Global inference profiles are not counted, because they route anywhere and answer no residency question.