ccusage fails when LiteLLM API is unavailable

首先感谢作者开发的这个工具，他很有意思，我把遇到的问题向您反馈下。

Background

I discovered this ccusage tool on X.com and found it very meaningful for tracking Claude usage. However, I encountered some issues during local testing that prevented the tool from working properly.

Given my limited technical expertise, I sought assistance from AI to help diagnose the problem. The AI provided some analysis and conclusions, but I'm not entirely certain about the accuracy of its findings. I'd appreciate it if you could review the investigation and let me know your thoughts.

Problem

ccusage becomes completely unusable when the LiteLLM API service is down, failing with "fetch failed" error during pricing data retrieval.

Error Details

ERROR  Failed to fetch model pricing: fetch failed
Error: Could not fetch model pricing data
    at fetchModelPricing (pricing-fetcher.js:33:9)

Root Cause Investigation

Network connectivity test: ✅ Working fine

$ curl -I https://www.google.com  # Success

LiteLLM API status check: ❌ Service unavailable

$ curl -I https://api.litellm.ai/
HTTP/2 503
server: cloudflare
x-render-routing: suspend

$ curl -I https://api.litellm.ai/pricing  
HTTP/2 503

Conclusion: The issue is caused by LiteLLM API returning HTTP 503 errors, not user configuration problems.

Impact

ccusage becomes completely unusable during LiteLLM service outages
Users cannot analyze their Claude usage data at all
Tool has single point of failure dependency on external service

Proposed Solution: Multi-Source Pricing Fallback

Implement a robust fallback chain to eliminate dependency on single external service:

Fallback Chain Design

1. LiteLLM API (primary)
   ↓ (on 503/timeout)
2. Anthropic official pricing API
   ↓ (on failure)
3. Static Claude pricing file (GitHub/CDN)
   ↓ (on failure)
4. Local cached pricing data
   ↓ (on failure)  
5. Built-in Claude pricing table

Implementation Benefits

✅ Eliminates single point of failure
✅ Always functional, even when external APIs are down
✅ Uses most current pricing when available
✅ Graceful degradation with user warnings

Configuration Options

# Manual source selection
ccusage --pricing-source anthropic
ccusage --pricing-source cache
ccusage --pricing-source builtin

# Fallback mode indicators
ccusage daily  # Shows: "⚠️ Using cached pricing (LiteLLM API unavailable)"

# Tokens-only mode
ccusage --no-pricing  # Skip cost calculation entirely

Additional Improvements

Local caching: Store successful API responses with TTL
Retry logic: Exponential backoff for temporary failures
Status indicators: Clear warnings when using fallback data
User overrides: Allow manual pricing configuration

Alternative Data Sources

Anthropic: Official Claude API pricing endpoints
Static JSON: Community-maintained Claude pricing on GitHub/jsDelivr
Vendor pages: Scrape Anthropic's official pricing pages as last resort

Expected User Experience

# Current (broken)
$ ccusage daily
ERROR: Failed to fetch model pricing

# Improved (resilient)  
$ ccusage daily
⚠️ LiteLLM API unavailable, using cached pricing data (2 days old)
[Shows usage report successfully]

This architecture change would make ccusage much more reliable and user-friendly, ensuring it works even when external dependencies fail.

I see that OpenRouter also provides a public pricing query API endpoint.
API endpoint: https://openrouter.ai/api/v1/models
I'm wondering if this could be helpful for this project.

Pricing Data Structure:
Each model returns pricing information including:

"pricing": {
    "prompt": "0.000003",           // Per-token prompt price
    "completion": "0.000015",       // Per-token completion price  
    "request": "0",                 // Fixed price per request
    "image": "0.0048",             // Per-image price
    "web_search": "0",             // Web search price
    "internal_reasoning": "0",      // Internal reasoning price
    "input_cache_read": "0.0000003", // Input cache read
    "input_cache_write": "0.00000375" // Input cache write
}

Finally, by cloning the code locally and having Claude Code analyze it, I discovered the real cause of the problem. It is essentially still a network issue (mainland China network restrictions). Although I configured a proxy, it seems that for some reason the proxy cannot be used. The following is the resolution process organized by AI:

Problem

When running ccusage, encountered network connection error:

ERROR Failed to fetch model pricing: fetch failed

The tool was unable to access the LiteLLM pricing API at:
https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_
context_window.json

Root Cause

Node.js v22.12.0 fetch API had connectivity issues in certain network
environments
Local proxy settings (https_proxy=http://127.0.0.1:8888) interfered
with the request
The issue persisted even when proxy environment variables were
disabled

Solution

Modified the pricing URL to use a GitHub mirror service:

Original URL:
https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json

Mirror URL:
https://ghfast.top/https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json

Code Change:
In src/pricing-fetcher.ts, line 14:
const LITELLM_PRICING_URL =
"https://ghfast.top/https://raw.githubusercontent.com/BerriAI/litellm/
main/model_prices_and_context_window.json";

Result

✅ Successfully loads 1053+ model pricing entries
✅ All ccusage functionality works normally
✅ No changes needed to the core logic

Alternative Workarounds

For users experiencing similar issues:

Use --mode display to bypass network requests entirely
Use --mode calculate only when network access is available
Consider adding configurable mirror URL support for different regions

Hi
I know China has a complicated Internet network issue.
So if you have any solutions to solve this problem, just send a PR.

@yonghao2011
My questions are

which is better, litellm or openrouter
is the price info from litellm and openrouter same?

Also openrouter uses different model name.... 🤔

Looks like the key issue here is issue's author find that they cannot let ccusage use proxy to get past GFW.
Submitted a PR to fetch using proxy if HTTP(S)_PROXY env var is configured.

#51 this PR adds support for --fetch local_model_price.json

Then you can download and prepare the data file using whatever proxy you want

refactor(adapter/copilot): drop unused _event_id param + trim 3 multi…

Navigation Menu

Repository navigation

ccusage fails when LiteLLM API is unavailable #13

Background

Problem

Error Details

Root Cause Investigation

Impact

Proposed Solution: Multi-Source Pricing Fallback

Fallback Chain Design

Implementation Benefits

Configuration Options

Additional Improvements

Alternative Data Sources

Expected User Experience

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ccusage fails when LiteLLM API is unavailable #13

Description

Background

Problem

Error Details

Root Cause Investigation

Impact

Proposed Solution: Multi-Source Pricing Fallback

Fallback Chain Design

Implementation Benefits

Configuration Options

Additional Improvements

Alternative Data Sources

Expected User Experience

Activity

evergood2025 commented on Jun 6, 2025

evergood2025 commented on Jun 6, 2025

ryoppippi commented on Jun 6, 2025

ryoppippi commented on Jun 7, 2025

ryoppippi commented on Jun 7, 2025

yfzhou0904 commented on Jun 12, 2025

iamwrm commented on Jun 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions