fix(models): map legacy provider api_type values to pi's canonical api ids#418
Open
jacoblee-io wants to merge 1 commit into
Open
fix(models): map legacy provider api_type values to pi's canonical api ids#418jacoblee-io wants to merge 1 commit into
jacoblee-io wants to merge 1 commit into
Conversation
…i ids
Selecting "Anthropic" as a model provider has never worked: the option
stored api_type="anthropic", which flowed verbatim into every model
config's `api` field — but pi-ai's API-provider registry only knows
"anthropic-messages" ("anthropic" is a provider slug there, not an
api), so every turn failed with "No API provider registered for api:
anthropic". The bare-API default "openai" had the same latent problem.
Fix on both sides:
- normalizeProviderApi() in core/model-compat maps the legacy values
(anthropic → anthropic-messages, openai → openai-completions) and
passes everything else through. Applied at every boundary that builds
a pi model config from model_providers.api_type: the four adapter
handlers (agent settings + model-binding, HTTP and WS mirrors),
chat-gateway, cli-snapshot-api, and model-routing-config. Existing DB
rows keep working with no migration.
- The TUI Anthropic preset and the provider-create default now emit
canonical ids.
- Models page: select options store canonical ids; the edit form maps a
legacy stored value so it displays (and re-saves) correctly.
Deliberately untouched: the default-provider endpoints that return raw
rows to sicore, and ai-security-reviewer (raw chat/completions fetch,
not pi) — normalizing those could change consumer-side comparisons.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Selecting Anthropic as a model provider has never worked. Every chat turn fails immediately with:
Root cause
The Models page stored
api_type="anthropic", which flowed verbatim into every model config'sapifield (adapter → agentbox → pi ModelRegistry, no validation or aliasing anywhere). pi-ai's API-provider registry only registersanthropic-messages—anthropicis a provider slug there, not an api id — soresolveApiProvider()throws on the first prompt. Verified this was broken since the Portal's first commit (pi-ai 0.55.3 already only knewanthropic-messages); it went unnoticed because everyone used OpenAI-compatible endpoints. The bare-API create default"openai"had the same latent problem (openai-completionsis the registered id).Fix
Backend (read-time normalization — existing DB rows keep working, no migration):
normalizeProviderApi()incore/model-compat.ts:anthropic→anthropic-messages,openai→openai-completions, everything else passes through.model_providers.api_type: the four adapter handlers (agent settings + model-binding, HTTP and WS mirrors),chat-gateway,cli-snapshot-api(TUI snapshot),model-routing-config(fallback routing).provider-presets.ts) and the provider-create default now emit canonical ids.Frontend (canonical values going forward):
anthropic-messages/openai-completions; the edit form maps a legacy stored value so it displays and re-saves correctly instead of snapping to the first option.Deliberately untouched: the default-provider endpoints that return raw rows to sicore, and
ai-security-reviewer(rawchat/completionsfetch, not pi) — normalizing those could change consumer-side comparisons.Testing
normalizeProviderApi(legacy mapping, passthrough, case/whitespace tolerance, empty fallback) and frontendnormalizeApiType.tsc --noEmitclean on backend + portal-web; backend suite green at repo root; portal-web tests pass.🤖 Generated with Claude Code