Versioned Pricing Snapshots for Peak/Off-Peak AI SDK Routing (August 2026)

[chawkian]

One operational habit I would like to see more SDKs adopt is a versioned pricing snapshot before any route table changes. Not a marketing price table in the README, and not a monthly billing export. I mean a small, dated data object that the SDK or gateway can reference when it decides whether a request should run now, wait for an off-peak window, or move to a different model.

The reason this is timely is DeepSeek's August 16, 2026 pricing change. I rechecked the official DeepSeek pricing page today. The page still lists the current model details for deepseek-v4-flash and deepseek-v4-pro, including 1M context, OpenAI-format and Anthropic-format base URLs, tool calls, JSON output, Responses API support, and concurrency limits of 2500 for Flash and 500 for Pro. It also says peak/off-peak billing takes effect at 16:00 UTC on August 16, 2026, with peak hours at 01:00-04:00 and 06:00-10:00 UTC.

Those direct DeepSeek rows are now materially different from a simple flat table:

Model	Window	Cache-hit input / 1M	Cache-miss input / 1M	Output / 1M
deepseek-v4-flash	off-peak	$0.007	$0.22	$0.66
deepseek-v4-flash	peak	$0.014	$0.44	$1.32
deepseek-v4-pro	off-peak	$0.022	$0.66	$1.98
deepseek-v4-pro	peak	$0.044	$1.32	$3.96

I also rechecked AIWave's live pricing feed at https://aiwave.live/api/pricing on August 16. Its current OpenAI-compatible rows exposed flat rates such as deepseek-v4-flash at $0.103 input, $0.0206 cached input, and $0.206 output per 1M tokens; deepseek-v4-pro at $0.54375 input, $0.271875 cached input, and $1.0875 output; qwen3-coder-480b-a35b-instruct at $0.0600 input and $0.1800 output; kimi-k2.6 at $0.5450 input and $2.2999 output; glm-5.1 at $1.0500 input and about $3.3000 output; and ernie-5.0 at about $1.232877 input and $4.65756 output.

That difference is exactly why SDKs should not treat pricing as a loose comment beside route code. A gateway may expose a flat account-specific row while an upstream provider introduces a time-windowed direct row. Both can be true in their own context. The application needs to know which source powered the estimate, when it was checked, and which route policy was approved against it.

A small shape like this is enough:

{
  "pricing_snapshot": "2026-08-16-deepseek-peak-offpeak",
  "source_url": "https://api-docs.deepseek.com/quick_start/pricing/",
  "gateway_price_url": "https://aiwave.live/api/pricing",
  "checked_at": "2026-08-16",
  "model": "deepseek-v4-pro",
  "window_policy": "peak_0100_0400_0600_1000_utc",
  "cache_policy": "measure_provider_cache_tokens",
  "route_policy": "use_pro_for_architecture_security_incident_rca"
}

The useful part is not the exact field names. The useful part is that route behavior and price evidence become reviewable together. If a coding agent moves from Flash to Pro, the pull request should show the route reason and the pricing snapshot. If an async evaluation waits until off-peak, the scheduler should log that decision. If a customer-facing request runs during peak hours, the ledger should show that the product chose immediacy over deferral.

I would keep this separate from final billing reconciliation. Reconciliation needs account invoices, taxes, credits, retries, failed calls, and provider usage exports. A pricing snapshot has a narrower job: prevent SDK route changes from being shipped against stale or ambiguous price assumptions.

The open design question for SDK maintainers is where this belongs. Should a pricing snapshot ID appear in response metadata, structured logs, OpenTelemetry spans, or a callback before dispatch? My current preference is a small opt-in metadata object plus a mandatory internal log field. That keeps normal OpenAI-compatible clients clean while still giving platform, SRE, and finance teams the evidence they need.

How are you representing time-windowed pricing in your own SDKs or gateways? Do you version route policy and pricing snapshots together, or do you keep them as separate systems?