OpenSquilla est un agent IA local qui promet de faire tourner CLI, interface web, mémoire, outils et routage de modèles dans une même boucle. Mon verdict court : ça marche pour lancer un agent réel avec un fournisseur OpenAI-compatible, mais le produit reste jeune et il faut accepter de mettre les mains dans la configuration.
Je l’ai testé comme je testerais un outil que je pourrais intégrer dans une chaîne DevOps : clone du dépôt, installation, configuration via proxy LLM local, exécution sur un mini dépôt Python, puis capture de l’interface web.
OpenSquilla, c’est quoi ?
OpenSquilla se présente comme un runtime d’agent IA « microkernel ». En clair, il essaie de séparer le cerveau LLM, les outils, la mémoire, les canaux de chat, l’interface web et les politiques de permissions, tout en gardant une expérience unique.
Le dépôt annonce trois usages principaux :
- un agent en ligne de commande pour les tâches ponctuelles,
- une Web UI locale pour piloter l’agent,
- des connecteurs et fonctions avancées comme mémoire, crons, recherche web, sessions et gateway.
Le positionnement « token-efficient » vient surtout de SquillaRouter, un routeur local censé envoyer les requêtes vers le modèle le moins cher capable de répondre. Dans mon test, je n’ai pas validé ce routeur complet, car l’installation du profil recommandé a échoué dans le conteneur par manque d’espace temporaire lors de l’extraction de NumPy. J’ai donc testé le coeur agent, sans le profil lourd recommandé.
| Élément | Observation pendant le test |
|---|---|
| Version du dépôt | 0.3.1 depuis la branche clonée |
| Langage principal | Python 3.12 requis |
| Interface | CLI plus Web UI locale |
| Fournisseur testé | OpenRouter via proxy OpenAI-compatible local |
| Modèle utilisé | openai/gpt-4o-mini |
| Cas testé | revue sécurité d’un mini projet Python |
Installation de OpenSquilla
J’ai cloné le dépôt dans /tmp, comme prévu pour un test propre, puis j’ai lu le README, le quickstart et le pyproject.toml. Le projet dépend de Python 3.12 et recommande uv.
La commande documentée pour le profil recommandé tire aussi des dépendances lourdes, dont ONNX Runtime, LightGBM, scikit-learn, tokenizers et NumPy. Dans mon conteneur, ce chemin a bloqué avec une erreur nette : plus d’espace disponible pendant l’extraction de NumPy dans /tmp.
J’ai donc basculé sur une installation source du paquet de base, dans un environnement isolé temporaire :
uv tool install --python 3.12 /tmp/opensquilla-scout
Ensuite, j’ai configuré OpenSquilla avec le proxy LLM fourni :
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
opensquilla onboard \
--minimal \
--provider openrouter \
--api-key-env OPENROUTER_API_KEY \
--base-url http://172.17.0.1:8790/v1 \
--model openai/gpt-4o-mini \
--router disabled \
--skip-channels \
--skip-search \
--skip-image-generation
Le statut d’onboarding est ensuite passé à OpenSquilla ready: yes. Le fournisseur était prêt, la mémoire en mode local était prête, les canaux et l’image génération étaient logiquement laissés pour plus tard.
OpenSquilla à l’usage
Pour un vrai essai, j’ai créé un mini projet Python dans /tmp/opensquilla-test. Il contenait une fonction is_admin, une fonction delete_user, et une sortie simple basée sur la variable USER.
Le premier run m’a donné une réponse trop générique : l’agent a parlé de dépendances vulnérables et a proposé des tests pour des fonctions qui n’existaient pas. C’est un point important : comme avec beaucoup d’agents, le prompt initial doit être précis si on veut forcer l’inspection réelle du code.
J’ai relancé avec une consigne plus stricte : lire README.md et app.py avec les outils fichier avant de répondre, ne pas inventer de fonctions, ne rien modifier. Là, OpenSquilla a bien utilisé ses outils read_file, puis a produit une réponse cohérente avec le code.
opensquilla agent \
--workspace /tmp/opensquilla-test \
--workspace-strict \
--permissions bypass \
--model openai/gpt-4o-mini \
--max-iterations 6 \
-m "You must inspect README.md and app.py with file tools before answering..."
Ce que l’agent a produit :
- il a identifié
is_admin(user), - il a identifié
delete_user(user, target), - il a expliqué que seul
adminpeut supprimer un utilisateur, - il a proposé deux tests pytest adaptés au code réel.
Le transcript JSONL confirme que l’agent a appelé read_file sur README.md et app.py. Côté coût, le run a utilisé environ 24 503 tokens, avec 2 requêtes et un coût estimé autour de 0,002 dollar via le proxy et openai/gpt-4o-mini.
Interface web de OpenSquilla
J’ai aussi lancé la gateway locale :
opensquilla gateway run --port 18791
L’interface répondait en HTTP 200 sur /control/. La page charge une application JavaScript avec les vues chat, sessions, configuration, setup, logs, santé, canaux et usage. C’est plus qu’un simple wrapper CLI : on sent que le projet vise un cockpit local complet.
Je n’ai pas laissé la gateway tourner après le test. Le serveur Uvicorn a été arrêté, et les répertoires temporaires ont été supprimés à la fin.
Ce que j’aime dans OpenSquilla
Le premier bon point, c’est l’ambition produit. OpenSquilla ne se contente pas d’être un script qui appelle un modèle. Il pose déjà les briques utiles pour un vrai assistant local : sessions, mémoire, outils, permissions, gateway, interface web, providers multiples.
J’aime aussi la compatibilité fournisseur. Le fait de pouvoir pointer vers une base OpenAI-compatible custom est important pour travailler avec un proxy, OpenRouter ou une gateway interne.
Autre point positif : les traces sont exploitables. Entre les logs, le transcript JSONL et le fichier d’usage, on peut vérifier ce qui s’est passé. Pour un usage sécu ou DevOps, cette auditabilité compte beaucoup.
Les limites de OpenSquilla
La limite la plus visible dans mon test, c’est le poids de l’installation recommandée. Le profil complet dépend de paquets ML lourds. Sur un environnement contraint, ça peut casser avant même le premier run.
Deuxième limite : le premier résultat agent n’était pas assez fiable. Sans consigne explicite d’utiliser les outils fichier, l’agent a halluciné des tests pour des fonctions absentes. Ce n’est pas forcément la faute exclusive d’OpenSquilla, le modèle joue beaucoup, mais le produit devrait encourager plus fortement l’ancrage outil pour les revues de code.
Troisième limite : certains messages internes sont bruyants. Les logs sont utiles, mais un utilisateur grand public peut vite être perdu entre sandbox, bootstrap, mémoire, catalogues modèles et warnings de dépendances.
OpenSquilla, est-ce que ça marche vraiment ?
Oui, sur le périmètre testé. J’ai installé le paquet source de base, configuré un fournisseur LLM réel via proxy, lancé un agent sur un mini dépôt, observé des appels d’outils fichier, obtenu une réponse utile, puis lancé la Web UI locale.
Non, je ne peux pas dire que toute la promesse est validée. Je n’ai pas prouvé SquillaRouter en conditions complètes, ni les canaux de messagerie, ni les crons en production, ni la mémoire long terme sur plusieurs jours. Mon test valide plutôt le coeur : un agent local piloté par CLI et gateway, connecté à un LLM, capable de lire un workspace et de produire une analyse.
Faut-il adopter OpenSquilla ?
Mon verdict : essayer, mais pas adopter aveuglément en production.
Pour un freelance sécu, un DevOps ou un développeur qui veut construire son propre assistant local, OpenSquilla vaut clairement un test. Il apporte déjà une structure sérieuse, avec une vraie notion de runtime et de cockpit.
Pour une équipe qui cherche un outil simple et stable à mettre dans les mains de tout le monde, j’attendrais encore. Le projet est prometteur, mais il demande de comprendre les providers, les dépendances Python, les permissions, la mémoire et les chemins d’installation.
Le bon usage aujourd’hui : labo personnel, prototype d’assistant interne, veille technique, automation encadrée. Le mauvais usage : remplacer demain matin un workflow CI ou un opérateur humain sans garde-fous.
FAQ
OpenSquilla est-il utilisable sans clé OpenAI ?
Oui, si vous avez un fournisseur compatible, un proxy local ou un modèle local pris en charge. Dans mon test, j’ai utilisé OpenRouter via un proxy OpenAI-compatible local.
OpenSquilla remplace-t-il un IDE agentique ?
Pas directement. Il ressemble plus à un runtime d’agent généraliste avec CLI, Web UI, mémoire et outils. Pour coder, il peut aider, mais il faut cadrer fortement les permissions et les consignes.
OpenSquilla est-il prêt pour la production ?
Je le classerais plutôt en outil à évaluer sérieusement. Le coeur fonctionne, mais le profil complet est lourd et certains comportements agent doivent être surveillés avec des transcripts, des limites et des validations humaines.