/v1/chat/completions does NOT restore gateway alias on response.model (inconsistent with /v1/messages two-step rewrite)

[moonming]

Behavior inconsistency between two surfaces

Endpoint	Customer-visible response.model
/v1/chat/completions	upstream id (verbatim from upstream echo)
/v1/messages	gateway-facing alias (DP rewrites upstream id → alias on the way out)

Confirmed by audit + existing pinned tests

/v1/messages performs a two-step model rewrite (alias→upstream on request, upstream→alias on response) at crates/aisix-proxy/src/messages.rs:142-249, 335-339. This is pinned by dashboard/tests/e2e/dp-messages-anthropic-roundtrip-live.spec.ts:193 which asserts body.model === modelName (the dashboard alias).

/v1/chat/completions does NOT perform the inbound rewrite:

• crates/aisix-proxy/src/chat.rs:985 calls render_response(now, upstream).
• crates/aisix-proxy/src/render.rs:81-103 constructs ChatCompletion { model: resp.model, ... } from the bridge's parsed upstream response.
• crates/aisix-provider-openai/src/wire.rs:186-223 response_into_chat_response sets ChatResponse.model = raw.model.
• This is pinned by dashboard/tests/e2e/dp-completions-live.spec.ts which explicitly asserts body.model === 'gpt-3.5-turbo-instruct' (the upstream id) with the comment "Model rewrite: response carries the upstream id, not the proxy-side display name."

Why this matters

Customer SDKs that branch on the model field (e.g. caching layers, billing reconciliation, dashboard analytics that match alias) get the upstream id on /v1/chat/completions but the alias on /v1/messages. A customer using both endpoints sees two different model names for the same Model resource. LiteLLM and Portkey both restore the alias on both endpoints (verified against LiteLLM docs and runtime behavior).

Question for triage

Pick a direction:

(a) Restore alias on both endpoints (the LiteLLM/Portkey convention). Pro: consistent customer experience, alias is what the dashboard displays. Con: dp-completions-live test needs updating to assert alias instead of upstream id, which is a behavior change for any external consumer that depends on the current shape.

(b) Drop alias restoration from /v1/messages to match /v1/chat/completions. Pro: simpler code (no two-step rewrite). Con: customer doesn't see the alias they configured — leaks upstream id, surprises Anthropic SDK users who pinned alias.

(c) Document the inconsistency as intentional and add UI/SDK notes. Pro: zero code change. Con: confusing, hard to justify product-wise.

My read: (a) is the right answer for a managed-gateway product but is a breaking-change for body.model consumers, so should be gated/documented or coordinated with major version.

Related

• AISIX-Cloud refactor(server): inline DeepSeek/Google bridge factories + delete wrapper crates (Phase A) #302 D3.1 (this question surfaced during the long-tail matrix audit)
• AISIX-Cloud PR docs: correct cache-fingerprint description on enable-response-caching tutorial (caller key is excluded, not included) #349 (initially asserted alias-restore on /v1/chat/completions; aligned to current upstream-id behavior pending this issue's triage)

[coderabbitai]

🔗 Related PRs

#39 - feat(proxy): add anthropic messages api [merged]
#92 - feat: unified chat handler [merged]
#254 - fix(proxy): translate Anthropic tools/tool_choice to OpenAI shape in cross-provider dispatch (streaming + non-streaming) [merged]
#279 - refactor: rename provider 'gemini' to 'google' to match models.dev [merged]
#283 - chore: remove legacy DP registration [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[moonming]

Fixed by #360 (merged) — /v1/chat/completions now echoes the customer-facing model alias on response.model, matching the /v1/messages two-step rewrite (cross-endpoint alias-echo parity).

Verified end-to-end: dashboard/tests/e2e/matrix/adapter-openai-longtail-live.spec.ts hard-asserts resp.model === <gateway alias> on the non-stream /v1/chat/completions path (the assertion was flipped on from its prior hold-back after #360 merged). The e2e is green on AISIX-Cloud main.

Closing as completed — the fix is merged and locked by the e2e regression net.