litellm - 💡(How to fix) Fix [Feature]: cost_per_token() in cost_calculator.py should return (0.0, 0.0) for unrecognized models instead of raising [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#27581Fetched 2026-05-11 03:14:02
View on GitHub
Comments
3
Participants
2
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
commented ×3labeled ×2

Error Message

an exception when the model is not found in the pricing database: warnings.warn(f"No pricing data for model '{model}'. Returning (0.0, 0.0).") handle zero cost are unaffected, and callers that relied on the exception can users hit this exception on their very first call.

Code Example

from litellm import cost_per_token
  
  cost_per_token(
      model="openrouter/meta-llama/llama-3.3-70b-instruct",
      completion_tokens=50,
  )   
  # → raises: No cost information for model

---

# in cost_calculator.py
  warnings.warn(f"No pricing data for model '{model}'. Returning (0.0, 0.0).")
  return 0.0, 0.0
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

cost_per_token() and completion_cost() in litellm/cost_calculator.py raise an exception when the model is not found in the pricing database:

from litellm import cost_per_token

cost_per_token(
    model="openrouter/meta-llama/llama-3.3-70b-instruct",
    completion_tokens=50,
)   
# → raises: No cost information for model

Proposed fix — return (0.0, 0.0) with a UserWarning instead of raising:

# in cost_calculator.py
warnings.warn(f"No pricing data for model '{model}'. Returning (0.0, 0.0).")
return 0.0, 0.0

Motivation, pitch

Raising breaks any flow iterating over a mixed list of models. Downstream tools using LiteLLM's pricing functions are forced to wrap every single call in try/except and implement their own fallbacks — which defeats the purpose of having a shared pricing utility.

Returning (0.0, 0.0) with a warning is non-breaking: callers that already handle zero cost are unaffected, and callers that relied on the exception can check for zero instead.

Context

Ran into this while building Baar-Core, a pre-flight budget kill-switch for LLM agents that uses LiteLLM's cost_per_token() and completion_cost() for local cost enforcement — no proxy required.

This covers a gap that LiteLLM's existing budget manager doesn't address: SDK-side pre-flight enforcement for users not running the proxy. OpenRouter users hit this exception on their very first call.

Happy to open a PR for the fix in cost_calculator.py if this direction works for the maintainers. If the team is open to it, Baar-Core could also be listed as a companion library for SDK users who want hard budget limits without spinning up the proxy.

What part of LiteLLM is this about?

SDK (litellm Python package)

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

Yes

Twitter / LinkedIn details

@orvi_onethread / https://bd.linkedin.com/in/robatdasorvi-productdev

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix [Feature]: cost_per_token() in cost_calculator.py should return (0.0, 0.0) for unrecognized models instead of raising [3 comments, 2 participants]