[BUG] LiteLLM Integration Fails When /v1/model/info Is Inaccessible

[Syntax-Boldt]

Extension: Roo Code
Version: 3.51.1
VS Code Version: 1.110.0
Operating System: Windows 11

---

Description

The LiteLLM integration fails when the endpoint /v1/model/info is not accessible. The extension does not attempt to query /v1/models as a fallback, even though that endpoint successfully can return the list of available models.

---

Expected Behavior

If /v1/model/info is unreachable or returns an error (e.g., 403 Forbidden), Roo Code should automatically attempt to query /v1/models to retrieve model information.

---

Actual Behavior

Only /v1/model/info is queried. When that endpoint fails, no fallback request to /v1/models is made, causing the integration to fail and preventing model discovery.

---

Relevant Endpoint Documentation

• LiteLLM /v1/models – Model List API

---

Trace / Log Output

[2026-03-09T10:49:14.386Z] Fetching from:: "https://example.com/v1/model/info"
[2026-03-09T10:49:14.858Z] Response status:: "403 Forbidden"
[2026-03-09T10:49:14.859Z] Fetching from:: "https://example.com/v1/models"
[2026-03-09T10:49:15.352Z] Response status:: "200 OK"
[2026-03-09T10:49:15.354Z] Parsed response:: {
  "object": "list",
  "modelCount": 78
}

---

Suggested Fix

Implement a fallback mechanism:

1. Attempt to fetch from /v1/model/info.
2. If the request fails or returns a non‑200 status, automatically retry with /v1/models.
3. Parse and use whichever endpoint responds successfully.

Context (who is affected and when)

Enterprise or managed LiteLLM users where /v1/model/info is blocked by API gateways or internal policies.
Teams with LiteLLM authentication via base URL and API key
Users behind proxys or vpns, when the endpoint is blocked

Reproduction steps

1. Open VS Code and launch Roo Code (version 3.51.1).
2. Configure Roo Code to connect to the LiteLLM base URL and provide the API key.
3. Set up LiteLLM with API key authentication using a base URL (e.g., https://example.com).

• Ensure the endpoint /v1/model/info is restricted or returns 403 Forbidden.
• Verify that /v1/models is accessible and returns a valid model list.

4. Trigger model fetching

Expected result

If /v1/model/info is unreachable or returns an error (e.g., 403 Forbidden), Roo Code should automatically attempt to query /v1/models to retrieve model information.

Actual result

Only /v1/model/info is queried. When that endpoint fails, no fallback request to /v1/models is made, causing the integration to fail and preventing model discovery.

App Version

3.51.1

API Provider (optional)

LiteLLM

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

The problem is in src/api/providers/fetchers/litellm.ts - the getLiteLLMModels function only queries /v1/model/info. When that endpoint returns a non-200 status (e.g., 403 Forbidden), the function throws an error without attempting any fallback.

Proposed fix:

1. Modify getLiteLLMModels() in src/api/providers/fetchers/litellm.ts to add a fallback mechanism:

   • First, attempt to fetch from /v1/model/info (current behavior, returns richer model metadata)
   • If that request fails (network error or non-200 status), catch the error and attempt /v1/models as a fallback
   • Parse the /v1/models response (which returns { data: [{ id: "model-name", ... }] } in OpenAI-compatible format) into the same ModelRecord format, using sensible defaults for fields not available from this simpler endpoint

2. Extract the /v1/models fallback parser as a separate helper within the same file to keep the code clean and testable

3. Update tests in src/api/providers/fetchers/__tests__/litellm.spec.ts to cover:

   • The existing /v1/model/info happy path (unchanged)
   • Fallback to /v1/models when /v1/model/info returns 403
   • Fallback to /v1/models when /v1/model/info returns other errors (500, timeout, etc.)
   • Both endpoints failing (should still throw a descriptive error)

This approach preserves backward compatibility -- users whose /v1/model/info works will see no change. Users with restricted access will benefit from the automatic fallback to /v1/models.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[Syntax-Boldt]

@roomote This looks like a good plan to fix the issue without changing the function for existing users. Is approved.

[roomote-v0]

I've seen the approval and will start implementing the fallback mechanism now. I'll open a PR to share progress shortly.

[roomote-v0]

Opened PR #11899 with my attempt at addressing this. The fallback mechanism tries /v1/model/info first, then automatically falls back to /v1/models if it fails. Feedback welcome!