Timmy-TUI

Chaque exécution se scelle dans un reçu avec chaînage par hachage sha256 et une signature ed25519. Il stocke les hachages du prompt et de la réponse, l'usage des jetons, le coût, la latence et une classe d'erreur. Les exécutions échouées et celles refusées sont scellées aussi, donc les trous d'un journal ne sont pas silencieux. Ce dernier détail compte. La plupart des outils de journalisation n'enregistrent que les succès, c'est-à-dire précisément quand vous avez le moins besoin de l'historique.

TIMMY lie le système d'exploitation, l'architecture et les hachages de build des outils à chaque reçu. Au moment du rejeu, il refuse de faire passer une machine qui a dérivé pour celle qui a produit l'exécution. Donc un rejeu soit correspond à l'environnement, soit vous dit que non. Le rejeu lit le manifeste seul, tandis que les listes de coupe EDL réassemblent les clips dans un paquet portable .agentrun qui embarque les modifications, les hachages et les reçus, avec l'échange OTIO pour les outils qui parlent ce format.

Le Poste de commande prend un DispatchPlan typé, validé avec CUE, et le déroule sur un cycle de vie. Les jetons d'opérateur se lient au hachage complet du plan, donc l'approbation est à usage unique et expire. Les routes payantes refusent par défaut sans limite de dépense, ce qui empêche un agent de faire grimper une facture en douce. C'est un garde-fou que vous réglez une fois et oubliez.

TIMMY pilote les agents par plusieurs canaux d'exécution, chacun conçu pour un type de travail. On y trouve OpenHands en mode bac à sable jetable ou rien, OpenCode, Pi et jcode. Il y a des canaux 3D pour Blender, Godot, Unity, Unreal et Houdini, plus des canaux d'API protégés par clé. Le multiplexage de terminal avec tmux, zellij et rmux vous laisse suivre plusieurs exécutions à la fois.

Pour des réponses plus sûres, les boucles de juge répartissent un prompt sur plusieurs modèles en local, puis ne montent vers un modèle de pointe que quand la confiance franchit un seuil. Chaque boucle scelle les reçus enfants et le reçu parent, ce qui vous laisse retracer comment une réponse finale a été atteinte plutôt que de ne voir que le point d'arrivée.

Le serveur MCP intégré expose 24 outils à tout agent qui parle MCP, avec un pont d'exécution client et un canal d'invocation OpenAPI qui laisse un agent existant déléguer du travail sans reconstruire sa propre couche d'outils. Les services compagnons ajoutent un miroir de chat navigateur sur le port 3001, un navigateur de reçus et une enquête de dispatch sur le 4310, et un Mission Map sur le 4321. Ainsi le travail en terminal a une couche visuelle quand vous en voulez une.