Resource groups

Some models are served through more than one upstream vendor pool. Resource groups let an organization pin a request to a specific pool instead of the platform’s default routing.

Note

Resource groups are available to organizations that have been granted pool access. Without it, requests route through the default pool automatically — which is the right behaviour for almost everyone — and explicitly selecting another pool returns 403 Forbidden. Contact support@inferel.ai if you need it.

Available pools

Pool	What it routes to
standard	Default pool: the current production vendor mix.
bdrk	AWS Bedrock-backed capacity.
vertex	Google Vertex-backed capacity.

Pools currently apply to the Claude model family; other families always use default routing. Availability is configured per deployment and can change — the authoritative list for your organization comes from GET /v1/models?variants=all.

Selecting a pool

Append the pool to the model ID with a colon:

{
  "model": "claude-opus-4.8:bdrk",
  "messages": [{ "role": "user", "content": "..." }]
}

Pools are also addressable with a hyphen, for SDKs and frameworks that reject : in model IDs:

{ "model": "claude-opus-4.8-bdrk" }

Or send a header and leave the model field untouched — useful when the model name is fixed by a framework:

curl https://inference.inferel.ai/v1/chat/completions \
  -H "Authorization: Bearer $INFEREL_API_KEY" \
  -H "X-Resource-Group: bdrk" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-opus-4.8", "messages": [{"role": "user", "content": "Hi"}]}'

A suffix is only read as a pool when it matches a configured group and the remaining prefix is a real model, so ordinary model IDs containing : or - are never misparsed.

Listing pool variants

GET /v1/models returns base model IDs only. With pool access, ?variants=all adds one entry per pool that routes the model:

{
  "id": "claude-opus-4.8-bdrk",
  "name": "AWS Bedrock",
  "object": "model",
  "owned_by": "inference",
  "root": "claude-opus-4.8",
  "resource_group": "bdrk",
  "display_name": "AWS Bedrock",
  "description": "Bedrock-backed reseller capacity",
  "price_multiplier": 1,
  "default": false
}

How routing works inside a pool

Within the selected pool, requests are balanced across vendors by configured weight, scaled by live endpoint health, with KV-cache-aware stickiness for conversations that share a prefix. Saturated or unhealthy endpoints are skipped automatically, and a failed attempt fails over to another vendor in the pool.

Pricing

Each pool carries a price multiplier applied to the model’s base per-token rates; the multiplied rate is what your credit balance is debited, and it is reflected in the pricing block of that variant in GET /v1/models. All pools currently run at a 1× multiplier, so today pool choice affects routing, not price.