fix: use custom api type to prevent conflict with built-in Anthropic provider#1
Open
ramonvg wants to merge 1 commit into
Open
Conversation
…provider Register kimi-coding with kimi-anthropic-messages / kimi-openai-completions instead of the built-in anthropic-messages / openai-completions api types. Using a built-in api type with a custom streamSimple caused pi-coding-agent to route Claude/Anthropic requests through streamSimpleKimi, resulting in a 401 invalid x-api-key error. Also guard apiKey forwarding in buildPatchedOptions so an empty/missing KIMI_API_KEY never overwrites the caller's OAuth credential, and route internally by PROTOCOL instead of model.api since the registered api type is now a custom string.
|
Hello @Leechael! Any change to get this merged? |
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
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
When
KIMI_CODE_PROTOCOLis not set (the default), the provider registers withapi: "anthropic-messages"— the same built-in API type used by the Anthropic provider. Combined with a customstreamSimple, this causes pi-coding-agent to route Claude/Anthropic requests throughstreamSimpleKimi, resulting in:The official custom-provider-anthropic example shows the correct pattern: when using
streamSimple, always register with a customapistring (e.g."custom-anthropic-api"), not a built-in one.Changes
Add
KIMI_API_TYPE— resolves to"kimi-anthropic-messages"or"kimi-openai-completions"instead of the built-in names.Change
api: PROTOCOL→api: KIMI_API_TYPEinregisterProvider— the root fix; the kimi provider no longer claims a built-in protocol handler.Route by
PROTOCOLinstead ofmodel.apiinstreamSimpleKimi— sincemodel.apiis now a custom string, the OpenAI vs Anthropic branch uses the module-levelPROTOCOLconstant instead.Guard
apiKeyforwarding inbuildPatchedOptions— never spread an emptyapiKeyontopatchedOptions, which would silently overwrite a valid OAuth credential passed in by the caller.Summary by cubic
Prevents conflicts with the built-in Anthropic provider by registering
kimi-codingwith custom API types, so Claude/Anthropic requests no longer route throughstreamSimpleKimiand return 401s. Also improves credential handling and internal routing.apivalues:kimi-anthropic-messages/kimi-openai-completions(viaKIMI_API_TYPE).PROTOCOLinstead ofmodel.apito align with the customapi.apiKeyonly when present to avoid overwriting caller OAuth credentials.Written for commit 489fd3c. Summary will update on new commits.