Protocoles fournisseurs et interfaces de modèles
Anyy v0.1.107 implémente cinq familles natives de conversation. Le comportement partagé suit Pi v1.2.0 figé, commit 06a466935536f8c9bcacb2d5efc0fc021be1bdff. Ce périmètre de protocoles/interfaces ne promet pas un test réel de chaque point fournisseur, compte ou authentification.
Protocoles de conversation
api_mode Anyy | API Pi correspondante | Famille de requêtes |
|---|---|---|
openai-compatible | openai-completions | Chat Completions de style OpenAI, services locaux compatibles compris |
openai-responses | openai-responses | OpenAI Responses |
codex-responses | openai-codex-responses | Responses d’abonnement Codex et comportement transport/session |
anthropic-messages | anthropic-messages | Anthropic Messages |
google-gemini | google-generative-ai | Gemini Generative AI |
Une marque peut proposer plusieurs contrats de points d’accès ; choisir la marque ne les rend pas interchangeables. Ollama et Ollama Cloud utilisent la famille compatible OpenAI existante. /api/tags d’Ollama ne sert qu’à découvrir les modèles.
Les cinq API Pi supplémentaires azure-openai-responses, bedrock-converse-stream, google-vertex, mistral-conversations et pi-messages n’ont ni implémentation native indépendante ni qualification dans cette version. Une passerelle compatible peut utiliser une des cinq familles si elle en implémente réellement le contrat, sans ajouter l’API native distincte du service. Les choix bloqués, dont Azure et Bedrock natifs, restent indisponibles.
Points d’accès et authentification
Utilisez la racine API attendue. Anthropic Messages natif ajoute /v1/messages?beta=true à l’URL fournie sans retirer de préfixe. Pour le service direct Anthropic, la racine est https://api.anthropic.com ; n’ajoutez pas /v1. Les proxys doivent exposer le chemin résultant.
Anyy résout les identifiants avant préparation. L’authentification Anthropic native suit clé effective et règles natives d’en-têtes/bêta ; auth_transport ne force pas un autre mécanisme Messages natif. OAuth/abonnement reste propre au point. Codex utilise son identifiant d’abonnement et l’identité client Anyy (originator: anyy par défaut), sans se prétendre le client du fournisseur. Les en-têtes du modèle sont appliqués avant ceux de requête ; ces derniers peuvent remplacer/supprimer ce marqueur. Anyy gère toujours authentification et User-Agent fidèle.
Catalogue de modèles typés
Le catalogue sépare les opérations par type :
| Type | Finalité | Limite |
|---|---|---|
chat | Conversation et appels d’outils | Défaut si omis ; utilisé par principal/secours |
image | Génération d’image typée | Utilisé par models.generateImages() |
classifier | Classification structurée choix, score et booléen | Utilisé par models.classify() |
Un ID est résolu avec fournisseur et type. Le même ID peut exister dans plusieurs types ; une entrée image/classification ne devient pas silencieusement un modèle chat. Les descripteurs portent API, modalités, limites, coûts, compatibilité et échantillonnage. Ils décrivent une route sans sonder le service distant.
Les champs avancés providers[].models[] incluent type, api, base_url, input, output, headers, input_limits, sampling_params, sampling_params_by_thinking_level, compat, capabilities et cost. Suivez le contrat réseau déclaré et les paramètres documentés. L’échantillonnage natif fusionne défauts du modèle, paramètres du niveau effectif puis paramètres de requête ; les derniers priment. Ces contrôles n’ajoutent pas de famille ni garantie d’acceptation d’options arbitraires.
Utilitaires Models de Codemode
Lorsqu’ils sont disponibles, ces utilitaires asynchrones utilisent catalogue et identifiants configurés :
| Fonction | Résultat |
|---|---|
models.getModelsOfType(type, provider?) | Entrées chat, image ou classifier |
models.getAvailableOfType(type, provider?) | Entrées filtrées par activation et identifiants résolvables |
models.getModelOfType(type, provider, id) | Entrée exacte ou undefined |
models.classify(model, context) | Résultat de classification typé |
models.generateImages(model, context) | Résultat image typé |
« Disponible » est un contrôle local, pas un test d’inférence. Les scripts reçoivent les descripteurs sans en-têtes configurés. L’exécution résout de nouveau le modèle original ; modifier un descripteur retourné ne redirige pas l’opération.
L’API image implémentée est openrouter-images. Les API de classification sont typesafe-system-one, cloudflare-workers-ai-system-one, llama-cpp-classify et openai-decisions. Leurs contrôles locaux ne qualifient pas tout déploiement/compte externe.
Par exemple dans Codemode :
const candidates = await models.getAvailableOfType("image");
if (!candidates.length) throw new Error("Configure an image model first");
const result = await models.generateImages(candidates[0], {
input: [{ type: "text", text: "A landscape watercolor of a quiet lake" }],
});
if (result.stopReason !== "stop") throw new Error(result.errorMessage);
for (const block of result.output) {
if (block.type === "image") image(block);
}
generateImages accepte texte et références image base64 facultatives. classify accepte state, questions et images compatibles facultatives ; les types sont choice, score et bool. Les échecs natifs restent des résultats typés error/aborted. Vérifiez stopReason avant la sortie. Aucun models.chat() générique n’est ajouté.
La classification exige state objet et questions objet non vide. Chaque question possède type, instructions et criteria :
| Type | Forme de criteria |
|---|---|
choice | Objet non vide associant étiquettes et significations textuelles |
score | Tableau non vide de descriptions textuelles (chaînes de caractères), du plus faible au plus élevé |
bool | Objet avec significations true et false |
images facultatif utilise des blocs { type: "image", data: "<base64>", mimeType: "image/png" } et exige un modèle compatible. La classification retourne answers ; l’image, output, avec utilisation si fournie.
L’outil produit Génération d’images est distinct : il utilise OpenAI Responses et conserve une pièce de conversation. Sa route Dashboard ne configure ni openrouter-images ni les classifications.
Tentatives, secours et routage virtuel
Ces mécanismes ont des responsables différents :
| Mécanisme | Contrôle |
|---|---|
| Tentatives automatiques de session | Réessaie une erreur admissible ; activé par défaut, 3 essais, délai exponentiel de 2 000 ms à 60 000 ms |
| Tentatives SDK fournisseur | Réessaie les échecs initiaux transport/HTTP admissibles selon retry.provider sans rejouer un corps déjà diffusé |
| Secours configuré | Essaie une cible ordonnée compatible selon la règle d’erreur |
| Rappel de modèle virtuel | Résout une sélection virtuelle enregistrée vers un modèle physique et raisonnement effectif |
La requête initiale ne compte pas parmi les tentatives de session. Les erreurs de facturation/limites ne sont pas des erreurs transitoires ordinaires ; le débordement de contexte suit sa récupération. L’annulation termine l’attente. retry.enabled: false désactive les tentatives de session sans désactiver tout SDK ni secours.
Les paramètres avancés utilisent exactement ces clés camelCase :
retry:
enabled: true
maxRetries: 3
baseDelayMs: 2000
maxAgentDelayMs: 60000
provider:
maxRetries: 0
maxRetryDelayMs: 60000
httpIdleTimeoutMs: 300000
retry.provider.timeoutMs est un délai facultatif de requête fournisseur. httpIdleTimeoutMs vaut 300 000 ms par défaut ; 0 ou disabled désactive l’inactivité. Les médias ont leurs propres limites. Tentatives de session, SDK, secours et récupération native Codex sont distincts ; un réglage seul n’est pas un plafond global de nombre/durée.
Les modèles virtuels utilisent l’interface interne pi-virtual d’enregistrement/rappel. Ils ne sont pas un sixième protocole distant, et v0.1.107 n’a ni déclaration YAML de routeur virtuel, ni assistant CLI, ni éditeur Dashboard. Un rappel reçoit le contexte utilisateur/continuation/tentative/direct et peut conserver un état de route de branche, mais doit retourner un modèle physique enregistré avec identifiants utilisables. Il ne peut viser un modèle non enregistré ni récursivement un virtuel. Une liste de secours n’enregistre pas ce rappel.
Pour la configuration courante, consultez Configurer les modèles et Modèles Dashboard.