8 views
-/https://github.com/berriai/litellm/issues/29146
GitHub · issue

#29146 [Feature]: Add a typed exception for (This model isn't mapped yet) [provider=mistral]

  • State: open
  • Author: @mohamed-amir-ben-khadda-maif
  • Labels: enhancement, SDK

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

**Problem Statement**

Currently, when a model (with mistral provider) is requested but not mapped in LiteLLM, the system throws a generic Exception with a message similar to:

"This model isn't mapped yet"

Using a generic exception type makes it difficult for client code to:

Reliably detect this specific failure scenario Implement targeted error handling or retries Differentiate it from other runtime or configuration errors

**To reproduce**

` prompt_tokens_cost_usd, completion_tokens_cost_usd = litellm.cost_per_token( "mistral-medium-3.5-128b", 100, 100 custom_llm_provider="mistral" ) `

By the time this issue is being taken care of it could be that "mistral-medium-3.5-128b" is mapped, so you can put any unsupported model instead.

**Possible Enhancements**

` class ModelNotMappedError(Exception): """Raised when a requested model is not mapped in LiteLLM.""" pass `

` raise ModelNotMappedError("This model isn't mapped yet. model={}, custom_llm_provider={}. Add it here - https://github.com/BerriAI/litellm/bl…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (5 events)
#0 of 0 · 31d19h29s ago — entered · #import:https:::github.com:berriai:litellm post #1859
The right-hand task requires tracing data through a specialized proxy path, preserving differentiated metadata, applying pricing logic correctly, and adding regression coverage across billing behavior. The left-hand task is comparatively localized, mainly involving exception definition, replacement, and compatibility checks.
Introducing a new typed exception requires tracing model-resolution failure paths, integrating it with LiteLLM's exception hierarchy and provider-specific behavior, and adding compatibility-focused tests. The guardrail issue is comparatively localized: correcting a key lookup and updating targeted tests, with limited behavioral surface.
The right issue is harder because it requires tracing runtime error paths, introducing and exposing a stable exception type, preserving compatibility, and adding comprehensive tests. The left issue is a localized, synchronized metadata update with limited behavioral risk.
The left requires cross-layer dashboard work, upload handling, request integration, and endpoint-specific validation; the right is comparatively localized to SDK exception definition, propagation, and tests.
#0 of 0 · 31d17h52m27s ago — current · #import:https:::github.com:berriai:litellm post #2994
The left issue is harder because it requires provider-specific request/response translation across differing Gemini API semantics, preservation of reasoning metadata, and regression coverage for multiple model generations. The right issue is comparatively localized: define and raise a typed exception at the unmapped-model path while maintaining compatibility with existing callers.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search