bug: Some Anthropic (Claude) model names appear deprecated or invalid, resulting in 404 Not Found errors from the Anthropic API

[scadoshi]

• I have looked for existing issues (including closed) about this

Bug Report

Some of Rig's pre-defined Anthropic model constants (CLAUDE_3_5_SONNET, CLAUDE_3_7_SONNET) resolve to model identifiers that Anthropic's API no longer recognizes, resulting in 404 Not Found errors. This breaks model selection in applications using these constants from rig::providers::anthropic::completion.

Reproduction

Using Rig version 0.29.0, the following code fails when trying to use certain model constants:

use rig::{
    providers::anthropic::completion::{
        CompletionModel, CLAUDE_3_5_HAIKU, CLAUDE_3_5_SONNET, CLAUDE_3_7_SONNET,
        CLAUDE_4_OPUS, CLAUDE_4_SONNET,
    },
};

// In my scotbot CLI project, I build an agent like this:
let client = anthropic::Client::from_env();
let agent = client
    .agent(CLAUDE_3_7_SONNET)  // or CLAUDE_3_5_SONNET
    .preamble("You are a helpful assistant")
    .build();

// When sending a message:
let response = agent
    .chat(Message::user("Hello"), vec![].into())
    .await?;  // ❌ Fails with 404

Working models:

• CLAUDE_3_5_HAIKU ✅
• CLAUDE_4_OPUS ✅
• CLAUDE_4_SONNET ✅

Failing models:

• CLAUDE_3_5_SONNET ❌
• CLAUDE_3_7_SONNET ❌

Error message:

Error: CompletionError: HttpError: Invalid status code 404 Not Found with message:
{
  "type":"error",
  "error":{
    "type":"not_found_error",
    "message":"model: claude-3-7-sonnet-latest"
  },
  "request_id":"req_011CXr8vk1U7Q5zvnX4DuK"
}

Expected behavior

Rig's exported model constants should only include models that Anthropic currently supports. When a model is deprecated by Anthropic, the constant should either:

1. Be removed from Rig
2. Be updated to point to the correct current model identifier
3. Be marked as deprecated with a compile-time warning

Additional context

• Rig version: rig-core = "0.30.0"
• Rust version: Latest stable (2024 edition)
• Impact: Users using Rig's pre-defined constants hit runtime 404 errors when selecting these models

Suggestion: Update these constants to use accurate model names that match Anthropic's current API, or remove them if these models are no longer available.

[linear]

RIG-1185

[joshua-mo-143]

Looks OK to me. We should probably be checking these every once in a while.

[scadoshi]

@joshua-mo-143

Thoughts on something like the below as an enhancement? Might as well just go to the source of truth to get this stuff rather than hard code periodically..

Dynamic Model Discovery via Anthropic's List Models API

Status: Enhancement idea
Related to: Issue #1370 (deprecated model constants)

Problem

Currently, Rig uses hardcoded model constants that become outdated when Anthropic deprecates or releases new models. This requires manual framework updates and causes 404 errors for users when models are retired.

Potential Solution

Anthropic provides a /v1/models API endpoint that returns the current list of available models. This could be used to provide dynamic model discovery or validation.

---

API Specification

Endpoint

GET https://api.anthropic.com/v1/models

Request Headers

anthropic-version: 2023-06-01
x-api-key: YOUR_API_KEY

Query Parameters (Optional)

• limit (number): Items per page (default: 20, max: 1000)
• after_id (string): Cursor for next page
• before_id (string): Cursor for previous page

---

Example Request

curl https://api.anthropic.com/v1/models \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_API_KEY"

---

Example Response

{
  "data": [
    {
      "id": "claude-opus-4-6",
      "created_at": "2026-02-05T00:00:00Z",
      "display_name": "Claude Opus 4.6",
      "type": "model"
    },
    {
      "id": "claude-sonnet-4-5-20250929",
      "created_at": "2025-09-29T00:00:00Z",
      "display_name": "Claude Sonnet 4.5",
      "type": "model"
    },
    {
      "id": "claude-haiku-4-5-20251001",
      "created_at": "2025-10-01T00:00:00Z",
      "display_name": "Claude Haiku 4.5",
      "type": "model"
    },
    {
      "id": "claude-opus-4-5-20251101",
      "created_at": "2025-11-01T00:00:00Z",
      "display_name": "Claude Opus 4.5",
      "type": "model"
    }
  ],
  "has_more": false,
  "first_id": "claude-opus-4-6",
  "last_id": "claude-opus-4-5-20251101"
}

Response Fields

• id: Exact string to use in API requests (e.g., "claude-opus-4-6")
• created_at: ISO 8601 timestamp of model release
• display_name: Human-readable name
• type: Always "model"
• has_more: Whether more results exist
• first_id / last_id: Pagination cursors

---

Potential Benefits

1. Future-proof: Reduces need for constant updates when models change
2. Validation: Could validate model IDs before API calls
3. Discovery: Users could enumerate available models programmatically
4. Backwards compatible: Could coexist with existing constants

---

References

• Anthropic API Docs: https://docs.anthropic.com/en/api/models/list
• Related Issue: bug: Some Anthropic (Claude) model names appear deprecated or invalid, resulting in 404 Not Found errors from the Anthropic API #1370

[scadoshi]

Thinking about the principle of this more and it really does break the idea of what a constant is as it is reliant upon an external source of truth which is guaranteed to change.

Probably best to allow the user to simply submit their own model IDs. In asking the question of then how can this crate benefit the user in doing this? Probably just build a convenient API to go get what is currently available (for as many providers as we can given this will be the same across all of them likely).

Then the only thing we have to maintain is the request body of that handle as it could change over time but we are maintaining those across all providers now anyhow so it makes sense. Thoughts?

[joshua-mo-143]

Well, I mean if it really comes down to that all the const model identifiers are out of date, users can just use strings (edit: or I guess more to be more correct, &str). The model identifiers are simply to make it easier to use.

Model listing/fetching a list of models will already be partially solved by #1243 + the follow up PR from that, so I think we should wait first before trying to implement everything all at once.

[scadoshi]

Yep #1243 is exactly what would resolve this. Personally, would throw out the const model IDs altogether as they invite breaking changes in the long term.

[gold-silver-copper]

For now this has been fixed by #1616
Internally we are working on a better system for keeping models up to date, and considering how to remove constants if possible. Currently a lot of internal code hard codes capability by model name, so it will be a pretty big refactor once we get to it.