Configurer les modèles

Anyy utilise un fournisseur/modèle sélectionné pour les conversations ordinaires. Vous pouvez configurer des secours ordonnés et des routes séparées image, vidéo et parole. Ce guide décrit v0.1.107.

Choisir une interface de configuration

Objectif	Interface
Configurer fournisseur et modèle principal	anyy setup model
Voir et modifier les routes	Dashboard → Models
Configurer les secours	anyy setup model fallback ou Dashboard → Models
Inspecter chemins et références d’identifiants	anyy config
Changer la conversation actuelle	Sélecteur de modèle Chat ou TUI /model

Commencez par :

anyy setup model

Une route exige fournisseur, point d’accès/protocole compatible, authentification et ID exact accepté. L’assistant découvre les modèles si possible, accepte une saisie manuelle et montre un récapitulatif avant écriture. Test connection de Dashboard vérifie la connectivité du catalogue et la présence du modèle choisi avec les paramètres en attente ou enregistrés. Aucun appel de génération conversationnelle n’est envoyé.

Après enregistrement, ouvrez une nouvelle session Chat et vérifiez la sélection fournisseur/modèle. Envoyez une courte demande telle que « Réponds Prêt » et confirmez une vraie réponse. Pour ce test, désactivez temporairement les secours puis restaurez leurs réglages. Si vous les gardez, confirmez que le fournisseur/modèle testé a produit la réponse sans secours avant de le considérer fonctionnel. La sélection de session et une réponse réussie seules ne prouvent pas la cible qui l’a générée, pas plus que découverte, connexion ou état de configuration.

Protocoles pris en charge

Les cinq familles conversationnelles actuelles sont openai-compatible, openai-responses, codex-responses, anthropic-messages et google-gemini. Elles suivent la référence Pi v1.2.0 figée d’Anyy pour le comportement partagé.

Azure OpenAI Responses, Bedrock Converse, Google Vertex, Mistral Conversations et pi-messages n’ont pas d’implémentation native indépendante dans cette version. Une entrée catalogue, une marque ou une URL de base compatible ne prouve pas la prise en charge d’une API native distincte. Consultez Protocoles et interfaces de modèles pour limites, types et tentatives.

Fournisseurs locaux

Démarrez Ollama ou LM Studio avant setup et installez au moins un modèle. Ollama utilise son point d’accès OpenAI avec openai-compatible et http://127.0.0.1:11434/v1 par défaut ; /api/tags sert à la découverte, sans protocole d’inférence distinct. Ollama Cloud utilise https://ollama.com/v1. Ollama local n’exige pas d’authentification par défaut ; un point protégé peut utiliser l’option de clé API compatible.

Les anciens réglages api_mode: ollama, ollama.local.native et ollama.cloud.native sont rejetés. Relancez setup et choisissez le point OpenAI ou migrez explicitement vers openai-compatible, l’URL /v1 du service et ollama.local.openai ou ollama.cloud.openai. Anyy ne réécrit pas silencieusement ces valeurs.

Points d’accès compatibles

Utilisez OpenAI-compatible ou Anthropic-compatible uniquement si le service implémente ce protocole. Saisissez sa racine API et l’ID exact du modèle. Les métadonnées de capacités doivent correspondre ; la saisie manuelle ne rend pas un modèle inconnu compatible images, outils ou raisonnement.

Le fournisseur détermine la destination des données

Il peut recevoir demandes, contexte, pièces et résultats d’outils nécessaires. Examinez confidentialité, conservation, compte et facturation.

Modèle principal et identifiants

Après setup, inspectez le résultat :

anyy config
anyy status

anyy config affiche configuration non secrète, chemins et santé des références. Les clés gérées sont sous <ProfileHome>/secrets/ avec mode 0600 ; la configuration garde les références. Une référence env:MY_MODEL_KEY fonctionne seulement si le Gateway hérite de la variable.

Dashboard → Models permet saisie, remplacement et effacement de clés, ainsi que les actions d’abonnement offertes par le point sélectionné. Codex utilise la connexion par appareil ChatGPT. L’option d’abonnement Anthropic Claude Code accepte un jeton setup obtenu à l’extérieur ; ce n’est pas une connexion générique pour tout fournisseur OAuth. Les choix catalogue bloqués restent indisponibles. Une connexion ou découverte réussie ne prouve toujours pas que chaque modèle ou compte fonctionne.

Utilisez la même interface Models/setup pour reconnecter ou déconnecter un identifiant compatible. Évitez les secrets dans demandes, historique shell, captures et rapports.

Routage de secours

Une fois la route principale fonctionnelle :

anyy setup model fallback

Ajoutez des cibles indépendantes dans l’ordre préféré. Dashboard peut activer/désactiver chaque entrée et définir allow_reasoning_drop, allow_context_drop et max_attempts. Pour vérifier la génération d’un secours, sélectionnez-le explicitement dans une nouvelle conversation et envoyez une courte demande, avec le même contrôle sans secours ci-dessus. Son seul contrôle de catalogue ne suffit pas.

Le secours est un routage conditionnel de disponibilité. Il vérifie la classe d’erreur et la compatibilité, dont outils/médias, historique de raisonnement et taille du contexte ; il ne lance pas tous les modèles et ne fusionne pas les réponses. Autoriser un contexte plus petit ne fait pas automatiquement tenir la requête. Utilisez points et identifiants indépendants pour la résilience.

Limites de secours et tentatives automatiques de session sont distinctes. Consultez Tentatives, secours et routage virtuel.

Changer la session actuelle

Enregistrer le modèle principal définit les valeurs des nouvelles sessions. Les existantes peuvent conserver cible et raisonnement. Changez explicitement cette session dans Dashboard Chat ou la TUI :

/model
/provider
/effort

Utilisez /new pour une conversation neuve. Changer de modèle ou raisonnement peut réduire la réutilisation du cache et augmenter les coûts.

Valeurs de raisonnement par défaut

Les niveaux nommés sont off, minimal, low, medium, high, xhigh et max. Les contrôles montrent les choix compatibles du modèle et les demandes sont bornées selon son mapping. Off peut devenir un autre niveau si le modèle ne peut désactiver le raisonnement. Les modèles sans raisonnement utilisent off sans sélecteur d’effort.

Action	Ordre des préférences avant bornage
Nouvelle session	Réglage par modèle → global → medium
Changement de modèle	Réglage du modèle cible → global → raisonnement actuel → medium
Reprise d’une branche avec messages	Raisonnement enregistré ; sinon global → medium
Reprise sans messages	Valeurs initiales et par modèle → global → medium

Modèle/raisonnement enregistrés priment sur les réglages ultérieurs à la reprise de messages. Les sessions occupées restent inchangées. Restaurer la sélection n’envoie aucune requête. Sans modèle sélectionné, le raisonnement initial est off.

inference.level garde la préférence demandée ; inference.effective_level en lecture seule montre le résultat borné. L’aperçu global utilise le modèle principal sans réglages par modèle et peut donc différer d’une nouvelle session. Enregistrer un contrôle d’effort Dashboard non touché ne mémorise pas sa valeur dérivée comme préférence.

Dans /effort, Entrée applique le choix à la session et enregistre la préférence globale demandée en préservant fournisseur/modèle enregistrés ; Alt+S ne change que la session. Aucun n’écrit de réglage par modèle. Consultez Configuration et migration du raisonnement pour YAML et paramètres retirés.

Historique de raisonnement

Chat compatible OpenAI conserve les champs natifs non vides reasoning_content, reasoning ou reasoning_text, même si le catalogue ne déclarait pas le raisonnement. reasoning_details structuré reste un historique opaque. Une continuation sur la même cible restaure le champ natif correspondant ; changer de cible suit les conversions d’historique du protocole. Ne copiez pas le raisonnement caché dans la réponse et n’inventez pas de commutateurs pour activer sa reprise.

Routes auxiliaires

Dashboard → Models regroupe compréhension image/vidéo, génération d’images, TTS et STT. L’entrée image/vidéo native exige une capacité déclarée. summary_first exige une route dédiée. Les points vocaux ont leurs protocoles et identifiants ; un modèle textuel fonctionnel n’active pas la parole automatiquement.

L’outil produit de génération utilise sa route OpenAI Responses compatible. models.generateImages() de Codemode est une opération typée distincte ; configurer l’un ne configure pas l’autre. Consultez Génération d’images et Voix et parole.

Dépannage

Symptôme	Points à vérifier
Erreur d’authentification	Compte, clé/connexion, domaine d’identifiants du point et environnement résident
Modèle introuvable	Actualisez la découverte ou saisissez l’ID exact
Connexion locale refusée	Démarrez le serveur et vérifiez sa racine API
Secours inefficace	Testez les routes séparément, puis activation, ordre et compatibilité
Ancien modèle conservé	Changez cette session ou lancez /new
Coût ou latence inattendus	Modèle, raisonnement, limites de tentatives, secours et médias

Pour les contrôles visuels, consultez Modèles dans Dashboard.