fix: perplexity responses api compatibility - #4813
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 48 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughPerplexity now refines nested model names, resolves ChangesPerplexity Responses endpoint routing
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Confidence Score: 3/5The core routing logic is sound, but the addition of Perplexity to RefineModelForProvider introduces a model-name mangling risk that could silently break all Perplexity API calls when catalog entries carry a perplexity/ prefix. The Responses/ResponsesStream routing change is well-reasoned and the streaming path uses the correct client. The concern is the unexplained addition of schemas.Perplexity to RefineModelForProvider: that helper is designed for providers whose APIs accept a leading provider/ segment (Groq, Replicate). Perplexity's API does not — any pool model stored as perplexity/sonar-pro would cause the governance plugin to set request.Model to that prefixed string, producing model-not-found errors on every call to both the /v1/responses and /chat/completions paths. framework/modelcatalog/models.go — the new Perplexity case in RefineModelForProvider needs justification or removal; core/providers/perplexity/perplexity_test.go — ListModels scenario should be enabled now that the operation is implemented. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Responses / ResponsesStream] --> B[ResolveCanonicalModel]
B --> C{isPerplexityResponsesSupported?}
C -->|sonar-* variant| D[ChatCompletion fallback]
C -->|sonar base or non-sonar| E[HandleOpenAI Responses handler]
D --> F[chat completions endpoint]
E --> G[v1 responses endpoint]
subgraph Governance plugin
H[RefineModelForProvider NEW] --> I[refineNestedProviderModel for Perplexity]
I --> J{Catalog entry has perplexity prefix?}
J -->|Yes| K[Sets model to perplexity slash model-name]
J -->|No| L[Model unchanged]
end
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[Responses / ResponsesStream] --> B[ResolveCanonicalModel]
B --> C{isPerplexityResponsesSupported?}
C -->|sonar-* variant| D[ChatCompletion fallback]
C -->|sonar base or non-sonar| E[HandleOpenAI Responses handler]
D --> F[chat completions endpoint]
E --> G[v1 responses endpoint]
subgraph Governance plugin
H[RefineModelForProvider NEW] --> I[refineNestedProviderModel for Perplexity]
I --> J{Catalog entry has perplexity prefix?}
J -->|Yes| K[Sets model to perplexity slash model-name]
J -->|No| L[Model unchanged]
end
Reviews (5): Last reviewed commit: "fix: perplexity responses api compatibil..." | Re-trigger Greptile |
fca4e63 to
707421f
Compare
The merge-base changed after approval.
707421f to
1d6c19c
Compare
1d6c19c to
ad975da
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
core/providers/perplexity/perplexity.go (1)
256-291: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd table-driven coverage for Perplexity Responses routing
core/providers/perplexity/perplexity_test.godoesn’t cover the newisPerplexityResponsesSupportedsplit. Add cases for a supported model hitting/v1/responses, asonar-*model falling back to/chat/completions, and the streaming fallback settingBifrostContextKeyIsResponsesToChatCompletionFallback. Basesonarstays on/v1/responses.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@core/providers/perplexity/perplexity.go` around lines 256 - 291, Add table-driven tests around PerplexityProvider.ResponsesStream and isPerplexityResponsesSupported to cover the new routing split: verify a supported model goes through openai.HandleOpenAIResponsesStreaming against /v1/responses, verify a sonar-* model falls back to provider.ChatCompletionStream with request.ToChatRequest() targeting /chat/completions, and verify the fallback path sets BifrostContextKeyIsResponsesToChatCompletionFallback in the BifrostContext. Also include a case for base sonar to confirm it remains routed to /v1/responses.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@core/providers/perplexity/perplexity.go`:
- Around line 256-291: Add table-driven tests around
PerplexityProvider.ResponsesStream and isPerplexityResponsesSupported to cover
the new routing split: verify a supported model goes through
openai.HandleOpenAIResponsesStreaming against /v1/responses, verify a sonar-*
model falls back to provider.ChatCompletionStream with request.ToChatRequest()
targeting /chat/completions, and verify the fallback path sets
BifrostContextKeyIsResponsesToChatCompletionFallback in the BifrostContext. Also
include a case for base sonar to confirm it remains routed to /v1/responses.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 0f070a09-6161-4c9b-a871-6b3f62006e1f
📒 Files selected for processing (3)
core/providers/perplexity/perplexity.gocore/providers/perplexity/responses.goframework/modelcatalog/models.go
🚧 Files skipped from review as they are similar to previous changes (2)
- framework/modelcatalog/models.go
- core/providers/perplexity/responses.go
Merge activity
|
ad975da to
df11d15
Compare
df11d15 to
d43eeec
Compare
* upstream/dev: feat(mcp): add per-MCP-server tool execution timeout (maximhq#4472) fix: billing on failed responses stream requests anthropic and bedrock (maximhq#4842) fix: gemini openai through signature compatibility (maximhq#4810) fix: cancelled state in logs (maximhq#4831) fix: perplexity responses api compatibility (maximhq#4813) docs: clarify two-layer token refresh behavior and disabled-client refresh token expiry (maximhq#4849) fix: skip background token refresh for disabled/unconfigured MCP clients and guarantee non-nil logger in sync workers (maximhq#4848)

Summary
Perplexity's
/v1/responsesendpoint does not support all Sonar model variants. Previously, all Responses and ResponsesStream calls fell back unconditionally to/chat/completions. This PR adds model-aware routing so that models supported on/v1/responsesare sent there via the OpenAI-compatible handler, whilesonar-*variants (excluding the basesonarmodel) continue to fall back to/chat/completions.Changes
isPerplexityResponsesSupportedto detect whether a model can use Perplexity's/v1/responsesendpoint. Any model with asonar-prefix (after stripping an optionalperplexity/namespace) is considered unsupported and falls back to/chat/completions.Responsesnow conditionally callsopenai.HandleOpenAIResponsesRequestfor supported models instead of always converting to a chat request.ResponsesStreamnow conditionally callsopenai.HandleOpenAIResponsesStreamingfor supported models, only setting theIsResponsesToChatCompletionFallbackcontext flag when the fallback path is actually taken.Type of change
Affected areas
How to test
Send a Responses request using a supported model (e.g.
sonar) and verify it is routed to/v1/responses. Send a request using an unsupported variant (e.g.sonar-pro,sonar-reasoning) and verify it falls back to/chat/completions.Breaking changes
Related issues
Security considerations
No new auth mechanisms introduced. API key is passed via the existing Bearer token header, consistent with other OpenAI-compatible providers.
Checklist
docs/contributing/README.mdand followed the guidelines