Providers & Models

How providers work

BharatCode has no hardcoded list of vendors baked into the binary. Instead, every model source is described by a provider entry in your config file. Each entry has five fields:

• name — a label you choose. It is how you refer to the provider in /model and in bharatcode models.
• type — the wire protocol BharatCode uses to talk to the endpoint. One of anthropic, openai, openai_compatible, gemini, codex_oauth, ollama, or lmstudio.
• base_url — the HTTP endpoint. This is what lets you pin a provider to an India-hosted gateway or a machine on your own network.
• api_key_env — the name of the environment variable BharatCode reads the API key from. The key itself never lives in the config file. Local runtimes need no key.
• models — the list of model IDs this provider serves. These are the entries you pick from when you switch models.

Because the shape is the same for every vendor, adding a new provider — or repointing an existing one at a different region — is just editing JSON. Nothing about the protocol leaks into the rest of the agent.

Provider types

The type field selects how BharatCode formats requests and parses responses. Pick the one that matches the API your endpoint speaks:

• anthropic — the native Anthropic Messages API (Claude models).
• openai — the native OpenAI API (GPT models).
• openai_compatible — any endpoint that speaks the OpenAI Chat Completions protocol. This is the workhorse type: most open-weight gateways (DeepSeek, Moonshot/Kimi, z.ai, Mistral, Groq, Cerebras, Together, Fireworks, DeepInfra, Nebius, Novita, OpenRouter), India-built providers (Sarvam, Krutrim), xAI/Grok, Cohere, Perplexity, and most self-hosted servers all expose one, so you reach them by setting base_url and api_key_env.
• gemini — Google's native Generative Language API (Gemini 2.5 Pro / Flash). There is also an OpenAI-compatible Gemini shim if you prefer that path.
• codex_oauth — experimental: reuse your ChatGPT subscription via the Codex sign-in instead of a metered API key. No api_key_env; authenticate with bharatcode login.
• ollama — a local Ollama server. Runs models on your own machine; no API key.
• lmstudio — a local LM Studio server. Also fully on-device; no API key.

Supported providers

These 20+ providers ship in BharatCode's defaults, ordered the way we think about sovereignty: fully local first, then India-built models, then open-weight gateways, then frontier closed models. Open-weight and in-country options come first by design — they are typically far cheaper than closed models, and you can run them on your own hardware or pin them to an Indian endpoint. You can edit, remove, or add to any of them.

• Local — runs fully on your machine. Source code never leaves the device.
• India-built — sovereign, in-country inference (Sarvam, Krutrim).
• Open-weight — serves open-weight model families. No vendor lock-in.

Configuring a provider

Providers live under a providers array in your config. The global file is ~/.config/bharatcode/config.json; a project file at ./.bharatcode.json is merged on top for repo-specific overrides. Here is a hosted open-weight provider — DeepSeek, reached over its OpenAI-compatible endpoint:

{  "providers": [    {      "name": "deepseek",      "type": "openai_compatible",      "base_url": "https://api.deepseek.com/v1",      "api_key_env": "DEEPSEEK_API_KEY",      "models": ["deepseek-chat", "deepseek-reasoner"]    }  ]}

The key never goes in the file — BharatCode reads it from the environment variable named in api_key_env. Export it in your shell (or your secrets manager):

$ export DEEPSEEK_API_KEY="sk-..."

Local providers (data stays on device)

Local runtimes are the strongest privacy posture: the model runs on your own machine, so your source code never leaves it. A local provider needs no API key — only a base_url pointing at the local server. Ollama and LM Studio both work this way:

{  "providers": [    {      "name": "ollama-local",      "type": "ollama",      "base_url": "http://localhost:11434",      "models": ["qwen2.5-coder", "deepseek-coder-v2"]    },    {      "name": "lmstudio-local",      "type": "lmstudio",      "base_url": "http://localhost:1234/v1",      "models": ["your-loaded-model"]    }  ]}

India-built providers (sovereign by default)

When you can't run locally but still need to keep inference in-country, reach for an India-built provider. Sarvam and Krutrim both speak the OpenAI-compatible protocol, so they are ordinary provider entries with an Indian base_url:

{  "providers": [    {      "name": "sarvam",      "type": "openai_compatible",      "base_url": "https://api.sarvam.ai/v1",      "api_key_env": "SARVAM_API_KEY",      "models": ["sarvam-m"]    },    {      "name": "krutrim",      "type": "openai_compatible",      "base_url": "https://cloud.olakrutrim.com/v1",      "api_key_env": "KRUTRIM_API_KEY",      "models": ["Krutrim-spectre-v2"]    }  ]}

Native Gemini & ChatGPT sign-in

Two provider types skip the OpenAI-compatible path. The gemini type talks to Google's native Generative Language API, and codex_oauth (experimental) reuses your ChatGPT subscription instead of a metered key — so it carries no api_key_env and is authenticated with bharatcode login:

{  "providers": [    {      "name": "gemini",      "type": "gemini",      "api_key_env": "GEMINI_API_KEY",      "models": ["gemini-2.5-pro", "gemini-2.5-flash"]    },    {      "name": "codex",      "type": "codex_oauth",      "models": ["gpt-5.5"]    }  ]}

Adding a custom OpenAI-compatible endpoint

Because openai_compatible is just “speaks the OpenAI Chat Completions protocol,” you can point BharatCode at any gateway that follows it — including an India-hosted inference endpoint, a regional proxy, or a self-hosted vLLM / TGI server. Set the base_url to that endpoint and name an env var for its key:

{  "providers": [    {      "name": "india-gateway",      "type": "openai_compatible",      "base_url": "https://llm.example.in/v1",      "api_key_env": "INDIA_GATEWAY_API_KEY",      "models": ["kimi-k2", "qwen2.5-coder-32b"]    }  ]}

$ export INDIA_GATEWAY_API_KEY="..."

Listing & updating providers

Once a provider is configured, list every model BharatCode can currently reach — grouped by provider — with:

$ bharatcode models

Inside the TUI, /model opens the same picker so you can switch the active model mid-session. To refresh provider definitions, run:

$ bharatcode update-providers

For providers that use a sign-in flow rather than a raw key, manage credentials with bharatcode login and bharatcode logout. See the full CLI reference for every subcommand.

Data stays in India

Providers are the mechanism behind BharatCode's core promise: your code only goes where you send it. BharatCode never phones home — it connects solely to the endpoints in your config. That gives you two ways to keep data in the country:

• Run fully local. With an ollama or lmstudio provider, inference happens on your own machine and your source never touches the network. Ideal for air-gapped or highly sensitive work.
• Pin to an India-hosted endpoint. Point an openai_compatible provider's base_url at an in-country gateway so hosted inference stays within India's borders.

Open-weight models make both routes practical: the same model families are available locally, through regional gateways, and from global hosts, so you can choose the posture each project needs without changing how you work.