OHarness : clé API et URL de base
Offre officielle — connectez-vous avec votre compte OHarness. Utilisez votre propre clé ; nous ne facturons rien.
Ce que le harnais connaît déjà
| Identifiant du fournisseur | official |
| URL de base | https://api.oharness.ai/api/v1 |
| Protocole | Chat completions compatible OpenAI |
| Clé API | OHARNESS_API_KEY |
| Découverte des modèles | Oui — la liste des modèles est demandée à l'endpoint plutôt que livrée avec le harnais. |
Le connecter
L'endpoint ci-dessus est intégré : il n'y a rien à configurer. Placez la clé dans l'environnement et le fournisseur apparaît dans le sélecteur de modèles :
export OHARNESS_API_KEY="..."Bon à savoir
L'offre officielle : connectez-vous avec un compte OHarness, ou collez une clé oh- créée sur le site. L'utilisation est décomptée du solde du compte et les clés amont n'appartiennent jamais à l'abonné — la passerelle qui sert les modèles est un détail d'implémentation, modifiable via OHARNESS_BASE_URL. Cet hôte est notre passerelle de comptage, PAS la passerelle amont : elles exposent les mêmes chemins, on les confond donc facilement et l'erreur passe inaperçue — la liste des modèles est publique en amont et répond 200, et seule la première complétion revient avec invalid_api_key. Pas de docsUrl : on entre par la connexion, pas par une page de clés ; y renvoyer ferait faire un détour aux utilisateurs. Les deux lignes ci-dessus concernent la passerelle amont, pas un modèle : elle exige un Idempotency-Key sur chaque complétion et plafonne max_tokens à son propre GATEWAY_MAX_OUTPUT_TOKENS — 4096 par défaut, et rien dans /models ne mentionne l'un ou l'autre ; il faut donc les indiquer ici. Augmentez la valeur au même rythme que le déploiement, sinon une réponse plus courte sera le moindre des problèmes : au-delà de la limite, c'est une erreur 400, pas une troncature.
Le pointer ailleurs
Un hôte régional, une passerelle ou votre propre serveur. Les surcharges dans ~/.oharness/config.json s'appliquent champ par champ : changer d'endpoint n'oblige pas à redéclarer le reste du fournisseur. Voici le bloc complet, avec la valeur par défaut pour que la structure soit claire :
{
"providers": {
"official": {
"baseUrl": "https://api.oharness.ai/api/v1"
}
}
}Ce que vous obtenez dans tous les cas
La même boucle d'agent, les mêmes outils, les mêmes serveurs MCP et les mêmes règles de permission, quel que soit le fournisseur sous-jacent — et passer de l'un à l'autre en cours de session ne convertit rien, car l'historique n'est jamais stocké au format d'un fournisseur. Ce qu'est un harnais d'agent explique pourquoi c'est la partie difficile, et la référence des fournisseurs décrit le catalogue lui-même.