OpenAI client migration

Change the route without rewriting the application.

Keep an OpenAI-compatible client while you test Chinese AI model routes with USD billing, dated rates, and request-level charge evidence.

Test the migration path Check dated pricing

Start with a request you can verify.

Keep the model ID, status, usage fields, and effective group beside the test result.

One request before production traffic

BASE URLCHECK

Change one connection surface.

Point the supported client at AIWave, load the key from an environment variable, and keep the original client contract visible.

MODEL IDCHECK

Pin the route you accepted.

Choose an explicit model ID and save it with the test result instead of relying on an unnamed default.

FAILURECHECK

Test the boundaries before launch.

Exercise 401, 402, 429, timeout, and context overflow handling before increasing traffic.

curlOpenAI-compatible chat request

curl https://aiwave.live/v1/chat/completions \
  -H "Authorization: Bearer $AIWAVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-pro","messages":[{"role":"user","content":"Reply with one sentence."}]}'

Questions to settle before you send traffic.

The answers keep account, route, and billing boundaries explicit.

What changes in an existing OpenAI client?

For supported chat requests, change the base URL, API key, and model ID. Review any provider-specific request fields separately.

Should I move all traffic at once?

No. Start with one representative workload, compare the completed result and ledger, then expand only after the acceptance checks pass.

How do I keep costs reviewable?

Capture the dated input, cache-hit input, and output rates with the effective account group and completed request record.