OrbitWake CLI
Modèles
OrbitWake CLI utilise la même logique générale de modèles que le reste de la plateforme : vous pouvez travailler avec OrbitWake Auto ou, lorsque l’interface le permet, choisir un modèle explicitement disponible pour votre compte.
Le rôle du modèle dans le CLI
Le modèle est le moteur qui traite votre demande. Il reçoit le texte de votre message ainsi que le contexte utile transmis par OrbitWake, puis produit la réponse affichée dans votre session terminal.
Le choix du modèle influence notamment le comportement de génération, les capacités disponibles, la latence et les limites appliquées à la requête. Le CLI ne doit cependant pas être conçu autour d’un fournisseur particulier : OrbitWake sert de couche d’abstraction entre votre workflow et les modèles disponibles.
OrbitWake Auto
OrbitWake Auto est le mode prévu lorsque vous ne voulez pas choisir manuellement le modèle ou le fournisseur pour chaque tâche. OrbitWake sélectionne alors le chemin de traitement à partir de la demande, des capacités requises et de la disponibilité des services configurés.
Le principe reste le même que dans OrbitWake AI : l’utilisateur travaille avec une identité produit stable, tandis que les détails du fournisseur choisi peuvent rester internes à la plateforme.
Sélection explicite
Dans les interfaces où OrbitWake expose un sélecteur de modèle, vous pouvez choisir explicitement un modèle pris en charge. Cette approche est utile lorsque vous voulez garder un comportement plus prévisible pour une tâche donnée, comparer plusieurs modèles ou utiliser une capacité spécifique.
La disponibilité d’un modèle dépend du compte, de la configuration du workspace, des fournisseurs activés et de l’état du service. Un modèle visible aujourd’hui ne doit pas être considéré comme une dépendance permanente de votre workflow.
Modèle et session CLI
Une session CLI peut conserver le contexte de votre échange pendant que vous travaillez dans le terminal. Le modèle utilisé fait partie de l’état fonctionnel de cette interaction, mais les détails exacts de persistance, de changement de modèle en cours de session et de restauration entre sessions ne sont pas encore publiés comme interface stable.
Pour cette raison, cette documentation ne promet pas qu’un choix de modèle sera automatiquement conservé entre deux lancements du CLI tant que ce comportement n’est pas formellement validé.
Modèle et contexte de projet
Le modèle ne travaille pas directement sur votre disque. OrbitWake prépare le contexte qui doit être transmis à partir du répertoire courant, des fichiers autorisés et des éléments nécessaires à la tâche.
Le choix du modèle et le choix du contexte sont deux problèmes différents. Un modèle plus puissant ne compense pas un mauvais contexte, et un contexte trop large peut ralentir ou dégrader une tâche. Le CLI doit donc privilégier un contexte ciblé et pertinent plutôt qu’un envoi systématique de tout le dépôt.
Disponibilité et fallback
La liste des modèles et leur disponibilité peuvent évoluer. Une interruption fournisseur, une limite de compte ou une capacité indisponible peut empêcher un chemin de traitement spécifique.
Avec OrbitWake Auto, la plateforme peut utiliser ses mécanismes de routage et de fallback afin de continuer avec un autre chemin autorisé lorsque cela est possible. Avec une sélection explicite, le comportement peut être plus strict puisque l’utilisateur a demandé un modèle particulier.
Un fallback ne signifie pas que deux modèles produiront exactement la même réponse. Les différences de comportement, de style et de capacité doivent être prises en compte pour les tâches sensibles.
Ce qui est actuellement confirmé dans le terminal
À ce stade, les commandes publiques confirmées restent volontairement limitées à l’installation, la connexion et le lancement du CLI.
$ npm install -g @orbitwake/cli
$ orbitwake login
$ orbitwake--model, de sous-commande models ou de syntaxe interactive de sélection tant que ces interfaces n’ont pas été validées dans OrbitWake CLI.Bonnes pratiques
Pour les workflows de développement, utilisez OrbitWake Auto lorsque vous privilégiez la simplicité et la continuité. Utilisez un modèle explicite uniquement lorsque le produit expose officiellement cette option et que vous avez une raison précise de figer le choix.
Ne basez pas vos scripts ou automatisations sur un nom de modèle affiché dans l’interface sans vérifier qu’il fait partie d’une interface documentée. Les noms visibles, les fournisseurs disponibles et les routes internes peuvent évoluer indépendamment du CLI.
Pour une tâche importante, vérifiez toujours le résultat produit, en particulier lorsqu’il s’agit de modifications de code, de commandes shell, de changements Git ou de déploiements.
Ce qui reste à documenter
La syntaxe de sélection d’un modèle depuis le CLI, le changement de modèle pendant une session, l’affichage de la liste des modèles, les identifiants stables, les paramètres éventuels de routage et les comportements détaillés de fallback restent hors de cette page tant qu’ils ne sont pas confirmés.
Lorsque ces interfaces seront stabilisées, elles seront ajoutées ici avec des commandes copiables et des exemples exécutables plutôt qu’avec des suppositions.
Étapes suivantes
Continuez avec Contexte de projet pour comprendre comment OrbitWake détermine ce qui appartient au projet courant et comment ce contexte doit être limité avant d’être envoyé au modèle.