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. Each call runs on your own provider keys (BYOK) — every panel member is open-weight, so one provider key (e.g. Groq) can cover the whole panel.
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 Qwen2.5 · Llama 3.1 · Qwen2.5-VL — open-weight (run on your own 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.
Bring your own keys. Every variant is BYOK: you bring a key for each panel model. The Open-Sangam panel is all open-weight and Groq-routable, so a single provider key (e.g. Groq) can cover the whole panel.
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. It's a flag, not a different product: the same bharatrouter/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 | qwen2.5-7b-instruct | BharatRouter · A40 | 🇮🇳 India-resident | open-weight |
| Panelist | llama-3.1-8b-instruct | BharatRouter · A40 | 🇮🇳 India-resident | open-weight |
| Panelist | qwen2.5-vl-7b-instruct | BharatRouter · A40 | 🇮🇳 India-resident | open-weight |
| Synthesizer | llama-3.1-8b-instruct | BharatRouter · A40 | 🇮🇳 India-resident | open-weight |
Synthesizer is llama-3.1-8b-instruct via BharatRouter's A40 node — an open-weight panel model doing the reconciliation. 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):
qwen2.5-7b-instruct · BharatRouter · A40Fine-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.
llama-3.1-8b-instruct · BharatRouter · A40Self-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.
qwen2.5-vl-7b-instruct · BharatRouter · A40Parameter-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 byllama-3.1-8b-instruct):
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": "qwen2.5-7b-instruct", "provider": "bharatrouter", "ok": true, "ms": 1840},
{"model": "llama-3.1-8b-instruct", "provider": "bharatrouter", "ok": true, "ms": 1120},
{"model": "qwen2.5-vl-7b-instruct", "provider": "bharatrouter", "ok": true, "ms": 2310}
],
"synthesizer": {"model": "llama-3.1-8b-instruct", "provider": "bharatrouter", "ms": 2640}
}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 completions— and because Open-Sangam's panel is all open-weight, you run it on your own provider keys (BYOK), so the panel cost is your own open-weight provider rate. It's free while the platform is in BYOK-beta. 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.