Connect → LiteLLM

Use AxForge with LiteLLM

LiteLLM is an open-source proxy. Put AxForge behind it to get one endpoint for many models, with budgets, keys and fallback — and to reach AxForge from tools that speak a different API shape.

config.yaml

model_list:
  - model_name: axforge-chat
    litellm_params:
      model: openai/chat                 # openai/ prefix = OpenAI-compatible upstream
      api_base: https://api.axforge.ai/v1  # MUST include /v1
      api_key: os.environ/AXFORGE_API_KEY
  - model_name: axforge-embed
    litellm_params:
      model: openai/embeddings
      api_base: https://api.axforge.ai/v1
      api_key: os.environ/AXFORGE_API_KEY

$ litellm --config config.yaml     # proxy on http://localhost:4000

Two easy mistakes. api_base must end in /v1 (omit it and you get a Not Found), and you should never append /chat/completions yourself — LiteLLM's OpenAI handler adds the path.

Three surfaces from one upstream

The proxy can re-expose AxForge on all three of the API shapes tools expect:

For the Responses bridge, add that flag to the model's litellm_params and use LiteLLM ≥ 1.63.8. You don't need this to reach AxForge from Codex or Claude Code — both are served natively — but it's handy if you already front everything with a gateway.

Pin a clean LiteLLM release. Avoid the PyPI builds 1.82.7 / 1.82.8, which were flagged upstream — install a known-good version.

Check that it worked

Two things, and the second is the one that proves it end to end:

1. curl http://localhost:4000/v1/models lists your AxForge model names.
2. A chat call through the proxy returns an answer with usage.
3. The call appears in the console at Billing & usage within a minute or two. Nothing else confirms that your key reached our API — a reply alone could be a cache or another provider.

When it does not work

Run the self-test first when you are unsure — it says in one click whether the problem is your key, your quota or us, so you know whether the tool is worth debugging at all.