Roster for OpenRouter
Route Roster through a unified model gateway.
Use OpenRouter — or another validated OpenAI-compatible gateway — to centralize model access, routing, budgets, provider selection, and policy controls for Roster's resolver.
Roster treats OpenRouter as a gateway configuration, not as a separate direct model-provider family.
Last verified 07/13/2026
Centralize model access without changing Roster's participant model
Roster continues to govern:
“Who should review this contract exception for the Atlas project in Europe?”
OpenRouter sits between Roster and the selected underlying model provider. This adds flexibility, but also introduces another layer of API behavior, routing, privacy policy, limits, and failure handling that must be validated.
- Projects
- Participants
- Directory context
- Memberships
- Metadata
- Delegations
- Access boundaries
- Resolution history
Roster remains the participant-resolution and governance layer regardless of which model or provider the gateway routes to.
How the integration works
Roster reaches OpenRouter through an OpenAI-compatible interface, which routes to the selected underlying model.
Agent, workflow, or application
↓
Roster Resolve
↓
Authorized participant context
↓
OpenRouter
↓
Selected OpenAI, Anthropic, Mistral,
or other gateway-hosted model
↓
Structured participant selection
↓
Roster validation and expansionWhy use a model gateway?
Configure OpenRouter
Keep ROSTER_MODEL_PROVIDER=openai because Roster reaches OpenRouter through an OpenAI-compatible interface.
For a supported OpenAI model through the Responses API:
OPENAI_API_KEY=<openrouter-api-key>
OPENAI_BASE_URL=https://openrouter.ai/api/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_NAME=openai/gpt-5.4-mini
ROSTER_MODEL_EFFORT=lowWhen ROSTER_MODEL_API is omitted for the openai provider family, Roster defaults to responses.
For many non-OpenAI models, Chat Completions is the more appropriate starting point because gateway support for the Responses API varies by model:
OPENAI_API_KEY=<openrouter-api-key>
OPENAI_BASE_URL=https://openrouter.ai/api/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_API=chat-completions
ROSTER_MODEL_NAME=anthropic/claude-opus-4.8The use of ROSTER_MODEL_PROVIDER=openai describes the compatible API family used by Roster. It does not mean that the underlying model is necessarily operated by OpenAI.
Responses API output limit — when OPENAI_BASE_URL is configured, Roster defaults the OpenAI Responses output cap to:
ROSTER_MODEL_OPENAI_RESPONSES_MAX_OUTPUT_TOKENS=2048Override this only when required by the selected gateway, model, or account limits. Test the complete Resolve response rather than checking only for HTTP success.
Currently validated OpenRouter model/API combinations:
openai/gpt-5.5 Responses low
openai/gpt-5.4 Responses low
openai/gpt-5.4-mini Responses low
anthropic/claude-opus-4.8 Chat Completions n/a
mistralai/mistral-large-2512 Chat Completions n/aTreat these as validated candidates, not a permanent guarantee. Model slugs, availability, routing providers, APIs, and underlying behavior can change. Revalidate before publishing a production recommendation.
Example gateway resolution
A legal-operations workflow asks:
“Who should review this contract exception for the Atlas project in Europe?”
- Roster builds the authorized participant context.
- Roster calls the configured OpenRouter endpoint.
- OpenRouter routes the request to the selected model/provider combination.
- The model returns a structured participant selection.
- Roster validates the selection and resolves current users or delegates.
- Roster records its model run and Resolve request.
Gateway activity and Roster activity may have separate request IDs and observability systems. Preserve both when investigating a production issue.
Compatibility has several layers
A gateway model can pass a simple API test and still fail as a Roster resolver. Validate endpoint compatibility, API compatibility (Responses vs Chat Completions), structured-output compatibility, reasoning-control compatibility (does the gateway pass, translate, ignore, or reject Roster's effort setting), output-limit compatibility, Resolve quality on representative organizational data, and operational compatibility (latency, limits, availability, cost, errors).
Provider routing matters. OpenRouter may have multiple inference providers available for a model and can route between them according to its configuration and availability logic. Two requests using the same model slug may involve different underlying providers unless routing is constrained. Evaluate whether you need a preferred provider, allowlists or exclusions, fallback routing, regional routing, Zero Data Retention-only endpoints, fixed model versions, model-access guardrails, or key-specific spending limits.
Data handling requires two reviews — the gateway and the underlying inference provider. Review gateway metadata logging, optional prompt and completion logging, provider retention, provider training policies, ZDR routing, regional processing, fallback-provider policies, and error logging. OpenRouter documents account and request controls for restricting routing to providers that meet specified retention or training policies. Configure and verify those policies independently from Roster.