#16891: fix(models): generic opus-4-6 forward-compat for all providers
channel: telegram
agents
size: S
Cluster:
OpenAI Model Fixes and Updates
## Summary
Fixes #13281
The existing opus-4-6 forward-compat only works for `anthropic` and `google-antigravity` providers. Any other provider whose pi-ai catalog has `claude-opus-4-5` but not yet `claude-opus-4-6` (e.g. bedrock, vertex, custom Anthropic proxies) gets `Unknown model`.
- Adds a generic catch-all `resolveGenericOpus46ForwardCompatModel` that runs after the provider-specific handlers
- Works for any provider by searching the template under the actual provider name (not hardcoded)
- Handles all opus-4-6 variants including `-thinking` suffixes
- Provider-specific handlers (anthropic, antigravity) take priority and remain unchanged
## Test plan
- [x] Added 3 tests: bedrock opus-4-6, custom proxy opus-4-6-thinking, non-opus model unaffected
- [x] All 18 model tests pass (`pnpm test -- src/agents/pi-embedded-runner/model.test.ts`)
- [x] Existing provider-specific handlers unchanged — no regression
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
Adds generic opus-4-6 forward compatibility for all providers (bedrock, vertex, custom proxies) by falling back to opus-4-5 templates when opus-4-6 models aren't in the catalog. Provider-specific handlers (anthropic, antigravity) take precedence.
**Key changes:**
- New `resolveGenericOpus46ForwardCompatModel` function handles any provider
- Supports both dash (`claude-opus-4-6`) and dot (`claude-opus-4.6`) version formats
- Handles `-thinking` suffix variants
- Added 3 test cases covering bedrock, custom proxy, and non-opus models
- Chain order ensures provider-specific handlers run first
**Issue found:**
- Dot-versioned models (`claude-opus-4.6-*`) incorrectly match dash stem first due to `startsWith` crossing version format boundaries (src/agents/model-forward-compat.ts:257)
<h3>Confidence Score: 3/5</h3>
- Safe to merge with awareness of template matching issue
- Score reflects well-tested functionality with comprehensive test coverage, but the dot/dash version boundary bug (line 257) causes inefficient template lookups and could select wrong templates if both formats exist in registry. Fix would be straightforward but not critical since fallback chain eventually finds correct template.
- src/agents/model-forward-compat.ts line 257 needs the version format boundary fix
<sub>Last reviewed commit: 0466335</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#13119: fix: add forward-compat for google-antigravity claude-opus-4-6 models
by sdb001 · 2026-02-10
83.8%
#23250: feat: add Sonnet 4.6 forward compat for google-antigravity
by Oceanswave · 2026-02-22
83.0%
#10831: fix(agents): set Opus 4.6 context window to 1M in forward-compat fa...
by slawt · 2026-02-07
80.4%
#12220: fix: forward-compat models now respect user-configured contextWindow
by Batuhan4 · 2026-02-09
80.0%
#20095: fix(model-forward-compat): extend claude-sonnet-4.6 forward-compat ...
by SeeYangZhi · 2026-02-18
79.7%
#19533: fix: allow forward-compat models in buildAllowedModelSet
by Anthony-g-dev · 2026-02-17
79.5%
#18697: fix: include forward-compat models in model catalog for allowlist val…
by dmitry-orabey · 2026-02-17
79.1%
#13361: fix(google-antigravity): add Opus 4.6 support and fix thinking.sign...
by SovranAMR · 2026-02-10
77.4%
#22899: fix(models): synthesize antigravity Gemini 3.1 pro high/low models
by Phineas1500 · 2026-02-21
76.6%
#14508: fix(models): allow forward-compat models in allowlist check
by jonisjongithub · 2026-02-12
75.9%