Le billet publié le 21 mai 2026 sur NanoCorp présente nano 1.5 comme une nouvelle version du harness agent de la plateforme. Les chiffres mis en avant sont solides : coût moyen par tâche ramené de 2,33 $ à 1,56 $, coût médian abaissé de 1,49 $ à 1,21 $, durée médiane d'exécution réduite de 9,5 à 7,6 minutes, et taux de récupération en cours de tâche passé de 60 % à 86 %. Mais le point le plus intéressant pour les builders n'est pas la baisse de prix en elle-même. C'est le mécanisme technique qui produit cette amélioration : nano 1.5 corrige davantage d'erreurs seul, sans transformer chaque incident en arrêt net.
La nouveauté tient d'abord à la méthode. NanoCorp explique que cette version est la première construite de bout en bout à partir des traces de production de la précédente. En clair, les erreurs réelles rencontrées par nano-1 ne servent plus seulement à alimenter des post-mortems internes. Elles deviennent de la matière de training et de la logique d'exécution. Ce principe est renforcé par l'ajout de neuf skills directement injectées dans le sandbox. Ces skills couvrent des cas très concrets : attendre un déploiement, gérer un conflit lors d'un git push, savoir quand arrêter de poller, réagir à un échec d'authentification, vérifier un déploiement Vercel, ou encore reconnaître qu'un quota est épuisé.
Ce que cela change en pratique est plus important qu'un simple gain de benchmark. Jusqu'ici, beaucoup de workflows agents échouaient moins parce que le modèle "raisonnait mal" que parce qu'il se heurtait à un environnement réel plein de frictions : arguments mal formés, authentification incomplète, déploiement pas encore propagé, quota déjà consommé, état distant incertain. Le billet officiel indique que les erreurs d'appel d'outils déclenchent désormais une boucle d'autocorrection au lieu d'un hard stop. Autrement dit, l'agent n'abandonne plus immédiatement quand un outil répond mal ou qu'une commande part de travers. Il tente une adaptation, relit son contexte, puis repart.
Pour les builders, c'est une mise à jour de runtime bien plus qu'une simple évolution "modèle". Qu'on pilote un produit visible sur NanoDir, une opération de contenu comme NanoPulse, ou un flux maison de prospection et de reporting, la question n'est jamais seulement "combien cela coûte ?". La vraie question est : faut-il surveiller l'agent à chaque étape ? En faisant remonter la récupération en cours de tâche à 86 %, NanoCorp réduit justement cette dépendance au babysitting humain. Les tâches longues deviennent moins fragiles, les séquences multi-outils moins cassantes, et les builders non techniques récupèrent des heures d'attention.
Il faut aussi noter que NanoCorp n'a pas présenté nano 1.5 comme une migration lourde. La version est annoncée comme disponible immédiatement, sans nouveau palier tarifaire et sans action spécifique de l'utilisateur. C'est cohérent avec la nature réelle de la mise à jour. Nano 1.5 n'ajoute pas un bouton spectaculaire. Il renforce la couche invisible qui fait qu'un agent termine plus souvent ce qu'il a commencé. Pour une plateforme qui promet des entreprises autonomes, c'est probablement la nouveauté technique la plus structurante du moment.