Sangam — consensus routing

Sangam (संगम — confluence) sends one prompt to a panel of models that answer in parallel, then a synthesizer model reconciles their answers into a single reply. You call it like any other model — one request, one response in the standard OpenAI chat.completion shape — and you get the judgement of several models instead of one. The hero variant,bharatrouter/open-sangam, runs an all-open-weightpanel: a second opinion you can read end to end, built on transparent, reproducible models rather than a single closed one. It runs on your own provider keys (BYOK) (see BYOK), and India residency is available as a feature when you want it (data_policy: india_only).

Sangam is free during the BYOK beta — BharatRouter charges nothing on top while the platform is in beta. It is a showcase/premium path, not a low-latency one (seecost & latency).

When to reach for Sangam

Consensus buys you robustness at the cost of tokens and latency. That trade is worth it on hard problems and wrong on easy ones.

• Reach for it on questions where one model isn't enough — ambiguous or high-stakes reasoning, tricky analysis, drafting where you want a model to cross-check another's blind spots, or evaluations where a single answer feels like a coin-flip. Multiple independent answers, reconciled, beat any single one.
• Don't reach for it on latency-sensitive paths (interactive chat, autocomplete, anything user-facing in real time) or simple, cheap calls (classification, extraction, short summaries). There a single model onnormal routing is faster and cheaper, and consensus adds nothing.

The three-stage flow

Every Sangam request runs the same three stages internally — the caller sees only stage 3.

1. Panel (parallel). Your prompt fans out to 2–6 panel models at once, each on its own route. They run concurrently, so wall-clock time is bounded by the slowest panel member, not the sum.
2. Synthesizer. The panel's answers are handed to one synthesizer model, which reconciles them — resolving disagreements, dropping outliers, merging the strong parts — into a single coherent answer.
3. One answer. You get back exactly onechat.completion: choices[0].message.content is the synthesized reply. usage is the sum of every panel completion plus the synth completion. A br_sangam block makes the whole panel transparent.

The transparency block tells you exactly which models ran, where, and how they fared — nothing is hidden behind the single answer:

"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": 1210 },
    { "model": "qwen2.5-vl-7b-instruct", "provider": "bharatrouter", "ok": false, "ms": 0    }
  ],
  "synthesizer": { "model": "llama-3.1-8b-instruct", "provider": "bharatrouter", "ms": 2960 }
}

Each panel entry reports its model, the provider route it ran on, whether it answered (ok), and its latency in ms. A panel member that fails (ok: false) is simply dropped from the synthesis — the answer still lands as long as enough of the panel succeeds.

The two published variants

Two Sangam model ids ship in the catalog. Use open-sangamunless you specifically want frontier models in the panel.

First-party: the open panel runs on BharatRouter's own A40 node — qwen2.5-7b-instruct and qwen2.5-vl-7b-instruct alongside llama-3.1-8b-instruct, which also synthesizes; cloud routes stay as failover.

Quickstart

Sangam is an ordinary model id on the standard endpoint — no special parameters needed for the published variants. Point the OpenAI SDK at BharatRouter and callbharatrouter/open-sangam.

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": "Our supplier missed an SLA. Walk through whether we can terminate, and the risks."}
    ]
  }'

Python (OpenAI SDK)

from openai import OpenAI
client = OpenAI(base_url="https://api.bharatrouter.com/v1", api_key="br-...")

r = client.chat.completions.create(
    model="bharatrouter/open-sangam",
    messages=[
        {"role": "user",
         "content": "Our supplier missed an SLA. Walk through whether we can terminate, and the risks."},
    ],
)

print(r.choices[0].message.content)        # the synthesized answer
print(r.usage.total_tokens)                 # panel + synth, summed
print(r.model_extra["br_sangam"]["panel"])  # who ran, where, how fast

Custom panels

Beyond the two published variants you can assemble your own panel on a single request by sending a sangam object — choose which models debate and which one reconciles. This is a BharatRouter extension: the gateway consumes it and never forwards it upstream.

• panel — an array of 2 to 6 ids: each is a catalog model idor a Sangam alias (which runs as a nested consensus — see below). Fewer than 2 isn't consensus; more than 6 just burns tokens.
• synth — one catalog model id (or a Sangam alias) that reconciles the panel's answers.
• rounds — optional integer 1–4; opt a panel into recursive deliberation (the verifier can send the panel back for another round).
• exclude — optional array of model ids and/or provider ids to drop forcompliance (see below).

Agent-exclusion (compliance)

For residency or vendor-compliance rules, sangam.exclude lets you say"run Sangam, but never touch provider X or model Y." A panel member is dropped if its model id is listed, or if every route it has is on an excluded provider; surviving members are also routed around the excluded providers, so a member can't quietly fail over onto one. The synthesizer and verifier fall back to a surviving member if excluded. If nothing survives, the request returns a clear error rather than a silent answer. Whatever was dropped is reported back in br_sangam.excluded — an auditable record of what was kept out.

curl https://api.bharatrouter.com/v1/chat/completions \
  -H "Authorization: Bearer br-..." -H "Content-Type: application/json" \
  -d '{
    "model": "bharatrouter/glm-sangam",
    "sangam": { "exclude": ["openai", "anthropic"] },
    "messages": [{"role": "user", "content": "Draft a data-processing addendum."}]
  }'

Recursive consensus (consensus-of-consensus)

A panel member — or the synthesizer — can itself be a Sangam alias. When it is, that member runs as its own full consensus (panel + verifier + synthesizer) and contributes a single reconciled answer back to the outer panel. This lets a strong, deliberated sub-answer sit alongside ordinary single models in the outer debate. In the response, that member showsprovider: "sangam" in br_sangam.panel.

Recursion is bounded to one nesting level: a nested Sangam's own members run as plain models, so fan-out can't blow up. It only happens when you explicitly name a Sangam alias — the published variants never nest. Note the cost: a nested member multiplies the sub-calls for that slot, so reach for it deliberately.

curl https://api.bharatrouter.com/v1/chat/completions \
  -H "Authorization: Bearer br-..." -H "Content-Type: application/json" \
  -d '{
    "model": "bharatrouter/sangam",
    "sangam": { "panel": ["bharatrouter/open-sangam", "gpt-5", "gemini-2.5-pro"] },
    "messages": [{"role": "user", "content": "Stress-test this proof for gaps."}]
  }'

The object is validated server-side. A panel that's too small or too large, or any id that is neither a catalog model nor a Sangam alias, fails the whole request with400 bad_sangam before any model is dialed — you never pay for a malformed panel. When a sangam object is present it defines the panel; the base modelfield can be any Sangam id and is overridden by the object.

curl

curl https://api.bharatrouter.com/v1/chat/completions \
  -H "Authorization: Bearer br-..." -H "Content-Type: application/json" \
  -d '{
    "model": "bharatrouter/open-sangam",
    "sangam": {
      "panel": ["gpt-oss-20b", "qwen3-32b", "gemma-4-e4b-it", "llama-3.1-8b-instruct"],
      "synth": "gpt-oss-120b"
    },
    "messages": [{"role": "user", "content": "Is this clause enforceable under Indian contract law?"}]
  }'

Python (OpenAI SDK)

r = client.chat.completions.create(
    model="bharatrouter/open-sangam",
    messages=[{"role": "user", "content": "Is this clause enforceable under Indian contract law?"}],
    extra_body={
        "sangam": {
            "panel": ["gpt-oss-20b", "qwen3-32b", "gemma-4-e4b-it", "llama-3.1-8b-instruct"],
            "synth": "gpt-oss-120b",
        }
    },
)

The exact same sangam object works in theplayground — build a panel visually, then copy the request.

Bring your own keys

Every Sangam variant works with BYOK. Each panel and synth sub-call honours your own provider keys exactly like a normal request: it is BYOK, so you bring a key for each panel model. If your org has a saved key for a panel member's provider, that sub-call uses it. Nothing about Sangam changes the key resolution — it's the same path as any other call on the gateway. The Open-Sangam panel is all open-weight and Groq-routable, so a single provider key (e.g. Groq) can cover the whole panel.

• Saved BYOK keys. Provider keys you've stored on the account apply to every panel and synth sub-call automatically — no per-request flag needed.
• Per-request upstream_key. Send an upstream_key on the request to override for that call; it's applied to the sub-calls just as it is on a single-model request.
• One key, whole panel. Because every Open-Sangam panel member is open-weight, one provider key that serves those open weights (e.g. Groq) covers the entire panel — you don't need a separate key per member.

Because resolution is per sub-call, one Sangam request can mix providers across the panel — say your own Krutrim key for the Krutrim-served leg and a Groq key for the open-weight members. See BYOK for how keys are stored and resolved.

Reading the response

A Sangam reply is a plain chat.completion. Three parts matter:

• choices[0].message.content — the single synthesized answer. This is the synthesizer's output, not any one panel member's.
• usage — the sum of all panel completions plus the synth completion (prompt_tokens, completion_tokens,total_tokens). This is what you're metered on, so it's higher than a single model call by design.
• br_sangam — the transparency block (above): apanel array of { model, provider, ok, ms } and asynthesizer of { model, provider, ms }. Read it to see exactly who contributed and whether any member dropped out.

Agents

Sangam ships with full human + agent parity. The published Sangam models are discoverable inGET /v1/models alongside every other catalog model, so an agent finds them by listing the catalog — no special-casing. Agents call Sangam through theMCP chat tool, and custom panels use theidentical sangam: { panel, synth } config object you'd send over REST. One config shape, two surfaces — human UI and agent API stay in lockstep.

Tool calls: a consensus panel can't arbitrate a tool loop, so a Sangam alias given tools or tool_choice delegates the whole request to a single tool-capable model through normal routing — streaming, failover and BYOK intact — rather than silently dropping your tools. The delegation is observable: thex-br-auto-delegate response header names the serving model. Chat without tools gets the consensus panel as usual.

Cost & latency

Be deliberate: a consensus call costs roughly (panel + 1)× the tokens of a single model call — every panel member plus the synthesizer — and its latency is bounded by theslowest panel model (panel runs in parallel) plus the synth step. That makes Sangam a showcase/premium path, not a low-latency one. open-sangam runs on your own keys (BYOK) — its panel is all open-weight, so the cost is your own open-weight provider rate; sangam's frontier panel is premium. During the BYOK beta, Sangam itself is free — BharatRouter charges nothing on top.

See also

• Sangam overview — the concept, in plain language.
• Sangam playground — build and run a panel in the browser.
• Routing & data residency — how each panel member's route is chosen.