Roster pour OpenRouter
Routez Roster via une passerelle de modèle unifiée.
Utilisez OpenRouter — ou une autre passerelle compatible OpenAI validée — pour centraliser l'accès aux modèles, le routage, les budgets, le choix du fournisseur et les règles de gouvernance appliquées au modèle de résolution de Roster.
Roster traite OpenRouter comme une configuration de passerelle, pas comme une famille distincte de fournisseur de modèless en accès direct.
Dernière vérification : 13 juillet 2026
Centralisez l'accès aux modèles sans changer le modèle de participants de Roster
Roster continue de gouverner :
“Qui doit réviser cette dérogation contractuelle pour le projet Atlas en Europe ?”
OpenRouter s'intercale entre Roster et le fournisseur de modèles sous-jacent sélectionné. Cela apporte de la flexibilité, mais aussi une couche supplémentaire de comportement API, de routage, de politique de confidentialité, de limites et de gestion des erreurs à valider.
- Projets
- Participants
- Contexte annuaire
- Appartenances
- Métadonnées
- Délégations
- Périmètres d'accès
- Historique de résolution
Roster reste la couche de résolution des participants et de gouvernance quel que soit le modèle ou fournisseur vers lequel la passerelle route.
Comment l'intégration fonctionne
Roster atteint OpenRouter via une interface compatible OpenAI, qui route vers le modèle sous-jacent sélectionné.
Agent, workflow ou application
↓
Roster Resolve
↓
Contexte participant autorisé
↓
OpenRouter
↓
Modèle OpenAI, Anthropic, Mistral
ou autre modèle hébergé sur la passerelle
↓
Sélection de participant structurée
↓
Validation et expansion RosterPourquoi utiliser une passerelle de modèle ?
Configurer OpenRouter
Gardez ROSTER_MODEL_PROVIDER=openai car Roster atteint OpenRouter via une interface compatible OpenAI.
Pour un modèle OpenAI pris en charge via l'API Responses :
OPENAI_API_KEY=<clé-api-openrouter>
OPENAI_BASE_URL=https://openrouter.ai/api/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_NAME=openai/gpt-5.4-mini
ROSTER_MODEL_EFFORT=lowQuand ROSTER_MODEL_API est omis pour la famille de fournisseur openai, Roster utilise responses par défaut.
Pour de nombreux modèles non-OpenAI, Chat Completions est un point de départ plus adapté car le support de l'API Responses varie par modèle :
OPENAI_API_KEY=<clé-api-openrouter>
OPENAI_BASE_URL=https://openrouter.ai/api/v1
ROSTER_MODEL_PROVIDER=openai
ROSTER_MODEL_API=chat-completions
ROSTER_MODEL_NAME=anthropic/claude-opus-4.8L'utilisation de ROSTER_MODEL_PROVIDER=openai décrit la famille d'API compatible utilisée par Roster. Cela ne signifie pas que le modèle sous-jacent est nécessairement opéré par OpenAI.
Limite de sortie API Responses — lorsque OPENAI_BASE_URL est configuré, Roster fixe par défaut le plafond de sortie OpenAI Responses à :
ROSTER_MODEL_OPENAI_RESPONSES_MAX_OUTPUT_TOKENS=2048Ne le remplacez que si la passerelle, le modèle ou les limites de compte le requièrent. Testez la réponse Resolve complète, pas seulement le succès HTTP.
Combinaisons modèle/API OpenRouter actuellement validées :
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/aTraitez-les comme des candidats validés, pas comme une garantie permanente. Identifiants de modèles validés, disponibilité, fournisseurs de routage, API et comportement sous-jacent peuvent changer. Revalidez avant de publier une recommandation de production.
Exemple de résolution via passerelle
Un workflow legal-operations demande :
“Qui doit réviser cette dérogation contractuelle pour le projet Atlas en Europe ?”
- Roster constitue le contexte participant autorisé.
- Roster appelle le point d'accès OpenRouter configuré.
- OpenRouter route la requête vers la combinaison modèle/fournisseur sélectionnée.
- Le modèle renvoie une sélection de participant structurée.
- Roster valide la sélection et identifie les utilisateurs ou délégués courants.
- Roster enregistre son exécution de modèle et sa requête Resolve.
L'activité de la passerelle et celle de Roster peuvent avoir des IDs de requête et des systèmes d'observabilité distincts. Préservez les deux lors de l'investigation d'un incident en production.
La compatibilité comporte plusieurs couches
Un modèle de passerelle peut passer un test API simple et échouer comme moteur de résolution de Roster. Validez la compatibilité du point d'accès, la compatibilité API (Responses vs Chat Completions), la compatibilité de sortie structurée, la compatibilité du contrôle de raisonnement (la passerelle transmet-elle, traduit-elle, ignore-t-elle ou rejette-t-elle le réglage effort de Roster), la compatibilité des limites de sortie, la qualité Resolve sur des données organisationnelles représentatives et la compatibilité opérationnelle (latence, limites, disponibilité, coût, erreurs).
Le routage fournisseur est important. OpenRouter peut disposer de plusieurs fournisseurs d'inférence pour un modèle et router entre eux selon sa configuration et sa logique de disponibilité. Deux requêtes utilisant le même slug de modèle peuvent impliquer des fournisseurs sous-jacents différents à moins que le routage ne soit contraint. Évaluez si vous avez besoin d'un fournisseur préféré, de listes d'autorisation ou d'exclusions, d'un routage de repli, d'un routage régional, de points ZDR uniquement, de versions de modèle fixes, de garde-fous d'accès modèle ou de limites de dépense propres à une clé.
Le traitement des données requiert deux revues — la passerelle et le fournisseur d'inférence sous-jacent. Examinez la journalisation des métadonnées de la passerelle, la journalisation optionnelle des prompts et complétions, la rétention fournisseur, les politiques d'entraînement fournisseur, le routage ZDR, le traitement régional, les politiques de fournisseur de repli et la journalisation des erreurs. OpenRouter documente des contrôles compte et requête pour restreindre le routage aux fournisseurs qui respectent des politiques spécifiées. Configurez et vérifiez ces politiques indépendamment de Roster.