feat: add sonnet and haiku to supported providers#1317
Conversation
- make supported providers list more dynamic for cli models
🦋 Changeset detectedLatest commit: 9433562 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughAdds three new model entries to supported-models.json, introduces Changes
Sequence Diagram(s)sequenceDiagram
participant Provider as AI Provider (claude-code / codex-cli)
participant Config as ConfigManager
participant JSON as supported-models.json
Note over Provider,Config: Provider initialization (constructor)
Provider->>Config: getSupportedModelsForProvider(providerName)
Config->>JSON: read MODEL_MAP / filter supported:true
JSON-->>Config: array of model IDs
Config-->>Provider: supported model list
alt models list empty
Provider->>Provider: log warning "no models loaded"
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (3)
🧰 Additional context used📓 Path-based instructions (5)src/ai-providers/*.js📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
Files:
**/*.js📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Files:
scripts/modules/supported-models.json📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
Files:
scripts/modules/**📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
Files:
scripts/modules/*📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
Files:
🧠 Learnings (4)📓 Common learnings📚 Learning: 2025-07-18T17:06:04.909ZApplied to files:
📚 Learning: 2025-07-18T17:06:04.909ZApplied to files:
📚 Learning: 2025-07-21T14:14:48.694ZApplied to files:
🧬 Code graph analysis (2)src/ai-providers/claude-code.js (2)
src/ai-providers/codex-cli.js (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (5)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (9)
.changeset/open-tips-notice.md(1 hunks)scripts/modules/config-manager.js(1 hunks)scripts/modules/supported-models.json(2 hunks)src/ai-providers/claude-code.js(2 hunks)src/ai-providers/codex-cli.js(2 hunks)tests/integration/claude-code-error-handling.test.js(1 hunks)tests/integration/claude-code-optional.test.js(1 hunks)tests/unit/ai-providers/claude-code.test.js(2 hunks)tests/unit/ai-providers/codex-cli.test.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (22)
tests/unit/ai-providers/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
Create unit tests for the new provider in tests/unit/ai-providers/.test.js, mocking @ai-sdk/ and core ai module functions, and testing all exported functions for correct behavior and error handling.
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.js
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jsscripts/modules/config-manager.jstests/integration/claude-code-error-handling.test.jssrc/ai-providers/claude-code.jssrc/ai-providers/codex-cli.jstests/integration/claude-code-optional.test.js
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
**/*.{test,spec}.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{test,spec}.{js,jsx,ts,tsx}: NEVER use async/await in test functions unless testing actual asynchronous operations
Use synchronous top-level imports in tests; avoid dynamic await import()
Keep test bodies synchronous whenever possible
Files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
scripts/modules/config-manager.js
📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
scripts/modules/config-manager.js: Update scripts/modules/config-manager.js to add the new provider to MODEL_MAP, ensure it is included in VALID_PROVIDERS, and update API key handling logic.
If adding Ollama or another provider not requiring an API key, add a specific check at the beginning of isApiKeySet and getMcpApiKeyStatus in scripts/modules/config-manager.js to return true immediately for that provider.
scripts/modules/config-manager.js: Import and use specific getters fromscripts/modules/config-manager.jsto access configuration values needed for application logic; pass theexplicitRootparameter to getters if calling from MCP direct functions.
UseisApiKeySet(providerName, session)fromconfig-manager.jsto check if a provider's key is available before attempting an AI call.
Handle potentialConfigurationErrorif the.taskmasterconfigfile is missing or invalid when accessed viagetConfig.
Files:
scripts/modules/config-manager.js
scripts/modules/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Each module in scripts/modules/ should be focused on a single responsibility, following the modular architecture (e.g., commands.js for CLI command handling, task-manager.js for task data and core logic, dependency-manager.js for dependency management, ui.js for CLI output formatting, ai-services-unified.js for AI service integration, config-manager.js for configuration management, utils.js for utility functions).
scripts/modules/*.js: Export all core functions, helper functions, and utility methods needed by your new function or command from their respective modules. Explicitly review the module's export block to ensure every required dependency is included.
Pass all required parameters to functions you call within your implementation and verify that direct function parameters match their core function counterparts.
Use consistent file naming conventions: 'task_${id.toString().padStart(3, '0')}.txt', use path.join for composing file paths, and use appropriate file extensions (.txt for tasks, .json for data).
Use structured error objects with code and message properties, include clear error messages, and handle both function-specific and file system errors.
Import all silent mode utilities together from 'scripts/modules/utils.js' and always use isSilentMode() to check global silent mode status. Wrap core function calls within direct functions using enableSilentMode() and disableSilentMode() in a try/finally block if the core function might produce console output.
Core functions should check outputFormat === 'text' before displaying UI elements and use internal logging that respects silent mode.
Design functions to accept dependencies as parameters (dependency injection) and avoid hard-coded dependencies that are difficult to mock.
Keep pure logic separate from I/O operations or UI rendering to allow testing the logic without mocking complex dependencies.
When implementing core logic for new features, do so in 'scripts/modules/' before CLI or MCP interfaces, and d...
Files:
scripts/modules/config-manager.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/config-manager.jsscripts/modules/supported-models.json
scripts/modules/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/*: Every command that reads or writes tasks.json must be tag-aware
All command files must import getCurrentTag from utils.js
Every CLI command that operates on tasks must include the --tag CLI option
All commands must resolve the tag using the pattern: options.tag || getCurrentTag(projectRoot) || 'master'
All commands must find projectRoot with error handling before proceeding
All commands must pass { projectRoot, tag } as context to core functions
MCP direct functions must accept and use a context object containing projectRoot and tag, and pass them to core functions
Do not hard-code tag resolution (e.g., const tag = options.tag || 'master';); always use getCurrentTag
Do not omit the --tag CLI option in commands that operate on tasks
Do not omit the context parameter when calling core functions from commands
Do not call readJSON or writeJSON without passing projectRoot and tag
Files:
scripts/modules/config-manager.jsscripts/modules/supported-models.json
tests/integration/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Integration tests in tests/integration/ should test interactions between modules.
Files:
tests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
tests/integration/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Integration tests must be located in tests/integration/, test interactions between modules, and focus on component interfaces rather than implementation details.
Files:
tests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
tests/{integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Properly mock session objects when required by functions, and reset environment variables between tests if modified.
Files:
tests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
src/ai-providers/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
src/ai-providers/*.js: Create a new provider module file in src/ai-providers/ named .js when adding a new AI provider.
Provider modules must export three functions: generateText, streamText, and generateObject.
Provider modules must import the provider's create function from @ai-sdk/, and import generateText, streamText, generateObject from the core ai package, as well as the log utility from ../../scripts/modules/utils.js.
Implement generateText, streamText, and generateObject functions in provider modules with basic validation and try/catch error handling.Provider-specific wrappers for Vercel AI SDK functions must be implemented in src/ai-providers/*.js, each file corresponding to a provider.
Files:
src/ai-providers/claude-code.jssrc/ai-providers/codex-cli.js
scripts/modules/supported-models.json
📄 CodeRabbit inference engine (.cursor/rules/ai_providers.mdc)
Add a new key for the provider and an array of model objects under it in scripts/modules/supported-models.json, including id, name, allowed_roles, and optionally swe_score, cost_per_1m_tokens, and max_tokens.
Files:
scripts/modules/supported-models.json
.changeset/*.md
📄 CodeRabbit inference engine (.cursor/rules/changeset.mdc)
.changeset/*.md: When runningnpm run changesetornpx changeset add, provide a concise summary of the changes for theCHANGELOG.mdin imperative mood, typically a single line, and not a detailed Git commit message.
The changeset summary should be user-facing, describing what changed in the released version that is relevant to users or consumers of the package.
Do not use your detailed Git commit message body as the changeset summary.
Files:
.changeset/open-tips-notice.md
.changeset/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Create appropriate changesets for new features, use semantic versioning, include tagged system information in release notes, and document breaking changes if any.
Files:
.changeset/open-tips-notice.md
.changeset/**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Changeset entries should be user-facing, describing the end-user impact rather than code specifics
Files:
.changeset/open-tips-notice.md
🧠 Learnings (8)
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to tests/unit/ai-providers/*.test.js : Create unit tests for the new provider in tests/unit/ai-providers/<provider-name>.test.js, mocking ai-sdk/<provider-name> and core ai module functions, and testing all exported functions for correct behavior and error handling.
Applied to files:
tests/unit/ai-providers/codex-cli.test.jstests/unit/ai-providers/claude-code.test.jstests/integration/claude-code-error-handling.test.jstests/integration/claude-code-optional.test.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to scripts/modules/config-manager.js : Update scripts/modules/config-manager.js to add the new provider to MODEL_MAP, ensure it is included in VALID_PROVIDERS, and update API key handling logic.
Applied to files:
tests/unit/ai-providers/codex-cli.test.jsscripts/modules/config-manager.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Applied to files:
tests/unit/ai-providers/claude-code.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Do not import real AI service clients in tests; create fully mocked versions that return predictable responses.
Applied to files:
tests/unit/ai-providers/claude-code.test.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Module dependencies should be mocked before importing the test module, following Jest's hoisting behavior.
Applied to files:
tests/unit/ai-providers/claude-code.test.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to scripts/modules/supported-models.json : Add a new key for the provider and an array of model objects under it in scripts/modules/supported-models.json, including id, name, allowed_roles, and optionally swe_score, cost_per_1m_tokens, and max_tokens.
Applied to files:
scripts/modules/config-manager.jsscripts/modules/supported-models.json
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Provider modules must import the provider's create<ProviderName> function from ai-sdk/<provider-name>, and import generateText, streamText, generateObject from the core ai package, as well as the log utility from ../../scripts/modules/utils.js.
Applied to files:
src/ai-providers/claude-code.jssrc/ai-providers/codex-cli.js
📚 Learning: 2025-07-21T14:14:48.694Z
Learnt from: rtmcrc
PR: eyaltoledano/claude-task-master#933
File: scripts/modules/supported-models.json:238-238
Timestamp: 2025-07-21T14:14:48.694Z
Learning: Model version updates in scripts/modules/supported-models.json may be included in feature PRs if they provide practical improvements like reduced error rates, even if not directly related to the main feature being implemented.
Applied to files:
scripts/modules/supported-models.json
🧬 Code graph analysis (3)
src/ai-providers/claude-code.js (2)
src/ai-providers/base-provider.js (1)
BaseAIProvider(16-377)scripts/modules/config-manager.js (1)
getSupportedModelsForProvider(315-322)
src/ai-providers/codex-cli.js (1)
scripts/modules/config-manager.js (1)
getSupportedModelsForProvider(315-322)
tests/integration/claude-code-optional.test.js (1)
src/ai-providers/claude-code.js (1)
ClaudeCodeProvider(33-133)
🪛 LanguageTool
.changeset/open-tips-notice.md
[grammar] ~5-~5: There might be a mistake here.
Context: ...aster-ai": minor --- Add 4.5 haiku and sonnet to supported models for claude-code and...
(QB_NEW_EN_OTHER)
🪛 markdownlint-cli2 (0.18.1)
.changeset/open-tips-notice.md
5-5: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (12)
scripts/modules/config-manager.js (1)
310-322: LGTM! Clean implementation of dynamic model loading.The
getSupportedModelsForProviderfunction correctly:
- Returns empty array for unknown providers
- Filters out unsupported models (
supported !== false)- Maps to return just model IDs
- Enables dynamic model loading across providers
This eliminates hardcoded model arrays and centralizes model configuration in
supported-models.json.tests/unit/ai-providers/codex-cli.test.js (1)
23-23: LGTM! Test mock correctly supplies supported models.The mock for
getSupportedModelsForProviderproperly returns the expected codex-cli models, enabling the unit tests to verify dynamic model loading behavior.tests/integration/claude-code-error-handling.test.js (1)
46-48: LGTM! Test expectations correctly include haiku model.The updated expectations reflect haiku as a supported claude-code model, consistent with the changes to supported-models.json and dynamic model loading.
src/ai-providers/codex-cli.js (2)
13-16: LGTM! Clean import of dynamic model loader.The import of
getSupportedModelsForProvideralongside the existing config manager import is well-organized.
26-27: Excellent refactor to dynamic model loading!Replacing the hardcoded model array with
getSupportedModelsForProvider('codex-cli'):
- Centralizes model configuration in supported-models.json
- Eliminates code duplication across providers
- Makes it easier to add/remove models without code changes
- Reduces maintenance burden
The comment accurately describes the source of the models.
tests/unit/ai-providers/claude-code.test.js (2)
31-37: LGTM! Comprehensive config-manager mock.The mock correctly provides all required config-manager exports including the new
getSupportedModelsForProviderfunction, returning the expected claude-code models with haiku included.
107-113: LGTM! Test expectations updated for haiku support.The tests correctly verify that haiku is now included in supported models and passes model validation checks.
tests/integration/claude-code-optional.test.js (1)
43-50: LGTM! Integration tests correctly verify haiku support.The updated expectations confirm that haiku is properly integrated across the claude-code provider's getSupportedModels() and isModelSupported() methods.
scripts/modules/supported-models.json (1)
93-103: haiku entry is correct: The model ID"haiku"aligns with the otherclaude-codeentries (opus,sonnet), and permitting"research"matches those entries’allowed_roles—no changes required.src/ai-providers/claude-code.js (3)
15-18: LGTM! Import statement follows existing patterns.The addition of
getSupportedModelsForProviderto the import is correctly structured and maintains consistency with the existing import format.
30-30: LGTM! Documentation accurately reflects the change.The comment correctly describes that models are now loaded dynamically from configuration rather than being hardcoded.
37-38: No action required: ‘claude-code’ usage is consistent.
The key'claude-code'exists insupported-models.jsonand is referenced uniformly in constants, provider modules, commands, config-manager, ai-services-unified, and tests.
| { | ||
| "id": "claude-sonnet-4-5-20250929", | ||
| "swe_score": 0.73, | ||
| "cost_per_1m_tokens": { | ||
| "input": 3.0, | ||
| "output": 15.0 | ||
| }, | ||
| "allowed_roles": ["main", "fallback"], | ||
| "max_tokens": 8192, | ||
| "supported": true | ||
| }, | ||
| { | ||
| "id": "claude-haiku-4-5-20251001", | ||
| "swe_score": 0.45, | ||
| "cost_per_1m_tokens": { | ||
| "input": 0.8, | ||
| "output": 4.0 | ||
| }, | ||
| "allowed_roles": ["main", "fallback"], | ||
| "max_tokens": 8192, | ||
| "supported": true | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify model IDs and metadata for new Anthropic models.
The new model entries use future release dates (20250929, 20251001) and specific pricing/performance data. Please confirm:
- These model IDs match official Anthropic model naming
- SWE scores (0.73, 0.45) are accurate for these model versions
- Pricing ($3/$15 and $0.8/$4 per 1M tokens) matches current rates
max_tokens: 8192is correct (notably lower than some existing models like claude-sonnet-4-20250514's 64000)
🏁 Script executed:
#!/bin/bash
# Verify Anthropic model information from official sources
echo "Checking latest Anthropic model information..."
# Check if model IDs follow expected patterns
echo "Model IDs to verify:"
echo "- claude-sonnet-4-5-20250929"
echo "- claude-haiku-4-5-20251001"
echo ""
echo "Expected format: claude-[model-type]-[version]-[YYYYMMDD]"Length of output: 183
🌐 Web query:
What are the official model IDs, pricing, and capabilities for Anthropic's Claude 4.5 Sonnet and Haiku models released in 2025?
💡 Result:
Summary — Claude 4.5 Sonnet and Haiku (Oct 2025)
Claude Sonnet 4.5
- Official model IDs: claude-sonnet-4-5 (alias); full version id example: claude-sonnet-4-5-20250929. [1][3]
- Pricing (Claude API list): $3 per M input tokens, $15 per M output tokens (batch: $1.50 / $7.50 per M). Long‑context / 1M-token options available for Sonnet. [2][3]
- Capabilities: frontier‑level reasoning, strong coding (SWE‑Bench leader), extended agent/long‑running task support (multi‑hour autonomous agent work), improved alignment and tool/computer use; intended as Anthropic’s mid/top-tier developer model. [1][4]
Claude Haiku 4.5
- Official model IDs: claude-haiku-4-5 (alias); full version id examples shown on partner platforms (e.g., claude-haiku-4-5@20251001 on Vertex AI / claude-haiku-4-5-20251001 for API/Bedrock). [3][4]
- Pricing (Claude API list / docs): $1 per M input tokens, $5 per M output tokens (batch: $0.40 / $2 per M); advertised ~1/3 the cost of Sonnet 4 and significantly faster/cheaper for scale. Regional/global endpoint options on third‑party platforms may affect pricing. [2][5][4]
- Capabilities: compact, cost‑efficient model that matches or approaches Sonnet 4 on many coding, tool‑use and visual reasoning tasks while being faster and cheaper — aimed at large‑scale, latency‑sensitive deployments (chatbots, agents, free tier usage). Context limits listed as ~200k tokens on some partner endpoints. [5][4]
Sources: Anthropic Sonnet 4.5 announcement & docs; Claude pricing/what’s‑new pages; Anthropic model overview; Google Vertex AI partner page for Claude Haiku 4.5; reporting on the Haiku 4.5 launch. [1][2][3][4][5]
Correct pricing and context limits for new Anthropic models.
- Pricing for claude-haiku-4-5-20251001 should be $1 input/$5 output per 1M tokens (not $0.8/$4.0).
- Confirm SWE scores (0.73 and 0.45) match official benchmark data.
- Update max_tokens: Sonnet supports up to 64 000 (not 8 192); Haiku supports ~200 k tokens on partner endpoints (not 8 192).
This PR was automatically generated to update documentation based on recent changes. Original commit: feat: add sonnet and haiku to supported providers (#1317)\n\n\n Co-authored-by: Claude <claude-assistant@anthropic.com>
What type of PR is this?
Description
Related Issues
How to Test This
# Example commands or stepsExpected result:
Contributor Checklist
npm run changesetnpm testnpm run format-check(ornpm run formatto fix)Changelog Entry
For Maintainers
Summary by CodeRabbit
New Features
Chores
Tests