← Back to PRs

#16891: fix(models): generic opus-4-6 forward-compat for all providers

by battman21 open 2026-02-15 06:40 View on GitHub →
channel: telegram agents size: S
## 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