You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Model Resolution Snapshots for OpenAI-Compatible SDK Examples (September 2026)
#88
Pricing note (updated September 13, 2026): group multipliers are runtime configuration. The current AIWave feed reports default x1 and VIP x0.9; check the live endpoint before using any billing math.
OpenAI-compatible SDK examples often stop at "set base_url, send a chat completion, print the answer." That is enough for a hello world. It is not enough for an application that lets developers request a public model name while the gateway resolves that request through an actual provider route, price row, group policy, cache state, and retry envelope.
I would like more SDK examples to ship with a small model resolution snapshot.
The snapshot is not a receipt and it should not include private account data. It is a shareable record of what the client believed at the time of the call: requested model, resolved model if exposed by the gateway, pricing source, source date, group label, unit, cache fields, and the SDK version that interpreted the response. When a user reports "this example cost more than I expected" or "this fallback used the wrong model," the maintainer can compare the snapshot against the current pricing feed and the private receipt without asking for prompts, completions, API keys, or account identifiers.
The practical benefit is support speed. Without this artifact, every incident starts with a vague transcript: model string, approximate time, maybe a screenshot, and often no source date for the price assumption. With the snapshot, the first response can be specific: the example used this pricing version, this group multiplier, this public row, and this SDK version. If the private receipt disagrees, that is a real investigation. If the public snapshot is stale, the example needs an update, not a billing escalation.
Before posting this on September 13, 2026, I rechecked AIWave's public pricing surfaces. https://aiwave.live/api/pricing returned success=true, 64 rows, pricing version a42d372ccf0b5dd13ecf71203521f9d2, group_ratio.default=1, and group_ratio.vip=0.9. The dated snapshot at https://aiwave.live/api/v1/pricing returned 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 dated 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
Here is the kind of snapshot I would put beside a Python example:
This pattern gives maintainers a clean boundary. Public examples can explain how a model choice was interpreted. Private support can still validate the actual request receipt. Finance can see whether an estimate used the right unit and date. Product teams can notice when example code is pinned to a stale source.
I would also keep the snapshot append-only inside test fixtures. Do not rewrite yesterday's example to pretend it used today's price row. Add a new snapshot, mark the old one as historical, and let readers see that model economics move over time. That is much easier to trust than an evergreen code sample with invisible assumptions.
The SDK test does not need to be heavy. Assert that the snapshot has a source URL, checked date, pricing version, currency, unit, group, requested model, and redaction list. If any of those fields are missing, the example is not ready to teach cost-sensitive production usage.
Discussion question: should model resolution snapshots be emitted automatically by SDK middleware in debug mode, or should examples generate them explicitly so developers see every field they are preserving?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
OpenAI-compatible SDK examples often stop at "set
base_url, send a chat completion, print the answer." That is enough for a hello world. It is not enough for an application that lets developers request a public model name while the gateway resolves that request through an actual provider route, price row, group policy, cache state, and retry envelope.I would like more SDK examples to ship with a small model resolution snapshot.
The snapshot is not a receipt and it should not include private account data. It is a shareable record of what the client believed at the time of the call: requested model, resolved model if exposed by the gateway, pricing source, source date, group label, unit, cache fields, and the SDK version that interpreted the response. When a user reports "this example cost more than I expected" or "this fallback used the wrong model," the maintainer can compare the snapshot against the current pricing feed and the private receipt without asking for prompts, completions, API keys, or account identifiers.
The practical benefit is support speed. Without this artifact, every incident starts with a vague transcript: model string, approximate time, maybe a screenshot, and often no source date for the price assumption. With the snapshot, the first response can be specific: the example used this pricing version, this group multiplier, this public row, and this SDK version. If the private receipt disagrees, that is a real investigation. If the public snapshot is stale, the example needs an update, not a billing escalation.
Before posting this on September 13, 2026, I rechecked AIWave's public pricing surfaces.
https://aiwave.live/api/pricingreturnedsuccess=true, 64 rows, pricing versiona42d372ccf0b5dd13ecf71203521f9d2,group_ratio.default=1, andgroup_ratio.vip=0.9. The dated snapshot athttps://aiwave.live/api/v1/pricingreturnedchecked=2026-09-10,updated_at=2026-09-10, currencyUSD, unitper_1m_text_tokens, pricing version8c7a0c0b30661ccbc13d142cb54d1e4ae445fe774b2c6fa501080db97c7a3e56, and 64 model rows.Selected public rows from that dated snapshot:
deepseek-flash$0.70$0.0233$2.10deepseek-v4-flash$0.638$0.0202884$1.914deepseek-v4-pro$1.914$0.0637362$5.742glm-5.1$2.10$0.680001$6.5999997kimi-k3$4.50$0.90$22.50Here is the kind of snapshot I would put beside a Python example:
{ "snapshot_type": "model_resolution", "sdk_family": "python", "base_url": "https://aiwave.live/v1", "requested_model": "deepseek-v4-pro", "pricing_source": "https://aiwave.live/api/v1/pricing", "pricing_checked": "2026-09-10", "pricing_version": "8c7a0c0b30661ccbc13d142cb54d1e4ae445fe774b2c6fa501080db97c7a3e56", "currency": "USD", "unit": "per_1m_text_tokens", "group": "default", "group_multiplier": 1, "redacted_fields": ["api_key", "prompt", "completion", "account_identifier"] }This pattern gives maintainers a clean boundary. Public examples can explain how a model choice was interpreted. Private support can still validate the actual request receipt. Finance can see whether an estimate used the right unit and date. Product teams can notice when example code is pinned to a stale source.
I would also keep the snapshot append-only inside test fixtures. Do not rewrite yesterday's example to pretend it used today's price row. Add a new snapshot, mark the old one as historical, and let readers see that model economics move over time. That is much easier to trust than an evergreen code sample with invisible assumptions.
The SDK test does not need to be heavy. Assert that the snapshot has a source URL, checked date, pricing version, currency, unit, group, requested model, and redaction list. If any of those fields are missing, the example is not ready to teach cost-sensitive production usage.
Discussion question: should model resolution snapshots be emitted automatically by SDK middleware in debug mode, or should examples generate them explicitly so developers see every field they are preserving?
All reactions