Présentation

WorldTUI est une démonstration qui exploite un modèle de langage de 360 M de paramètres, dérivé de Qwen2.5‑Coder‑0.5B, afin de prédire les changements d’écran d’un terminal à chaque frappe de touche. Aucun shell réel n’est présent : le modèle reçoit les octets de la touche (par ex. \r pour Entrée, 0x1b pour Escape) et renvoie les lignes à réécrire ainsi que la nouvelle position du curseur. Le démon fonctionne dans le navigateur grâce à WebGPU, le fichier modèle pesant 208 Mo.

Architecture du modèle

Le terminal est modélisé comme une grille de caractères (ex. 32 × 96 cellules). Le modèle ne voit pas la grille directement ; il reçoit une séquence de tokens décrivant la taille, le contenu initial (BOS SCREEN_START 32 96 … SCREEN_END) et chaque INPUT_START contenant le caractère brut. En sortie, il génère des instructions de mise à jour : ROW_0 17 'l' suivi de CURSOR 0 18 1. Les coordonnées et les caractères utilisent les 256 tokens byte déjà présents dans le vocabulaire, ce qui limite le vocabulaire total à 333 tokens (256 bytes, 64 tokens de ligne, quelques opérations spéciales).

Pour les actions qui affectent plusieurs lignes (défilement, clear, insertion), le modèle emploie une opération COPY qui ne coûte que trois tokens par ligne au lieu de ~96, réduisant ainsi la charge de décodage. Un token WAIT avec durée encode les intervalles d’inactivité, indispensable pour des programmes comme Snake qui évoluent sans saisie.

Génération des données et entraînement

BOS SCREEN_START 32 96
ROW_0 0 'simedw@laptop:~$ '
CURSOR 0 17 1
SCREEN_END
INPUT_START 'l' INPUT_END
OUTPUT_START
ROW_0 17 'l'
CURSOR 0 18 1
OUTPUT_END

Le jeu de données a été créé en enregistrant 336 k sessions Docker, soit environ 2 M M tokens, avec des tailles de terminal variées (24 × 80, 32 × 96, 40 × 120). Les sessions intègrent des activités aléatoires (édition Vim, Python, tmux), un taux de faute de frappe de 1,2 % et 35 % démarrent en plein milieu d’une application pour forcer le modèle à gérer des états arbitraires. L’entraînement initial a consisté en un fine‑tuning supervisé, puis un apprentissage de type DAgger : le modèle prédit 1‑4 événements, la sortie est comparée à la référence, et les écarts sont corrigés pour créer de nouvelles paires d’entraînement, limitant la propagation d’erreurs.

Analyse des performances et limites

En pratique, le modèle reproduit des comportements réalistes : création de fichiers, édition avec Vim, exécution de tmux, même des jeux simples comme Snake. Il conserve généralement le contexte sur plusieurs commandes, mais des incohérences apparaissent après plusieurs dizaines d’étapes, notamment lorsqu’une faute de frappe n’est pas réparée. Le vocabulaire restreint garantit que chaque prédiction respecte la grammaire d’une mise à jour d’écran, mais empêche l’ajout de nouveaux caractères Unicode hors du jeu de 256 bytes. La dépendance à WebGPU rend la démonstration fluide uniquement sur Chrome ou Edge ; sur mobile, le débit chute drastiquement, rendant l’interaction laborieuse.