Cost Manifest Fixtures for OpenAI-Compatible SDK Releases (September 2026)

[chawkian]

Pricing note checked during the September 18, 2026 run: the live AIWave pricing endpoint returned success=true, 68 route rows, pricing version a42d372ccf0b5dd13ecf71203521f9d2, group_ratio.default=1, and group_ratio.vip=0.9. The dated public snapshot returned checked=2026-09-10, updated_at=2026-09-18, currency=USD, unit=per_1m_text_tokens, pricing version 83f77abde81ee3a096a672ed959ccc096f5d37a45c177ae8e03229456b5415a5, and 56 public model rows. Recheck the endpoints before using these rows for billing decisions.

Most SDK examples teach the request shape. Fewer examples teach the review shape.

That gap becomes visible when an OpenAI-compatible client moves from a notebook into a release. The code may only change one string, such as model="deepseek-v4-flash", but the release review needs more than the string. It needs to know which dated rate card was checked, whether the route table was live or copied, which billing group multiplier was assumed, and which receipt fields must be present after the example runs.

I would like SDK repositories to include cost manifest fixtures beside cost-sensitive examples.

A cost manifest fixture is not a pricing database. It is a small review artifact checked into source control with the example it supports. It should not contain API keys, prompts, completions, user identifiers, account balances, or private invoices. It should contain the evidence that a maintainer needs when the example is updated six weeks later.

Here is the shape I mean:

{
  "fixture_type": "cost_manifest",
  "sdk_family": "python",
  "client_shape": "openai_chat_completions",
  "base_url": "https://aiwave.live/v1",
  "model_id": "deepseek-v4-flash",
  "pricing_snapshot": {
    "url": "https://aiwave.live/api/v1/pricing",
    "checked": "2026-09-10",
    "updated_at": "2026-09-18",
    "pricing_version": "83f77abde81ee3a096a672ed959ccc096f5d37a45c177ae8e03229456b5415a5"
  },
  "route_table": {
    "url": "https://aiwave.live/api/pricing",
    "pricing_version": "a42d372ccf0b5dd13ecf71203521f9d2",
    "group_ratio": { "default": 1, "vip": 0.9 }
  },
  "rate_basis": {
    "currency": "USD",
    "unit": "per_1m_text_tokens",
    "input": 0.638,
    "output": 1.914,
    "effective_date": "2026-08-27"
  },
  "receipt_contract": [
    "request_id",
    "model_id",
    "prompt_tokens",
    "completion_tokens",
    "charged_amount"
  ],
  "redactions": ["api_key", "prompt", "completion", "user_id"],
  "unknowns": [
    "final cost depends on selected account or key group",
    "runtime receipt must confirm charged amount"
  ]
}

The useful part is not the JSON syntax. The useful part is that every field has a job.

The pricing_snapshot block tells reviewers which public base-rate surface was checked. The route_table block tells them which live routing version and group multipliers were visible at the time. The rate_basis block keeps the exact row near the example. The receipt_contract block says what the example expects to see after a run. The unknowns block prevents the fixture from pretending to know final account-specific billing.

Selected public base rows from the dated snapshot I checked:

Model ID	Input / 1M	Output / 1M	Effective date
deepseek-flash	$0.70	$2.10	2026-09-10
deepseek-v3.2	$0.154	$0.308	2026-08-27
deepseek-v4-flash	$0.638	$1.914	2026-08-27
glm-5.1	$2.10	$6.5999997	2026-08-27
kimi-k3	$4.50	$22.50	2026-08-27
MiniMax-M2.7	$0.45304	$1.81216	2026-08-27

I would test these fixtures with ordinary CI. Load each manifest, fetch the public pricing snapshot, compare the recorded pricing_version, find the model row, and fail loudly if the row disappears or the version changes. A missing row should produce a different failure from a numeric drift, because the maintainer response is different. One might require pausing the example. The other might only require refreshing the manifest.

The fixture should also reject unsafe fields. If a manifest contains sk-, a prompt transcript, a completion body, or a user identifier, it should fail before publication. The goal is reviewable release evidence, not a shadow log.

This turns a cost-sensitive SDK example into something maintainers can discuss line by line. The example still stays simple for developers who just want to run a request. The repository gains a second layer for people reviewing route economics, redaction behavior, and dated pricing assumptions.

Discussion question: should SDK cost manifest fixtures be committed as static JSON beside examples, or generated during release so they always reflect the latest public pricing surface?