Skip to main content
If a provider ForceAI does not ship yet exposes an OpenAI-compatible API, adding it as a first-class option is a small, mechanical change: a config class, a handful of registry entries, cost-map rows, and a dashboard entry. After this, the provider appears in the Add Model dropdown and behaves like any built-in one. This guide uses the reference implementation added for the sakana provider
This is a developer task that ships in a build. Use it only when the upstream API is OpenAI compatible (an OpenAI-style /chat/completions). For a provider ForceAI already supports, no code is needed; see Onboard an existing provider

​
Backend (Python)

1

Provider config class

Create litellm/llms/<provider>/chat/transformation.py with a class extending OpenAILikeChatConfig. Override custom_llm_provider to return your slug, and _get_openai_compatible_provider_info to resolve the api base and key (with env fallbacks like <PROVIDER>_API_KEY / <PROVIDER>_API_BASE). The sakana version is about 25 lines
2

Register the provider enum

Add your slug to the LlmProviders enum in litellm/types/utils.py
3

Constants

In litellm/constants.py: add <PROVIDER>_API_BASE; add the slug to LITELLM_CHAT_PROVIDERS, to the OpenAI-compatible endpoints list (host like api.example.ai/v1, used for endpoint auto-detection), and to openai_compatible_providers
4

Package wiring

In litellm/__init__.py: declare <provider>_models: set; add a branch in the cost-map loop that puts models whose litellm_provider matches into that set; fold the set into the aggregate model set and the provider-to-models dict; import your config class
5

Lazy-import registry

In litellm/_lazy_imports_registry.py: add your config class name to the exported list and its module tuple
6

Provider routing

In litellm/litellm_core_utils/get_llm_provider_logic.py: add an endpoint auto-detect branch (map your host to the slug and read its env key) and a dispatch branch that resolves api base and key through your config class
7

Cost map

Add each model to model_prices_and_context_window.json (and the _backup.json) with "litellm_provider": "<slug>", a mode, token limits, and input/output cost. This is what makes cost tracking and the model list work
8

Provider metadata (drives the dashboard dropdown)

Add a block to litellm/proxy/public_endpoints/provider_create_fields.json: provider, provider_display_name, litellm_provider, the credential_fields (for example api_key required password and an optional api_base with a placeholder), and a default_model_placeholder. This is served by /public/providers/fields and is what makes the provider appear in Add Model

​
Dashboard (TypeScript)

1

Provider helpers

In ui/litellm-dashboard/src/components/provider_info_helpers.tsx: add the provider to the Providers enum, to provider_map (display key to slug), and to providerLogoMap (points at the logo asset). Optionally add a fallback in getProviderModels so the model dropdown is never empty before the cost map loads
2

Logo

Add ui/litellm-dashboard/public/assets/logos/<provider>.svg
3

Tests and generated types

Update provider_info_helpers.test.tsx. If you changed a backend route or response the dashboard consumes, run npm run gen:api and commit the regenerated src/lib/http/schema.d.ts (CI enforces this)

​
Checklist

​
After it ships

The new provider shows up in Models + Endpoints -> Add Model. From there, onboarding one of its models is the no-code flow in Onboard an existing provider. If the provider is not OpenAI compatible, it needs a dedicated transformation rather than extending OpenAILikeChatConfig, which is a larger effort than this guide covers