Redacted Incident Replay Fixtures for OpenAI-Compatible SDKs (September 2026)

[chawkian]

Most SDK incident examples are still written as if the only useful artifact is a stack trace. That is enough to debug a local typo. It is not enough for an OpenAI-compatible gateway where one request can involve a public model alias, a resolved upstream route, cache behavior, account group policy, rate limits, retries, and a private usage receipt.

I think SDKs should include a redacted incident replay fixture as a first-class test artifact.

The goal is not to replay private message content. The goal is to preserve the minimum evidence needed to reproduce the decision path: what the client tried, which public pricing snapshot was in force, which failure class was returned, which retry branch was selected, and which private fields were deliberately excluded.

Before posting this on September 12, 2026, I rechecked AIWave's public pricing surfaces. https://aiwave.live/api/pricing returned success=true, 64 route records, and pricing version a42d372ccf0b5dd13ecf71203521f9d2. The dated snapshot at https://aiwave.live/api/v1/pricing returned HTTP 200 with checked=2026-09-10, updated_at=2026-09-10, currency USD, unit per_1m_text_tokens, pricing version 8c7a0c0b30661ccbc13d142cb54d1e4ae445fe774b2c6fa501080db97c7a3e56, and 64 model rows.

Selected public rows from that snapshot:

Model ID	Input / 1M	Cache-hit input / 1M	Output / 1M	Effective date
deepseek-flash	$0.70	$0.0233	$2.10	2026-09-10
deepseek-v4-flash	$0.638	$0.0202884	$1.914	2026-08-27
deepseek-v4-pro	$1.914	$0.0637362	$5.742	2026-08-27
glm-5.1	$2.10	$0.680001	$6.5999997	2026-08-27
kimi-k3	$4.50	$0.90	$22.50	2026-08-27

Those are public base rows, not completed invoices. A real charge still depends on the resolved route, applied account group, observed input and output tokens, cache state, and retry count. That distinction is exactly why a replay fixture should join public evidence to private receipts by reference, not by copying the receipt into a public issue or SDK test.

Here is the fixture shape I would want examples to emit:

{
  "fixture_type": "redacted_incident_replay",
  "base_url": "https://aiwave.live/v1",
  "client_family": "python",
  "model_requested": "deepseek-v4-pro",
  "status_class": "quota",
  "retryable": false,
  "pricing_snapshot": {
    "source": "https://aiwave.live/api/v1/pricing",
    "checked": "2026-09-10",
    "version": "8c7a0c0b30661ccbc13d142cb54d1e4ae445fe774b2c6fa501080db97c7a3e56",
    "currency": "USD",
    "unit": "per_1m_text_tokens"
  },
  "private_refs": {
    "receipt_ref": "internal-only",
    "request_ref": "internal-only"
  },
  "redaction": {
    "api_key": "excluded",
    "prompt": "excluded",
    "completion": "excluded",
    "account_identifier": "excluded",
    "raw_upstream_body": "excluded"
  }
}

The SDK tests can stay small. A quota-class fixture should assert retryable=false. A timeout-class fixture can allow retry only inside an attempt budget. A model-alias fixture should assert that the requested model and resolved route are different fields. A pricing-sensitive fixture should fail if the source URL, checked date, unit, currency, or version is missing.

This also helps support teams. Instead of asking a developer to paste a raw request body into a ticket, support can ask for the replay fixture plus a private receipt reference. The public fixture explains the decision branch. The private receipt stays inside the account boundary where it belongs.

Discussion question: should incident replay fixtures be generated by SDK middleware, by the gateway response layer, or by a separate diagnostic command? My bias is middleware for the common path and a diagnostic command for deeper incidents, because developers need a shareable artifact before they know which internal team owns the problem.