Use the Claude API with LiteLLM

Point litellm.completion() at the discounted endpoint

LiteLLM already implements the Anthropic Messages API, so routing Claude through apiToken.sale takes a single extra argument: keep the anthropic/ model prefix, set api_base to the gateway and pass your prepaid key. Requests and responses keep the standard Anthropic shape — only the endpoint and the per-token price change, with Claude spend at a flat 50% below list.

import litellm

response = litellm.completion(
    model="anthropic/claude-opus-4-8",
    api_base="https://router.apitoken.sale",
    api_key="sk-pool-•••",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
    stream=True,
)
for chunk in response:
    print(chunk.choices[0].delta.content or "", end="")

Three things do the work here. The anthropic/ prefix selects LiteLLM's Anthropic provider, so max_tokens, temperature, tools and streaming map onto the Messages API exactly as they do upstream — and max_tokens is required by that API, so set it explicitly rather than relying on defaults. api_base overrides where those requests go, per call. And api_key is your gateway key: the same sk-pool-… key works for every supported Claude model, so moving between claude-opus-4-8, claude-sonnet-5 and claude-haiku-4-5 is a string change, not a new integration.

Two pitfalls bite in practice. Never strip the anthropic/ prefix: a bare claude-opus-4-8 makes LiteLLM guess the provider, and a wrong guess sends the wrong protocol or rejects the key. And read the key from the environment (api_key=os.environ["APITOKEN_KEY"]) instead of pasting it into notebooks or configs that end up in git.

See also: Use the Claude API with LangChain

One LiteLLM proxy for every service that needs Claude

Direct calls are fine for a single script. Once several services, notebooks and coding agents need Claude, run LiteLLM as a proxy: one YAML file holds the endpoint and the key, every client talks to the proxy over LiteLLM's OpenAI-compatible surface, and upstream traffic stays on the Anthropic protocol.

# config.yaml
model_list:
  - model_name: claude-opus-4-8
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_base: https://router.apitoken.sale
      api_key: sk-pool-•••
  - model_name: claude-haiku-4-5
    litellm_params:
      model: anthropic/claude-haiku-4-5
      api_base: https://router.apitoken.sale
      api_key: sk-pool-•••
router_settings:
  fallbacks:
    - claude-opus-4-8:
        - claude-haiku-4-5

1. 01Install the proxy extra and save the YAML above as config.yaml: pip install "litellm[proxy]".
2. 02Start the gateway: litellm --config config.yaml --port 4000.
3. 03Point any OpenAI-compatible client at http://localhost:4000 with model="claude-opus-4-8" — the proxy translates the call into an Anthropic Messages request to https://router.apitoken.sale.
4. 04Track spend in the apiToken.sale dashboard: usage is recorded per key with token-level detail, so one proxy key gives you one cost line for every service behind it.

The router_settings block earns its two lines: if claude-opus-4-8 errors or is unavailable, LiteLLM retries the request against claude-haiku-4-5 instead of surfacing a failure to the client. For long-running agents that hold a session open for hours, that fallback is the difference between a silent retry and a dead process.

Streaming, tool use and prompt caching survive the switch

The features that usually break behind a translation layer keep working here, because the gateway serves the native Anthropic Messages API rather than re-encoding your traffic into a different protocol. Anything LiteLLM knows how to express in Anthropic terms arrives at the model unchanged.

• Streaming: stream=True yields the same incremental server-sent events, so token-by-token UIs and agents behave identically.
• Tool use: tools, tool_choice and the tool_result round-trip map onto the standard Messages blocks — function-calling agents need no rework.
• Prompt caching: cache_control breakpoints work as documented upstream, and cached reads are billed at the cache rates listed on the model pages.

This matters most for tools built on top of LiteLLM rather than for LiteLLM itself: many coding agents and frameworks route their Anthropic traffic through it, and they inherit the discounted endpoint from the same configuration without code changes of their own.

Mix GPT, Gemini and Kimi into the same model_list

The gateway key is multi-provider, so the proxy you just configured is not Claude-only. Add one entry per provider lane and every model draws from the same prepaid balance — no second account, no second key to rotate.

# additional model_list entries
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra        # OpenAI-compatible lane
      api_base: https://router.apitoken.sale/v1
      api_key: sk-pool-•••
  - model_name: gemini-3.6-flash
    litellm_params:
      model: gemini/gemini-3.6-flash     # native Gemini lane
      api_base: https://router.apitoken.sale
      api_key: sk-pool-•••

Kimi models ride the same two lanes — Anthropic Messages or the universal OpenAI-compatible endpoint — so a single LiteLLM deployment can front supported Claude, GPT, Gemini and Kimi models at once. Each provider keeps the protocol LiteLLM already speaks for it; only the base URL and key point somewhere new.

What changes when you switch — and what stays identical

Switching endpoints is deliberately boring, and it is worth being precise about which parts of the stack notice and which do not.

Budget the traffic before you scale it

Billing is prepaid: you top up a balance and every request deducts its exact token cost, Claude models at the discounted rate. There is no monthly commitment to size upfront, which makes LiteLLM's per-model cost tracking a nice-to-have rather than a survival tool — the authoritative numbers live in the apiToken.sale dashboard, broken down per key with token-level detail.

Before pointing a whole fleet at the proxy, run a representative day of traffic through one key and read the actual consumption off the dashboard; extrapolate from real tokens, not from list-price arithmetic. The cost calculator linked below does the same math in advance if you know your rough request mix.

Per-model prices, including cache rates →

Estimate your LiteLLM traffic cost in the free calculator →

Frequently asked questions

Related guides