This guide uses source checks from Sep 20, 2026. Provider and gateway prices can change; preserve the checked date with every forecast.
Why This Topic Matters Now
Brand and documentation queries remain the strongest useful signal in the Sep 19 report: aiwave.live, aiwaveblog, and aiwave api all carried more Tier 1 relevance than broad model terms. The first-call guide should therefore answer the question a developer has immediately after finding the site: which model ID, which endpoint, which price surface, and how do I test without creating a security or billing surprise?
This is a client contract checklist, not a promise that one model fits every job. The live AIWave endpoint is the source for current route and group context. The public pricing JSON is a dated USD snapshot. Read both, label the dates, and let the application record the exact route and usage fields returned by the call.
Source Facts Checked Today
AIWave /api/pricing was checked from production on Sep 20, 2026 and returned HTTP 200, success=true, 68 live route rows, pricing_version a42d372ccf0b5dd13ecf71203521f9d2, auto_groups=['default'], and group_ratio default=1 and vip=0.9. The public /api/v1/pricing endpoint also returned HTTP 200 with 56 dated USD rows, pricing_version 83f77abde81ee3a096a672ed959ccc096f5d37a45c177ae8e03229456b5415a5, updated_at=2026-09-18, and row checked dates of 2026-09-10. Use the live endpoint for route and group evidence, and the static endpoint for dated public USD rates.
The public JSON currently lists deepseek-v4-flash at $0.638 input, $0.0202884 cache-hit input, and $1.914 output per 1M tokens; step-3.5-flash at $0.21, $0.042, and $0.63; and qwen3.5-omni-flash at about $0.490976 input and $2.968176 output. The rows carry effective_date 2026-08-27, while the response itself is checked through 2026-09-10.
The live pricing response exposes the supported OpenAI path as /v1/chat/completions with POST and lists the currently usable default and VIP groups. Verify the exact model ID in the live response before copying it into a deployment manifest.
The public status and model documentation are evidence surfaces, not a substitute for a controlled client test. Keep the request small, use a placeholder key in documentation, and record only the metadata required to reconcile the result.
Planning Matrix
A source-dated planning matrix keeps the page useful for engineers and procurement reviewers. It turns a search query into an auditable route decision instead of a loose model preference.
| Check | What to verify | Evidence to keep |
|---|---|---|
| Credential | environment variable or secret manager | no key in source or logs |
| Endpoint | base URL and chat-completions path | HTTP method and response status |
| Model | current catalog and live route row | exact model ID and checked date |
| Budget | dated USD row and key group | input, cache, output fields |
| Response | finish reason and usage | request ID and token counts |
| Recovery | timeout and error mapping | bounded retry result |
Implementation Pattern
The implementation pattern keeps credentials as placeholders, pins the AIWave base URL, records the model, and leaves room for route-specific controls. Production applications should move credentials into environment or secret storage.
import os
from openai import OpenAI
api_key = os.environ.get("AIWAVE_API_KEY")
if not api_key:
raise RuntimeError("Set AIWAVE_API_KEY before running the test")
client = OpenAI(api_key=api_key, base_url="https://aiwave.live/v1")
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[{"role": "user", "content": "Return one short health-check sentence."}],
temperature=0.0, max_tokens=80,
)
print({"finish": response.choices[0].finish_reason,
"total_tokens": response.usage.total_tokens})
Write the Decision Record First
For a safe AIWave first-call checklist, record the workload, approved model IDs, endpoint, source date, output cap, retry ceiling, data class, budget owner, and fallback before traffic moves. A short decision record makes a later model or price change reviewable instead of surprising.
Keep Provider and Gateway Evidence Separate
Provider documentation describes direct-platform capabilities and billing concepts. AIWave endpoints describe the gateway's current route rows, public USD snapshot, supported endpoint type, and key-group context. A route row is not a promise that every provider feature is exposed or that a provider policy transfers automatically to the gateway.
Use a Representative Acceptance Set
Test one ordinary request, one long-context request, one malformed request, and one stop-condition request. Store model, finish reason, token usage, retry count, request identifier, checked source date, and reviewer decision. Do not promote a route because a single demo looked good.
Budget Input, Cache, and Output Independently
A single token total hides the cause of a bill. Store input tokens, cached input when exposed, output tokens, tool calls, and retries in separate fields. A route's output cap should follow the task class rather than a global default inherited by every feature.
Bound Retries and Fallbacks
Retry only errors that are safe to retry, use an attempt ceiling, and preserve the request ID. A fallback must be selected by policy, not by an unbounded loop. The receipt should show the original route, fallback route, stop reason, and whether the output was accepted or revised.
Use AIWave's Evidence Layer
Use the Chat Completions docs, Models docs, dated Pricing JSON, live route pricing, and Status. Read the live route table before a rollout, the dated pricing JSON before a budget review, the status page before a launch window, and the trust page before procurement review. Keep the checked dates in the internal decision record.
Final Promotion Checklist
Promotion is ready when provider sources are dated, AIWave routes are rechecked, public USD rows carry their own checked dates, canaries pass, output and retry limits exist, privacy handling is documented, and a reviewer can reconcile the receipt without seeing a prompt or reusable key.