RPT-2026: Complete Reference Price Table

TIER Framework — Token Impact & Efficiency Ratio

Narrative companion to internal/store/prices.yaml — describing the table embedded in TIER v0.6.0, version: 14, effective_date: 2026-10-12, with 93 models.

Status: Published reference. The authoritative, machine-readable table is internal/store/prices.yaml, which tierd embeds at build time and which this document describes. Where the two disagree, the YAML is correct — it is the single source of truth, and this page carries no independent version number precisely so the two cannot drift apart.

🔴 Before you edit this table or a --prices override, read §9, version: Is Binding. A change to this table needs the next version: integer; a change to an override needs a version: this database has never recorded. Without that, one integer denotes two different price tables; §9 says exactly which changes count. A --prices override that does it is refused outright; an edit to this table is refused on every deployment that already served the previous version. There is no flag to accept it; the remedy is always to bump the version.

Purpose: Comprehensive, research-verified reference pricing for every major AI model used in software development, effective for all TIER score calculations during calendar year 2026.

Data sourced: Base rows captured March 26, 2026 from official provider pricing pages and verified third-party aggregators; subsequent revisions through version: 14 (2026-10-12) added and re-verified individual rows — version: 8 (#461) added the GPT-5.6 Codex family (gpt-5.6-sol $5/$30, gpt-5.6-terra $2.50/$15, gpt-5.6-luna $1/$6, OpenAI standard-tier list); version: 9 added claude-opus-5 at $5/$25, verified against the vendor catalog rather than inferred from the 4.x pattern; version: 10 (#786) added claude-fable-5-1, claude-mythos-5-1, claude-opus-5-5, the GPT-6 family and the Z.ai GLM-5.3 rows under a new zai provider, and corrected claude-sonnet-5 from $3/$15 to $2/$10; version: 11 (#895) added Meta's Muse Spark models (muse-spark-1.3, -1.2, -1.1 and the -contributor tier of 1.3 and 1.2) under a new meta provider, from Meta's own pricing page read 2026-09-27; version: 12 (#1047) added claude-sonnet-5-5 at $2/$10 with the standard Anthropic cache rates, from Anthropic's pricing page read 2026-10-02; version: 13 (#1202) added claude-haiku-5-5 at $0.10/$0.50 through 100K prompt tokens and $0.50/$2.50 above, plus gpt-6.1-sol at $2/$10 with $0.10 cached input, on 2026-10-12; version: 14 (#1206) changed only claude-sonnet-5-5 cache reads to $0.10/M (0.05×), reflecting Anthropic's price change between the 2026-10-02 and 2026-10-12 reads. Per the table's own versioning rule, effective_date stamps when the table was last revised as a whole — it is not a guarantee that every row was re-captured on that date.

1. Cloud API Models (Pay-Per-Token)

All prices are USD per million tokens ($/MTok) at standard list rates. Batch API discounts and enterprise negotiations are excluded per TIER specification (see cost normalization spec Section 2.1). Prompt caching multipliers are applied — see §7 below.

1.1 Frontier Tier

Models representing the highest capability level. Used for architecture review, complex reasoning, and high-stakes code generation.

RPT-2026 Frontier reference model: claude-opus-4 at $15.00/$75.00 (set at RPT publication; not updated mid-year per spec Section 2.4).

Important note on Opus pricing evolution: Claude Opus 4 and 4.1 launched at $15/$75. Opus 4.5, 4.6, 4.7, 4.8, and 5 all dropped to $5/$25 -- a 67% price reduction. Note the reduction did NOT carry backwards: 4.1 remains $15/$75, so "a newer Opus is cheaper" is not a rule and each generation must be captured, not inferred. For RPT-2026, we retain the original claude-opus-4 entry at $15/$75 as the frontier reference anchor (set January 2026). The Opus 4.5–4.8 and Opus 5 entries are mid-year addenda at their actual list prices. Note these minor versions do NOT share the base-family rate, so the code price table (internal/store/prices.yaml) lists each explicitly rather than inferring a family rate (#80). Claude Fable 5 is a distinct, more-capable family priced above Opus tier at $10/$50. Similarly, gpt-4.5 at $75/$150 has been retired by OpenAI and replaced by the GPT-5.x series at dramatically lower prices.

1.2 Standard Tier

Primary workhorse models for day-to-day coding, code review, and feature implementation.

1.3 Efficient Tier

Cost-optimized models for high-volume tasks, simple code completions, test generation, and routine operations.

1.4 Embedding Tier

1.5 Open-Source Models (via Hosted APIs)

These models are open-weight and can be self-hosted (see Section 2) or accessed via inference providers (Together AI, Fireworks, DeepInfra, Groq, etc.). Prices below reflect typical hosted API rates, NOT self-hosted costs.

2. Self-Hosted Inference Cost Model

2.1 Reference Tier Pricing (For TIER Score Calculation)

Per the TIER cost normalization specification, self-hosted models use fixed reference tiers, NOT actual amortized costs. This ensures cross-organization comparability.

2.2 Estimated Actual Self-Hosted Costs (For Reference Only)

These are NOT used in TIER calculations. They are provided for organizations evaluating build-vs-buy decisions.

Cost Methodology

Annual cost per GPU node =
    (hardware_cost / amortization_years)
    + (power_draw_kw * 8760h * PUE * electricity_rate)
    + (hardware_cost / amortization_years * staffing_overhead)

Cost per million tokens =
    annual_cost * 1_000_000 / (tokens_per_second * 3600 * 8760 * utilization)

At 50% utilization, annual output is tok/s * 3600 * 8760 * 0.5, or tok/s * 15,768,000 tokens. Using the assumptions below:

For example, Spark at 25-35 tok/s costs 2179.862667 * 1,000,000 / (35 * 15,768,000) to 2179.862667 * 1,000,000 / (25 * 15,768,000) = $3.95-5.53/M. All ranges below use the same arithmetic, fastest throughput first, rounded to cents. Power cost follows the stated full-year draw; utilization scales token output only. These are estimates from the stated assumptions, not benchmarks.

DGX Spark (128GB Unified Memory, ~$4,999 MSRP)

*70B at Q4 = self-hosted-standard per tier assignment rules (Section 3.3 of cost normalization spec).

Assumptions: $4,999 hardware, 3-year amortization, 300W power draw, $0.12/kWh, PUE 1.1 (small deployment), 50% utilization, 10% staffing overhead.

Single H100 80GB SXM (~$25,000-$35,000)

Assumptions: $30,000 hardware, 3-year amortization, 700W TDP, $0.10/kWh, PUE 1.3, 50% utilization, 10% staffing.

8x H100 DGX H100 Node (~$300,000)

Assumptions: $300,000 hardware, 3-year amortization, 10.2kW TDP, $0.10/kWh, PUE 1.3, 50% utilization, 10% staffing.

8x H200 DGX H200 Node (~$400,000-$500,000)

Assumptions: $450,000 hardware, 3-year amortization, 10.2kW TDP, $0.10/kWh, PUE 1.3, 50% utilization, 10% staffing.

Consumer/Workstation GPUs

No power, electricity, PUE, utilization or staffing assumptions are stated for these consumer/workstation rows, so their $/M costs cannot be recomputed. The Spark embedding row likewise lacks token throughput. No cost estimate is given for those rows.

3. Tiered Summary for RPT-2026

3.1 API Models by Effective Cost (Output-Weighted)

For coding workloads, output tokens dominate cost (typically 60-70% of spend). This ranking uses an approximate "effective cost" = 0.35 * input + 0.65 * output per MTok.

TIER 1 — Frontier ($10+/M effective)

TIER 2 — Standard ($1-10/M effective)

TIER 3 — Efficient (<$1/M effective)

4. Corrections to Existing RPT-2026 in Cost Normalization Spec

The following entries in the current docs/cost-normalization-spec.md Section 2.3 need updating based on verified March 2026 pricing:

Entries to Update

Entries to Add (Mid-Year Addenda)

5. Cross-Provider Defaults (Design — NOT Implemented)

⚠️ This tiered-default scheme is design intent, not shipped behavior. The code has no frontier-default / standard-default / efficient-default tier and does no provider/tier inference for unknown models. The shipped fallback (ComputeCost, using internal/store/prices.yaml) prices an unmatched model at a self-hosted reference rate: a size-class heuristic (self-hosted-large $2.00/M, self-hosted-medium $0.50/M, self-hosted-small $0.10/M) when the model string carries a parameter count, else the flat self-hosted-medium $0.50/M combined rate. Both paths emit a one-time WARN and bump the unknown-model event/cost counters (tier_unknown_model_events_total / tier_unknown_model_cost_micro_total, #267/#135). The rows below are retained as a target design; see docs/cost-normalization-spec.md (implementation-status banner) for the same clarification.

6. Key Market Observations (March 2026)

Price Compression Is Accelerating

1. Anthropic's Opus 4.5/4.6 dropped 67% from Opus 4 ($15/$75 to $5/$25), making frontier models dramatically more accessible.
2. OpenAI's GPT-5.x series replaced GPT-4.5 ($75/$150) with models ranging from $0.05/$0.40 (nano) to $2.50/$15.00 (standard), a 10-50x cost reduction.
3. DeepSeek V3.2 reduced output pricing from $1.10/M to $0.42/M -- a 62% drop.
4. Google's Gemini 2.5 Flash-Lite at $0.10/$0.40 and Amazon Nova Lite at $0.06/$0.24 are approaching commodity pricing.
5. xAI's Grok Fast variants at $0.20/$0.50 represent aggressive undercutting by a new entrant.

Implications for TIER

• The frontier-default fallback of $15/$75 (based on Opus 4) is now overly conservative. Most "frontier" models are $3-5 input, $15-25 output.
• The efficient tier is being compressed toward near-zero. Models like GPT-OSS-120B at $0.039/$0.10 offer 120B-parameter performance at embedding-tier prices.
• Self-hosted reference tiers ($2.00/$0.50/$0.10) are fixed normalization rates, not actual infrastructure costs. Every computable estimate in §2.2 exceeds its tier's rate; the smallest gap is 7.9x ($3.95/M vs $0.50/M for Qwen 2.5 Coder 32B on DGX Spark). These estimates are not used in TIER calculations.
• The RPT-2027 TPI will likely show significant deflation (TPI < 0.60) given current trends.

Coding-Specific Model Recommendations

For organizations choosing models specifically for coding tasks in the TIER framework:

7. Prompt Cache Multipliers

Cache multipliers are per-model, stored in prices.yaml (cache_read_mult / cache_write_5m_mult / cache_write_1h_mult) and baked into the effective rate at parse time (#122). Each model omits them to inherit its provider default (below) or sets an explicit value to override that class. They are multipliers of the model's selected input rate, so under a long-context over-tier a cached read scales off the premium base too. ComputeCost reads the baked value directly — there is no per-provider branch anymore.

Provider defaults (used when a model sets no explicit multiplier):

Per-model overrides in the current table:

Gemini's cachedContentTokenCount is a subset of promptTokenCount (carved out of Input, same shape as OpenAI's cached_tokens); thoughtsTokenCount is reasoning usage billed at the output rate and folded into Output (#122). The GPT-5.x entries are in the v0.6.0 table (prices.yaml, added in v5 per #135 and present through the current v14) and each carries an explicit cache_read_mult: 0.10 — the 5-era discount differs from the 4-era 0.5× default (which the gpt-4.x / o-series rows inherit).

Sources:

• Anthropic: https://platform.claude.com/docs/en/about-claude/pricing#prompt-caching (5m=1.25×, 1h=2.0×, hit=0.1×).
• OpenAI: cache-hit input is 50% off standard rate on caching-enabled models.
• Google Gemini: implicit caching on 2.5+ models discounts cached input tokens 75% (0.25×).
• DeepSeek: published cache-hit rate $0.028/M (https://api-docs.deepseek.com/quick_start/pricing).
• Z.ai: no per-token cache-write rate is published. The "limited-time free" line on its pricing page is cache storage, not writes, so zai writes default to 1.0× input, the conservative choice. No real Opencode row has reported a cache write yet (0 of ~9,267 measured), so this has no numeric effect today.
• Meta: no cache-write rate is published. Meta's prompt-caching page (https://dev.meta.ai/docs/prompt-caching) says "cached_tokens is a subset of your input tokens … billed at a reduced rate compared to uncached input" and describes no write step, so meta writes default to 1.0× input. Meta's token-counting page (https://dev.meta.ai/docs/token-counting) says reasoning_tokens is "a subset of the output total", so reasoning is already billed inside output and needs no rate of its own.

Legacy entries (rows / JSONL responses pre-dating the nested cache_creation object) bucket all cache writes into the 5m TTL — this matches Anthropic's pre-1h-feature default and is the safest historical assumption per the TIER cost-correctness decision matrix (issue #55).

The 1h TTL premium pays off as a steady-state caching strategy when the cache is read more than twice within the hour (2 × 0.1× < 1.0× fresh-read break-even); the 5m TTL pays off after a single read. Pricing decisions about cache TTL belong upstream (in the application calling Claude) — TIER reports what was actually charged.

8. Data Sources

Base rows verified March 26, 2026, with later revisions through version: 14 (2026-10-12), from the following authoritative sources:

• Anthropic Official Pricing
• OpenAI Official Pricing and Developer Docs
• Google Gemini API Pricing
• xAI Grok API
• DeepSeek API Pricing
• Mistral AI Pricing
• Cohere Pricing
• Amazon Nova Pricing
• OpenAI Codex Pricing
• PricePerToken.com (third-party aggregator, cross-verified)
• OpenRouter (provider marketplace pricing)
• Z.ai model pages (GLM-5.3 / GLM-5.3 Flash, v10)
• OpenAI GPT-6.1 Sol announcement (v13; standard API prices)
• Anthropic prompt caching (v13 Haiku 5.5 inherits the 0.1× read and 1.25×/2.0× write defaults; rates also listed on the official pricing page)
• Meta Muse Spark pricing (Muse Spark 1.1–1.3 and Contributor tier, v11; the page is undated, read 2026-09-27)

9. version: Is Binding — One Number, One Table (#714)

🔴 This section describes a deliberate behaviour change. An override that was accepted before #714 can now fail at startup. Read it before editing any price table, embedded or override.

The rule

Every priced row in TIER carries a price_version column: the version: integer of the price table that produced its cost. That stamp is written once, at insert, and is never rewritten on the normal path — it is the only record of which rates a historical cost was computed with.

But version: is only a number. It resolves to actual rates through a file — internal/store/prices.yaml, or whatever --prices points at, which may not be version-controlled at all. So if you change the table and do not bump version:, one integer now denotes two different price tables, and the rows stamped under each are indistinguishable forever. No later query, backup, or audit can separate them.

⇒ Changing the table and bumping version: are the same action. Do both or neither. "The table" is the resolved table, which table_hash covers: for each row, its model key, input and output rates, over-threshold rates, context_threshold, combined, provider, effective cache multipliers and effective billing_mode. So adding or removing a row, or flipping a billing_mode or provider, needs a new version exactly as a rate edit does. effective_date, comments and row order are not part of it and do not need one.

A restart keeps its number whenever the resolved table is unchanged. The same file and the same tierd build guarantee that; a comment edit or a new path does not change it. A row that leaves a cache multiplier out inherits its provider's default, which lives in tierd's code, not in the file, and the hash covers the resolved value. An upgrade that changes one of those defaults therefore changes the hash of an unchanged file: if a refusal names your table after an upgrade, bump its version.

What enforces it

TIER records the content identity of every price table it serves from a database, in a price_table_registry row: the version, the table_hash and file_hash from the identity stamp, the effective date, the model count, where the table was loaded from, which binary first served it, and first_seen. (A store-less command such as tierd score-log prices and stamps without recording anything.) Two guards then refuse a second, different table claiming a version already in use:

Only table_hash — the identity of the resolved table — is compared. A comment-only edit moves file_hash and is not a collision; the same table loaded from a second path is not a collision either. A hash recorded under an older canonicalization scheme (the tierpt1: tag) is treated as not comparable rather than as a collision, so a future fix to the serialization cannot brick every deployment at once.

⚠️ One case is caught by neither, deliberately. Two different override files sharing a non-embedded version, used only through a store-less command (tierd score-log --prices A, then --prices B, both version: 1000), is invisible to the load-time guard (which compares only against the embedded table) and unreachable by the open-time one (there is no database). Closing it would require per-user state outside any database — a worse problem than the one it solves.

⛔ There is no flag that accepts a collision, and there will not be one. A --accept-rehash would silently rebind the meaning of every historical price_version stamp, with a green startup log — the exact corruption these guards exist to prevent. The remedy is always: bump the version.

What the refusal looks like

There are two refusals, and they read differently.

The open-time one names the database, both hashes, where the recorded one came from, and the ways out:

database "/var/lib/tier/tier.db": price table version 9 in this binary hashes
table_hash "tierpt1:086f4116…" but this database already recorded version 9 as
table_hash "tierpt1:7acfb82b…" (recorded "2026-08-29T00:01:23Z" from source
"/etc/tier/prices.yaml" by "tierd v0.4.1 go1.26.6 linux/amd64") — two different
price tables share one version number, and every row stamped price_version=9
under each is indistinguishable forever. Bump 'version:' in the price table (this
is the fix in almost every case), point --db at a different file, or — only if the
RECORDED row is the wrong one — run 'tierd prices forget-version --db
"/var/lib/tier/tier.db" --version 9 --commit' to drop it. There is deliberately no
flag that accepts the collision

The load-time one needs no database, names the override path, and does not offer forget-version — there is no recorded row to forget:

price table "/etc/tier/prices.yaml" declares version 9, which is this binary's
EMBEDDED price table version, but its table_hash "tierpt1:086f4116…" does not
match the embedded table_hash "tierpt1:7acfb82b…" — two different price tables
would share one version number, and every row stamped price_version=9 under each
is indistinguishable forever. Bump 'version:' in "/etc/tier/prices.yaml" to a
number the embedded table does not use (overrides conventionally start at 1000).
There is deliberately no flag that accepts the collision

⚠️ If BOTH tables are the embedded default, the open-time message says so and tells you not to run forget-version: you cannot bump a version compiled into the binary you were shipped, so that is a tierd release bug to report, not an operator misconfiguration to work around.

🔴 The failure mode is a total service outage, not degraded pricing. A refused store.Open takes down the daemon — dashboard, API and ingestion — because the guard runs before anything is served. That is the deliberate choice (integrity over availability), but size your change control for a price edit accordingly.

If you write a --prices override

Use a version: of 1000 or more that this database has never recorded. Overrides start at 1000 so they stay clear of the embedded table's current version:, which counts upward. When to bump is the rule. Copying the embedded table, changing it, and leaving the embedded table's current version: in place is refused when the table loads.

An override that gives a built-in per-token model a different billing_mode (its own row, or a <model>@<host> row that outranks it) is loaded as written, and serve (and every other command that loads --prices) logs one startup WARN per such model and host, naming the model, the host and both modes.

Inspecting what is recorded

tierd prices list  --db /var/lib/tier/tier.db          # every recorded identity
tierd prices audit --db /var/lib/tier/tier.db          # every retirement

Both are read-only, both accept --json, and both work on a database tierd serve is currently refusing to open — which is the point. Run them before an upgrade to see which versions a deployment has already bound.

The escape hatch

Sometimes the recorded row is the wrong one — it was seeded by a staging or test table, or by a bad edit that has since been reverted. For that, and only that:

# DRY RUN — prints the recorded row, changes nothing
tierd prices forget-version --db /var/lib/tier/tier.db --version 9

# archive it first if you want the record in machine-readable form
tierd prices forget-version --db /var/lib/tier/tier.db --version 9 --json > v9.json

# then retire it
tierd prices forget-version --db /var/lib/tier/tier.db --version 9 --commit

🔴 It retires the identity; it does not delete it. The row is kept and stamped with forgotten_at and forgotten_by, and a price_forget_audit ledger entry records the act — the same ledger family tierd reprice and tierd repair-repo already write into. Afterwards the database can still answer:

version 9 once meant table_hash tierpt1:7acfb82b…, and that record was retired at 2026-08-29T01:21:42Z by sre-oncall.

That is the whole reason it works this way. This program exists so provenance is not lost; an escape hatch that erased the record of its own use would contradict the thing it protects. A retired identity stops binding the guard, so the next start records the replacement — it does not stop being evidence. (Uniqueness on version is a partial index, WHERE forgotten_at IS NULL, so retiring keeps the evidence without blocking re-registration. Both properties depend on that one predicate.)

The row is always printed before anything is written, and if that output cannot be written — a closed stdout, a full disk, a truncated pipe — the retirement is aborted. You cannot lose the record silently.

forgotten_by defaults to the OS username and can be set with --actor. ⚠️ It is self-asserted: a local CLI has no authenticated principal to bind it to, so read it as a claim, corroborated by the tool_version the ledger records alongside it. Same honesty as the actor field on cost_correction_audit.

⚠️ It is still not a bypass. It does not let two real tables share one version — the remedy for that is always to bump the version. What it does is make using the hatch leave a mark instead of a hole. Do not automate it in a unit file or an entrypoint: running it on every boot converts fail-closed into fail-open.

What it does not claim

table_hash is an unkeyed digest computed by the same process that reports it. Against an adversary who controls the install it proves nothing — such an adversary changes the table and reports whatever hash they like. It detects accidental drift: an operator who edited the YAML on a box whose binary is trusted, or two installs that believe they are running the same rates and are not. See docs/api-compatibility.md for the full statement of what the two hashes do and do not establish.

🔴 A recorded row is authoritative only for rows written at or after its first_seen. It does not establish anything about rows that already carried that version number beforehand. This matters most on the first upgrade of an existing database: the same startup that records the active version's identity also runs the one-shot backfill that stamps pre-#233 rows with that version, so those rows inherit a version integer that now has a recorded hash while having been priced by whatever table was in effect at the time. tierd prices list prints first_seen and says so.

⚠️ Nothing consumes the registry as a verifier today. Its readers are the guard itself and the three tierd prices operator commands (list, audit, forget-version). The registry records identity and refuses collisions — it does not certify that any particular stored row was priced by the table its version names.

A price_version with no registry row is not an error and is not "invalid". It means no identity-recording binary ever served that table here — most commonly rows that pre-date this feature, or a figure produced by a store-less command like tierd score-log, which prices and stamps without touching a database. TIER deliberately does not mint a hash for a table nobody possesses.