Esc to close · ⌘K / Ctrl-K opens search anywhere
Several models deliberate on your prompt in parallel; one synthesized answer comes back. Open-weight, transparent, and reproducible — the panel is built from open-weight models and published, so you can check our work. Run it onyour own provider keys or ours — BYOK on every variant.
Try the Sangam playgroundSee the code
One model id, OpenAI-compatible: bharatrouter/open-sangam — set it as themodel and you're done.
Sangam is a three-stage ensemble. Instead of betting your answer on a single model, it convenes a panel, then has a stronger model reconcile them — the way asangam is a confluence of rivers. The panel is open-weight, so every stage is transparent and reproducible.
Your prompt fans out to a published panel of open-weight models. Each answers independently — different training, different blind spots — at the same time. The Open-Sangam panel runs on BharatRouter credit out of the box; save your own provider keys (BYOK) and those are used instead.
A stronger "fuse with" model reads every panel answer and reconciles them — keeping the consensus, surfacing contradictions, and filling the blind spots no single model caught.
You get back a single reply in the usual chat.completion shape — no new response format to handle. usage is the sum of the panel + synthesizer completions, plus a br_sangam transparency block.
Transparent by construction: the panel is open-weight and published, so a result reproduces and you can audit which models shaped it. India residency is available when you need it viadata_policy: india_only. Sangam is a premium showcase route — roughly 4× the tokens of one model, plus the latency of the slowest panel member — so it's never a default; reach for it when an answer is worth a panel.
| Model id | Panel | Residency | Best for |
|---|---|---|---|
bharatrouter/open-sangam hero | open-weight panel GLM-5.3-Flash · Qwen3.6-35B-A3B · Kimi K2.6 — open-weight, on our credit or your keys | 🇮🇳 on request | open-weight, reproducible, BYOK-ready — the one to try first |
bharatrouter/sangam | full frontier gpt-5 · Gemini · Claude | 🌐 global | frontier panel — top quality ceiling |
sangam: { panel, synth } | your pick (2–6 models + a synthesizer) | depends on your models | custom ensembles — same field humans and agents send |
Same OpenAI-compatible call for all three. Build a custom panel interactively in theSangam playground, or send the sangam object on any request.
Your keys or ours. Open-Sangam's panel is served on BharatRouter credit, so it runs for a new org as-is; if you've saved provider keys (BYOK), those are used instead. The frontierbharatrouter/sangam panel (GPT, Gemini, Claude) needs your own keys for those providers.
A first-class option: add data_policy: india_only and every panel + synthesizer call routes only to India-resident infrastructure — DPDP-aligned by construction, end to end. The panel narrows rather than relocating: non-resident members are dropped, so Open-Sangam convenes its two Krutrim-hosted panelists and synthesizes onglm-5.3-flash (India-resident). It's a flag, not a different product: the samebharatrouter/open-sangam call, pinned to India when you want it.
Many consensus routers keep their panel a secret. We don't. TheOpen-Sangam roster is published, so anyone can reproduce a result and audit which models shaped it. Three open-weight panelists answer; one open-weight synthesizer reconciles. Every model in the loop is open-weight — transparent and reproducible end to end. India residency is available viadata_policy: india_only when you need it.
| Role | Model | Served via | Residency | Weights |
|---|---|---|---|---|
| Panelist | glm-5.3-flash | Krutrim | 🇮🇳 India-resident | open-weight |
| Panelist | qwen3.6-35b-a3b | Krutrim | 🇮🇳 India-resident | open-weight |
| Panelist | kimi-k2.6 | Fireworks · Moonshot | 🌐 global (dropped under india_only) | open-weight |
| Synthesizer | glm-5.3-flash | Krutrim | 🇮🇳 India-resident | open-weight |
Synthesizer is glm-5.3-flash onKrutrim — it answers as a panelist and then reconciles, which is why it appears twice above. Send sangam: { india_only: true } (ordata_policy: "india_only") to keep every call on India-resident hosts: the two Krutrim panelists stay, kimi-k2.6 is dropped, and the synthesis still happens in India. Because the roster is fixed and public, the same prompt convenes the same panel: reproducible by design.
Illustrative exampleRepresentative wording to show the panel→synthesizer flow — not a benchmark or a measured result.
Prompt
"A startup wants to fine-tune an open model on Indian-language customer chats but can't let the data leave India. What approach should they take, and what's the one risk they'll most likely overlook?"
The panel answers (in parallel):
glm-5.3-flash · KrutrimFine-tune in-region on Indian GPU capacity and keep the dataset in an India-resident store. Use LoRA so you ship a small adapter, not a full model copy. Watch out: many "managed" fine-tuning APIs egress data to a foreign region during training — read the data-flow, not just the marketing.
qwen3.6-35b-a3b · KrutrimSelf-host the base weights and train on your own infra so nothing leaves your VPC. Curate the chat data carefully — Indian-language transliteration and code-mixing wreck naive tokenization. The overlooked risk is PII in the training set: customer chats are full of phone numbers and addresses that the model can later regurgitate.
kimi-k2.6 · FireworksParameter-efficient fine-tuning (LoRA/QLoRA) on an India-resident open model is the pragmatic path; full fine-tunes are rarely worth the cost. Build an eval set of real support transcripts first. Easy to miss: DPDP consent — using customer chats for model training is a distinct purpose that may need fresh consent and retention limits.
The Sangam answer (synthesized byglm-5.3-flash):
Take a parameter-efficient fine-tune (LoRA/QLoRA) of an India-resident open model, trained entirely on infrastructure inside India — ideally self-hosted in your own VPC so the dataset never egresses; if you use a managed trainer, verify in writing that training runs in-region. Invest up front in data work: an eval set of real Indian customer transcripts, and tokenizer/handling for code-mixed and transliterated text.
The panel agreed on the technical shape but flagged two different "most likely overlooked" risks, and both matter: (1) PII leakage — customer chats carry phone numbers and addresses a fine-tuned model can memorize and later emit, so redact before training; and (2) DPDP consent — reusing support chats for training is a new purpose that may require fresh consent and a retention limit. Residency alone doesn't make the project compliant; redaction plus a lawful basis do.
Why this is more than any one model: the synthesizer kept the shared technical answer but merged the panel's divergent risk calls instead of dropping one — the failure mode of trusting a single model.
Illustrative wording only. Real per-model outputs vary; nothing here is a measured score.
We won't quote numbers we haven't measured. Per-ensemble latency and quality for Open-Sangam are coming through BharatRouter's independentdeclared-vs-tested benchmark harness — the same one we use across the catalog to publish what a provider declares next to what we actuallymeasure, averaged over real calls.
Until those land, treat the example above as illustrative and the panel roster as the fact you can rely on. When measured figures are live, they'll appear here — the model id to call is bharatrouter/open-sangam (listed in /v1/models).
Sangam is just a model id. Point any OpenAI-compatible client at BharatRouter and setmodel="bharatrouter/open-sangam" — no SDK, no new endpoint, no special response parsing.
curl
curl https://api.bharatrouter.com/v1/chat/completions \
-H "Authorization: Bearer br-..." \
-H "Content-Type: application/json" \
-d '{
"model": "bharatrouter/open-sangam",
"messages": [
{"role": "user", "content": "How should an Indian startup keep fine-tuning data in-country?"}
]
}'Python — OpenAI SDK
from openai import OpenAI
client = OpenAI(
base_url="https://api.bharatrouter.com/v1",
api_key="br-...",
)
resp = client.chat.completions.create(
model="bharatrouter/open-sangam",
messages=[
{"role": "user",
"content": "How should an Indian startup keep fine-tuning data in-country?"},
],
)
print(resp.choices[0].message.content)
# panel + synthesizer transparency:
print(resp.br_sangam)The transparency block — every response carries a br_sangam field showing exactly who answered:
"br_sangam": {
"panel": [
{"model": "glm-5.3-flash", "provider": "krutrim", "ok": true, "ms": 1840},
{"model": "qwen3.6-35b-a3b", "provider": "krutrim", "ok": true, "ms": 1120},
{"model": "kimi-k2.6", "provider": "fireworks", "ok": true, "ms": 2310}
],
"verifier": {"model": "qwen3.6-35b-a3b", "provider": "krutrim", "ok": true, "ms": 900},
"synthesizer": {"model": "glm-5.3-flash", "provider": "krutrim", "ms": 640}
}Agents too — same surface.Open-Sangam is a first-class model: it shows up in GET /v1/models and is callable through the MCP chat tool exactly like any other model. Whatever a human can do in code, an agent can do over MCP — human + agent parity, no special path.
Pricing: Sangam is priced as the sum of the panel + synthesizer completionsat each model's listed rate — on your credit, or at your provider's rate when your own keys (BYOK) serve it. Expect roughly 4× the tokens of a single model and the latency of the slowest panel member — use it for answers worth a panel, not as a default route.