Configuration

Config files

BharatCode looks in two places and merges them. The global file lives in your XDG config directory; the project file sits in your repository root:

• ~/.config/bharatcode/config.json — global defaults, applied to every project on the machine.
• ./.bharatcode.json — project-local overrides, committed (or git-ignored) alongside your code.

The two are merged, and the project file wins. Keep your accounts, API key environment variables, and budget in the global file once; use the project file only for the few things that differ for a given repository — for example, forcing a local-only provider or a stricter permission mode.

An annotated config.json

Here is a complete global config with every major section: the providers array, the cost budget, and permissions. The comments below are explanatory — strict JSON does not allow comments, so strip the // notes before saving the file.

{  // Providers BharatCode can talk to. Each entry is independent — mix  // hosted open-weight endpoints, frontier APIs, and local runtimes.  "providers": [    {      "name": "deepseek",                  // your label for this provider      "type": "openai_compatible",         // anthropic | openai | openai_compatible | ollama | lmstudio      "base_url": "https://api.deepseek.com",      "api_key_env": "DEEPSEEK_API_KEY",   // key is read from this env var, never stored here      "models": ["..."]                    // model IDs this provider serves    },    {      "name": "moonshot",      "type": "openai_compatible",      "base_url": "https://api.moonshot.ai/v1",      "api_key_env": "MOONSHOT_API_KEY",      "models": ["..."]    },    {      "name": "groq",      "type": "openai_compatible",      "base_url": "https://api.groq.com/openai/v1",      "api_key_env": "GROQ_API_KEY",      "models": ["..."]    },    {      "name": "ollama",                    // fully local — nothing leaves the box      "type": "ollama",      "base_url": "http://localhost:11434",      "models": ["..."]    }  ],   // INR-aware cost ledger with a monthly budget gate. When the  // monthly spend reaches the limit, the budget gate stops further calls.  "budget": {    "monthly_limit_inr": 2000  },   // Permission defaults. Verbs: ask | allow | deny. Scopes that an  // approval can be remembered for: once | session | project | forever.  "permissions": {    "mode": "auto",                        // read-only | auto | full    "bash": "ask",    "edit": "allow"  }}

Providers

Each entry in the providers array is one endpoint BharatCode can route to. The fields are:

• name — your label for the provider, used when you switch models with /model or the models command.
• type — one of anthropic, openai, openai_compatible, ollama, or lmstudio. Most hosted open-weight endpoints speak the OpenAI wire format, so they use openai_compatible.
• base_url — the API endpoint to call. For local runtimes this points at your machine (for example http://localhost:11434 for Ollama).
• api_key_env — the name of the environment variable that holds the key (e.g. DEEPSEEK_API_KEY, MOONSHOT_API_KEY, GROQ_API_KEY). The key itself is read from the environment at runtime — it is never written into the config file. Local providers like Ollama and LM Studio need no key, so they omit this field.
• models — the model IDs this provider serves. Fill these with the identifiers your chosen provider publishes.

For the full list of supported providers, how open-weight endpoints are treated as first-class, and details on running fully local with Ollama and LM Studio, see Providers & Models.

Budget & the cost ledger

BharatCode keeps an INR-aware cost ledger and gates spend with a monthly budget. The budget block sets the monthly limit; once you reach it, the budget gate steps in. You can inspect current spend and the remaining allowance from the TUI with /budget, or from the command line:

$ bharatcode stats$ bharatcode budget

Permissions

The permissions block sets how BharatCode asks before it touches your machine. The overall mode is one of read-only, auto, or full. Individual actions resolve to a verb — ask, allow, or deny — and when BharatCode asks, you can remember your answer for a chosen scope: once, session, project, or forever.

You can change the mode mid-session with /permissions, and the --yolo flag (or the /yolo slash command) bypasses prompts entirely. The full model is covered on the Permissions page.

Project overrides

A project file only needs the keys it changes — it does not have to repeat your whole global config. A common pattern is a repo that must stay fully local and read-only:

{  "providers": [    {      "name": "ollama",      "type": "ollama",      "base_url": "http://localhost:11434",      "models": ["..."]    }  ],  "permissions": {    "mode": "read-only"  }}

Dropped into a repository root, this forces a local Ollama provider and a read-only permission mode for that project, while every other setting still comes from your global config.

The bharatcode config command

Use the config subcommand to inspect the configuration BharatCode has resolved — the effective result after the global file, the project file, and any active profile have been merged. It is the quickest way to confirm which providers are loaded and which settings are actually in effect before you start a session.

$ bharatcode config

Related commands round out provider setup: bharatcode models lists the models available from your configured providers, bharatcode update-providers refreshes provider data, and bharatcode doctor checks your environment for common problems. See the CLI Reference for the full list.

Where the data lives

BharatCode uses two directories under your home folder, each for a distinct purpose:

• ~/.config/bharatcode/ — your global configuration, including config.json.
• ~/.bharatcode/prompts/ — the custom prompt registry. Drop Markdown files here (*.md) to add your own /<name> slash commands, with {{input}} and {{var}} interpolation.

Project-level instructions are picked up separately: AGENTS.md / CLAUDE.md files in your repository are ingested into the system prompt, and the per-project ./.bharatcode.json sits in the repo root described above.