Externalise model pricing into versioned config

[Colinho22]

Motivation

Prices are hardcoded in application code. Provider rates change, so every cost figure decays silently and without warning — and cost underpins the selection guidance the harness produces. There is also currently no way to tell which rates produced a historical cost figure.

Proposal

• Move pricing to a versioned config file with a date stamp and currency per entry.
• Record the pricing-config version in run metadata so historical cost figures stay interpretable.
• Fail loudly on an unknown model instead of defaulting to zero.
• Optional: a script that re-derives costs for past runs under updated rates.

Done when:

• No price literals remain in application code
• Run metadata records the pricing version used
• Unknown model raises rather than silently returning 0

Scope

• In scope: pricing config, version stamping in run metadata, unknown-model guard, optional re-derivation script.
• Out of scope: automatic price fetching from provider APIs; multi-currency conversion.

Open questions

• Do cached-input and batch-discount tiers need modelling, or is a flat input/output rate sufficient for the comparisons the harness makes?
• Should historical runs be re-costed under current rates by default, or should each run keep the cost that was true when it ran? Argues for storing token counts as the primary record and treating cost as derived.

Related

• Blocks Model-selection decision rule and cost–quality frontier #97 — frontier analysis depends on trustworthy cost data.