Public Evidence Bundle Fixtures for OpenAI-Compatible SDK Releases (September 2026)

[chawkian]

An OpenAI-compatible SDK can make a gateway easy to call, but it should also make the gateway easy to evaluate. Before a team promotes a route into a production queue, the SDK can collect a small public evidence bundle: pricing source, model catalog source, status source, and the receipt fields that will be available after a request.

I checked the live sources for this discussion on September 8, 2026. The AIWave /api/pricing endpoint returned success=true, 63 route records, pricing version a42d372ccf0b5dd13ecf71203521f9d2, auto_groups=["default"], and group ratios of default=3 and vip=1. The public dated JSON at /api/v1/pricing returned currency USD, unit per_1m_text_tokens, checked date 2026-08-27, the same pricing version, and 63 model rows. Selected dated rows from that public file were:

Model	Provider	Input USD / 1M	Cache-hit USD / 1M	Output USD / 1M	Effective date
deepseek-v4-flash	DeepSeek	0.638	0.0202884	1.914	2026-08-27
deepseek-v4-pro	DeepSeek	1.914	0.0637362	5.742	2026-08-27
glm-5.1	GLM	2.1	0.680001	6.5999997	2026-08-27
kimi-k3	Kimi	4.5	0.9	22.5	2026-08-27
qwen3-max	Qwen	1.5621977891181764	absent	6.248791156472706	2026-08-27
qwen3.6-flash	Qwen	0.26780533527740163	absent	1.6068320116644097	2026-08-27

I also checked provider documentation during the same run. DeepSeek's API docs returned HTTP 200 and confirmed the callable deepseek-v4-flash and deepseek-v4-pro aliases. Alibaba Cloud Model Studio docs returned HTTP 200 for its current model documentation surface. Those checks are route-context evidence, not a replacement for the gateway's own dated billing source.

That distinction is where an SDK fixture helps. The SDK should not claim to be the billing authority. It can, however, preserve the public facts that the developer saw when the release was accepted.

One fixture shape could be:

{
  "fixture": "public_evidence_bundle_2026_09_08",
  "gateway": "aiwave",
  "pricing": {
    "url": "https://aiwave.live/api/v1/pricing",
    "checked": "2026-08-27",
    "verified_at": "2026-09-08T14:00:00Z",
    "pricing_version": "a42d372ccf0b5dd13ecf71203521f9d2",
    "currency": "USD",
    "unit": "per_1m_text_tokens"
  },
  "catalog": {
    "url": "https://aiwave.live/models",
    "id_policy": "pin exact model IDs in release fixtures"
  },
  "status": {
    "url": "https://aiwave.live/status",
    "scope": "current public probe"
  },
  "required_receipt_fields": [
    "request_id",
    "resolved_model",
    "effective_group",
    "pricing_version",
    "input_tokens",
    "cached_input_tokens",
    "output_tokens",
    "status_class"
  ]
}

The release test should run before a new SDK version changes defaults, model aliases, retry behavior, streaming parsing, or receipt serialization. It should fetch the public pricing JSON, store the pricing version and selected model rows, check that the intended model IDs still exist in the catalog, check that the status page describes its scope, and verify that synthetic examples still show the receipt fields the SDK expects to parse.

The fixture should fail closed when the selected model disappears, the pricing version is missing, the unit is ambiguous, the route has no enabled group for the intended account class, or the SDK can no longer surface token buckets separately. It should warn, not fail, when a provider documentation page changed but the gateway's dated pricing source has not changed yet. That may be a review queue item rather than a runtime break.

In Python, the helper can stay small:

bundle = client.aiwave.evidence_bundle.verify(
    pricing_url="https://aiwave.live/api/v1/pricing",
    catalog_url="https://aiwave.live/models",
    status_url="https://aiwave.live/status",
    models=["deepseek-v4-pro", "qwen3-max"],
)

bundle.assert_pricing_version("a42d372ccf0b5dd13ecf71203521f9d2")
bundle.assert_receipt_fields([
    "resolved_model",
    "effective_group",
    "pricing_version",
    "input_tokens",
    "cached_input_tokens",
    "output_tokens",
])

The helper should never store reusable credentials, prompts, completions, account emails, payment identifiers, or customer names. It should store only source URLs, checked dates, pricing versions, model IDs, selected public rows, and synthetic receipt expectations.

This gives SDK adopters a practical release gate. A green chat completion proves one request worked. A public evidence bundle fixture proves the SDK can still explain which public facts were accepted before that request path was promoted.

Open question: should aiwave-sdk-python expose this as a first-class evidence_bundle.verify() helper, or keep it as an example fixture until more teams standardize their receipt fields?