fix: drop service_tier for Bedrock Mantle instead of forwarding a field it rejects - #6532
Merged
Merged
Conversation
…ld it rejects Requests carrying service_tier to bedrock_mantle fail with "'priority' is not supported for 'service_tier' on this model". Mantle's OpenAI-compatible surface does not implement service_tier, but Bifrost forwards it anyway. serviceTierForModel already strips tiers a model does not support, but it asks the datasheet and falls back to keeping the tier when no record exists (ServiceTierSupported's fallback=true). Caps resolve against the verbatim Mantle id — openai.gpt-5.6-terra, not gpt-5.6-terra — which generally has no row, so the fallback fires and the field reaches AWS. Gate on the provider before consulting the datasheet: Mantle accepts no tier at all, so the answer does not depend on catalog coverage. Mirrors the existing Gemini handling, which nulls ServiceTier outright. Provider bedrock is included because it reaches these converters only through the deprecated in-provider Mantle routing in bedrock/mantle.go — every other Bedrock path uses Converse and never touches the OpenAI converters. The fix lands in serviceTierForModel, which both ToOpenAIChatRequest and ToOpenAIResponsesRequest call, so chat and Responses are covered by one change. Callers lose no functionality: the field was producing a 400, and omitting it lets the endpoint serve at its default tier.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesThe service-tier converter now omits Service-tier rejection logic and validation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized fix stops an unsupported request parameter from being sent to the affected provider while preserving other providers' behavior; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Description checkExplanation The description explains the problem, implementation, affected providers, testing steps, behavior impact, related issue, and security considerations. It omits the template checklist, but the required technical information is otherwise complete. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Your free Security trial is over. An organization admin can activate billing to continue. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
akshaydeo
approved these changes
Aug 25, 2026
akhsaul
pushed a commit
to akhsaul/bifrost
that referenced
this pull request
Aug 27, 2026
…ld it rejects (maximhq#6532) Requests carrying service_tier to bedrock_mantle fail with "'priority' is not supported for 'service_tier' on this model". Mantle's OpenAI-compatible surface does not implement service_tier, but Bifrost forwards it anyway. serviceTierForModel already strips tiers a model does not support, but it asks the datasheet and falls back to keeping the tier when no record exists (ServiceTierSupported's fallback=true). Caps resolve against the verbatim Mantle id — openai.gpt-5.6-terra, not gpt-5.6-terra — which generally has no row, so the fallback fires and the field reaches AWS. Gate on the provider before consulting the datasheet: Mantle accepts no tier at all, so the answer does not depend on catalog coverage. Mirrors the existing Gemini handling, which nulls ServiceTier outright. Provider bedrock is included because it reaches these converters only through the deprecated in-provider Mantle routing in bedrock/mantle.go — every other Bedrock path uses Converse and never touches the OpenAI converters. The fix lands in serviceTierForModel, which both ToOpenAIChatRequest and ToOpenAIResponsesRequest call, so chat and Responses are covered by one change. Callers lose no functionality: the field was producing a 400, and omitting it lets the endpoint serve at its default tier.
occcat
pushed a commit
to occcat/bifrost
that referenced
this pull request
Sep 2, 2026
…ld it rejects (maximhq#6532) Requests carrying service_tier to bedrock_mantle fail with "'priority' is not supported for 'service_tier' on this model". Mantle's OpenAI-compatible surface does not implement service_tier, but Bifrost forwards it anyway. serviceTierForModel already strips tiers a model does not support, but it asks the datasheet and falls back to keeping the tier when no record exists (ServiceTierSupported's fallback=true). Caps resolve against the verbatim Mantle id — openai.gpt-5.6-terra, not gpt-5.6-terra — which generally has no row, so the fallback fires and the field reaches AWS. Gate on the provider before consulting the datasheet: Mantle accepts no tier at all, so the answer does not depend on catalog coverage. Mirrors the existing Gemini handling, which nulls ServiceTier outright. Provider bedrock is included because it reaches these converters only through the deprecated in-provider Mantle routing in bedrock/mantle.go — every other Bedrock path uses Converse and never touches the OpenAI converters. The fix lands in serviceTierForModel, which both ToOpenAIChatRequest and ToOpenAIResponsesRequest call, so chat and Responses are covered by one change. Callers lose no functionality: the field was producing a 400, and omitting it lets the endpoint serve at its default tier.
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.
Summary
Requests carrying
service_tiertobedrock_mantlefail with:Mantle's OpenAI-compatible surface does not implement
service_tier, but Bifrost forwards it anyway, so every such request 400s.serviceTierForModelalready strips tiers a model doesn't support — but it asks the datasheet and falls back to keeping the tier when no record exists (ServiceTierSupported'sfallback=true,core/schemas/modelcaps.go:238). Capabilities resolve against the verbatim Mantle id (openai.gpt-5.6-terra, notgpt-5.6-terra), which generally has no row — so the fallback fires and the field reaches AWS.Fail-open is the right default for a gateway that shouldn't silently drop params (see #5902, where the opposite behaviour silently downgraded billing tier). It's wrong only when the endpoint rejects the field outright, which is the case here.
Changes
ServiceTieroutright (core/providers/openai/chat.go:99).serviceTierForModel, which bothToOpenAIChatRequestandToOpenAIResponsesRequestcall — so chat and Responses are covered by one change.bedrockis included alongsidebedrock_mantle: it reaches these converters only through the deprecated in-provider Mantle routing inbedrock/mantle.go(verified — all fouropenai.HandleOpenAI*call sites incore/providers/bedrock/are in that file). Every other Bedrock path uses Converse and never touches the OpenAI converters, so the same fix covers the legacy route.No functionality is lost: the field was producing a 400, and omitting it lets the endpoint serve at its default tier.
Type of change
Affected areas
How to test
Three cases added to
TestOpenAIConvertersFilterUltrafastByModelCapability, which already exercises both the chat and Responses converters:bedrock_mantleopenai.gpt-5.6-terrabedrock_mantlegpt-5.6-terrabedrockopenai.gpt-5.4Confirmed they fail without the source change and pass with it; existing cases (OpenAI supported/unsupported, OpenRouter with and without metadata) are unaffected.
go build ./...,go vet, andgofmtare clean, and the full./providers/...+./schemas/...suites pass.Reproduced in production behind a governance load-balancer splitting bare
gpt-5.x80/20 betweenbedrock_mantleandopenai: errors appeared on exactly the Mantle share, none on the OpenAI share.Breaking changes
Requests that previously 400'd now succeed at the endpoint's default tier.
service_tierbehaviour for every other provider is untouched.Related issues
Related to #5902 (closed) — the mirror-image bug, where a missing datasheet row caused
service_tierto be silently dropped for the gpt-5.4 family on first-party OpenAI. Same datasheet-driven gating, failing in the opposite direction. That one was fixed with a datasheet update; this one can't be, because no set of catalog rows makes forwarding correct for an endpoint that rejects the field.A datasheet row publishing
service_tiers: []for Mantle ids would be a reasonable complement, but the provider gate holds regardless of catalog coverage.Security considerations
None. No auth, secrets, or PII involved — one request parameter is omitted for two provider values.