De OpenCode à Kilo Code CLI : ce qui a changé
TL;DR
Kilo Code CLI est un fork d'OpenCode avec Kilo Gateway en plus. En pratique, le TUI est identique, les custom commands marchent pareil, et la migration a pris 15 minutes. La vraie différence : les modèles gratuits via le gateway changent l'économie du workflow.
Mise à jour juillet 2026 — Ce choix n’a pas tenu dans la durée : le free tier de Kilo Gateway a fini par cesser d’être intéressant, et je suis reparti sur Claude Code (abonnement Max). Cette pièce reste publiée telle quelle, comme étape documentée d’une évaluation d’outils. Suite : Anthropic, le Apple de l’IA.
Quand Anthropic a restreint l’usage de l’abonnement Claude Code dans les outils tiers, mon workflow OpenCode + abonnement Anthropic s’est cassé du jour au lendemain. La migration vers Kilo Code CLI — un fork d’OpenCode — n’était pas un choix technologique. C’était une nécessité.
Ce qui est identique
Kilo Code CLI est un fork. Pas une réécriture. En pratique :
Le TUI est le même. Même navigation vim-like, même sélecteur de modèles avec m, même système de sessions. Si tu connais OpenCode, tu connais Kilo Code CLI.
Les custom commands sont compatibles. Les fichiers .opencode/commands/*.md fonctionnent sans modification. Les 15 workflows formalisés de l’équipe ont migré sans toucher un fichier.
L’architecture client/serveur est héritée. Le setup SSH Mac → Ubuntu avec tmux fonctionne exactement comme avant.
Le fichier de contexte projet (AGENTS.md, CLAUDE.md) est lu de la même façon.
Ce qui a changé
Kilo Gateway est la vraie différence. C’est un proxy qui donne accès à des modèles gratuits — dont MiniMax 2.5. Sur les tâches mécaniques (tests, fixtures, DTOs), le résultat est comparable à Claude Sonnet. Sauf que ça ne coûte rien.
En pratique, ~65% de mes sessions tournent sur MiniMax 2.5 via le gateway. Les sessions de raisonnement (debugging complexe, architecture) restent sur Claude Sonnet via l’API Anthropic. Le routing se fait avec la touche m — un geste de 2 secondes.
L’écosystème Kilo apporte aussi Kilo Code VS Code pour l’équipe. Même gateway, même modèles, interface différente. Les devs qui préfèrent VS Code n’ont pas besoin d’un TUI terminal.
La migration en pratique
15 minutes. Installer le binaire, pointer la config vers les mêmes providers, vérifier que les custom commands sont lus. Pas de données à migrer — l’agent n’a pas de mémoire entre les sessions de toute façon.
Le seul ajustement : configurer Kilo Gateway comme provider par défaut pour avoir MiniMax en premier choix. Le reste — tmux bindings, split layout, SSH workflow — rien n’a changé.
Pour qui c’est pertinent
Si tu utilises OpenCode et que tu veux accéder aux modèles gratuits de Kilo Gateway : la migration est triviale. Si tu utilises déjà OpenCode avec OpenRouter et que tu es satisfait de tes coûts : il n’y a pas de raison urgente de migrer, les deux outils sont fonctionnellement identiques.
Si tu commences de zéro en terminal-first : à l’époque de ce dispatch, Kilo Code CLI était le meilleur point d’entrée grâce au gateway gratuit. Ce conseil n’a pas survécu à la fin de l’intérêt du free tier — voir l’encadré en tête et la suite de l’arc pour ma recommandation actuelle.