Mirascope est une boîte à outils de développement LLM open source maintenue par Mirascope, Inc., officiellement appelée « LLM Anti-Framework ». Avec le SDK Python/TypeScript comme noyau, il fournit des appels de modèle unifiés, des appels d'outils, une sortie structurée, une boucle d'agent de réponse en streaming, une observation OpenTelemetry de routage du fournisseur, des capacités de gestion des versions de fonctions et de gestion des erreurs sans prendre en charge de force l'architecture de l'application. Il convient pour précipiter des prototypes LLM dans un code d'ingénierie maintenable.

Mirascope

Paramètres et statistiques de base

Le positionnement officiel de Mirascope est « The LLM Anti-Framework ». Pour être plus précis, il s'agit d'un SDK léger pour le développement d'applications LLM, plutôt que d'une plate-forme d'agent full-stack qui oblige les développeurs à migrer vers un runtime spécifique. Il tente de se situer entre les API de modèles natifs et les frameworks d'agents robustes : en conservant les limites de capacités des fournisseurs tels que OpenAI, Anthropic, Google, xAI, Ollama, MLX, etc., tout en réduisant la quantité d'ingénierie répétitive avec des interfaces unifiées, des astuces de type, des décorateurs et des objets de réponse.

Projet	Informations publiques actuelles
Site officiel	https://mirascope.com/
Documents	https://mirascope.com/docs
Dépôt GitHub	https://github.com/Mirascope/mirascope
Paquet PyPI	https://pypi.org/project/mirascope/
Slogan officiel	L'anti-cadre LLM
Résumé PyPI	Chaque LLM frontière. Une interface unifiée.
Langues principales	Python, TypeScript
Exigences Python	>=3.10
Licence Open Source	MIT
Dernière version	2.5.0, publié le 2026-06-24
Taille de la communauté	GitHub environ 1,5k étoiles, 119 forks
État du service cloud	Mirascope Cloud s'est arrêté, le SDK continue d'être maintenu

Limite de capacité : Mirascope ne fournit pas de formation de base sur les modèles, d'hébergement de bases de données vectorielles, de plate-forme de flux de travail d'entreprise ou de console SaaS fermée. Sa valeur fondamentale se situe au niveau du code : regrouper les appels de modèle, les messages, les outils, la sortie structurée, les fournisseurs de réponses en continu, les boucles d'agent de routage et l'observabilité dans une interface de développement plus stable. Pour les ingénieurs en IA déjà familiers avec Python/TypeScript, c'est plus simple que d'écrire directement plusieurs ensembles de SDK Provider ; pour les utilisateurs non techniques qui n’ont besoin que d’une interface de chat, ce n’est pas un point d’entrée approprié.

Reconnaissance des utilisateurs et du marché

Les signaux d'adoption de Mirascope proviennent principalement de la communauté open source, de la plateforme de gestion de packages et de l'activité de documentation, plutôt que des démonstrations commerciales de clients SaaS. Le référentiel GitHub est décrit comme « L'Anti-Framework LLM » et la taille des étoiles publiques est d'environ 1,5 000, ce qui indique qu'il est entré dans la gamme visible des outils d'ingénierie LLM, mais n'a pas encore atteint le volume écologique des frameworks principaux tels que LangChain et LlamaIndex.

Du point de vue du positionnement, Mirascope ressemble plus à une « bibliothèque composable » qu'à une « plateforme ». La documentation du site officiel l'explique comme une abstraction de style React dans le développement LLM : elle a plus d'expérience en ingénierie que l'appel direct de l'API native, mais ne prend pas trop en charge le flux de contrôle comme les grands frameworks. Cette différenciation séduit deux types d'équipes : les équipes d'ingénierie qui ont surmonté la complexité des frameworks lourds, et les équipes produit en phase de démarrage qui souhaitent maintenir la flexibilité de migration entre les fournisseurs multimodèles.

La page PyPI montre que le package est classé comme Production/Stable, prend en charge Python 3.10 à 3.14 et fournit all, anthropic, google, mcp, mlx, openai, ops et d'autres extras. Cette méthode de fractionnement montre que le projet ne transmet pas toutes les dépendances aux utilisateurs en même temps, mais permet de sélectionner la portée de l'installation en fonction des capacités du fournisseur et d'observation, ce qui est plus convivial pour la gestion des dépendances liées à la production.

Avantage de coût

La forme commerciale principale actuelle de Mirascope est très claire : le SDK open source est gratuit et le coût provient principalement du fournisseur de modèles, du backend de journalisation/trace et de la maintenance technique appelée par les développeurs. Après la v2.4.0, Mirascope Cloud a été officiellement abandonné. La page officielle Cloud indique également que l'équipe se concentrera sur le SDK open source et recommande aux utilisateurs d'exporter les données d'observation vers des backends compatibles OTEL tels que Langfuse, Jaeger, Grafana Tempo, Datadog, etc.

Frais individuels et en petite équipe : Vous pouvez l'installer directement à la demande via pip install "mirascope[openai]", uv add "mirascope[anthropic]", etc. Il n'y a pas de frais d'abonnement pour le SDK lui-même. La principale dépense concerne les frais d'inférence pour les modèles OpenAI, Anthropic, Google, xAI ou natifs.

Coût de l'équipe de développement : le point d'économie de Mirascope n'est pas de réduire le prix unitaire des jetons, mais de réduire le travail répété d'adaptation multi-fournisseurs, d'encapsulation des appels d'outils, d'analyse de sortie structurée, de gestion des erreurs et d'accès à l'observabilité. Pour les équipes testant plusieurs modèles en même temps, une interface unifiée peut réduire les coûts de changement de modèle et de vérification A/B.

Limite des coûts d'entreprise : avec le retrait du cloud, les entreprises ne devraient plus acheter Mirascope en tant que plate-forme de surveillance hébergée. Lors du déploiement en production, vous devez choisir votre propre backend OTEL, votre politique de conservation des journaux, votre processus de désensibilisation des informations sensibles et votre solution de gestion des clés. Mirascope ressemble davantage à une bibliothèque d'ingénierie, et la responsabilité de la gestion des coûts reste au sein du système de plate-forme de l'utilisateur.

Fonctions principales

• Appel de modèle unifié : appelez différents fournisseurs via llm.Model("provider/model") ou @llm.call(...) pour réduire les différences d'interface des SDK tels que OpenAI, Anthropic et Google.
• Routage des fournisseurs : la documentation indique que Mirascope utilise un système de correspondance de préfixes d'ID de modèle pour sélectionner les fournisseurs, tels que openai/, anthropic/, google/, ollama/, mlx-community/, etc.
• Appel d'outil : utilisez @llm.tool pour déclarer les fonctions Python ordinaires en tant qu'outils appelables par modèle, et les paramètres d'outils et les docstrings peuvent être convertis en schéma côté modèle.
• Sortie structurée : organisez la sortie du modèle autour d'un système de type Pydantic, adapté aux tâches d'extraction, de classification, de vérification des résultats RAG et d'automatisation.
• Réponse en streaming : prend en charge le traitement en streaming des appels de texte et d'outils, adapté à la création de discussions en temps réel, d'assistants de ligne de commande et de commentaires sur la progression des tâches à long terme.
• Boucle d'agent : L'exemple officiel montre qu'après que le modèle appelle l'outil, la conversation se poursuit via execute_tools() et resume(), et les développeurs peuvent contrôler explicitement la logique de la boucle.
• Module d'observation Ops : mirascope.ops fournit le traçage, la session, le span, la gestion des versions de fonctions et l'instrumentation LLM, et se connecte à des backends externes basés sur OpenTelemetry.
• Modèle local et fournisseur étendu : prend en charge les chemins d'exécution locaux/légers tels que Ollama et MLX, et permet des fournisseurs personnalisés, adaptés aux scénarios de cloud hybride et d'inférence locale.

Evolution du modèle et de la version

L'évolution de la version de Mirascope s'articule autour de deux axes principaux : l'un consiste à étendre la prise en charge des fournisseurs et des API de modèle, et l'autre consiste à revenir à l'écosystème pur SDK et OpenTelemetry après avoir supprimé les fonctionnalités liées au cloud. La navigation actuelle du site Web officiel affiche toujours la version du document v2.4.0, mais les versions GitHub et PyPI montrent que la dernière version du package est la v2.5.0, le champ de version doit donc être basé sur la source de la version publique.

Version	Date de sortie	Changements clés	Jugement
2.5.0	2026-06-24	Ajout de XAIProvider pour prendre en charge Grok via l'API Responses	La dernière version publique
2.4.0	2026-03-08	Arrêtez Mirascope Cloud et supprimez les modules liés au cloud backend/api	Changement d'architecture important
2.3.0	2026-02-27	Fusion des contributions de la communauté et des correctifs de style du site	v2 version pré-mainline
2.2.2	2026-02-05	Correction de la gestion du numéro Cloud OTEL intValue	Version corrigée avant la suppression du Cloud

Recommandations pour la sélection de la version : les nouveaux projets doivent d'abord commencer avec la version 2.5.0 ; si l'équipe s'appuyait auparavant sur Mirascope Cloud ou d'anciens modules API, elle doit évaluer les modifications majeures de la v2.4.0 avant de migrer vers un backend compatible OTEL. L'environnement de production doit corriger la version du SDK et effectuer des tests de régression sur les appels d'outils, la sortie structurée et les formats de retour du fournisseur.

Avantages techniques

L'avantage de Mirascope n'est pas "le plus grand nombre de fonctions", mais "juste la bonne quantité d'abstraction". Le SDK natif du fournisseur offre aux développeurs le plus grand contrôle, mais entraînera des adaptations répétées lors du basculement entre plusieurs modèles ; la structure d'agent robuste offre de nombreuses fonctionnalités prêtes à l'emploi, mais peut rendre opaques les chemins d'exécution, la gestion des états et la gestion des erreurs. Mirascope contrôle l'abstraction dans les couches d'appel, d'outil, de fournisseur de réponses et d'observation, permettant au code métier de conserver un flux de contrôle Python/TypeScript clair.

Priorité des types et des fonctions : utilisez des fonctions ordinaires, des décorateurs et des annotations de type pour exprimer des invites, des outils et des structures de sortie afin de réduire l'état implicite causé par l'orchestration DSL ou graphique. Les équipes peuvent gérer les applications LLM à l'aide des processus de test de charpie, de vérification de type et de révision de code existants.

Capacités natives du fournisseur conservées : Mirascope n'est pas une simple couche de compatibilité OpenAI. La documentation souligne qu'elle convertira les appels au format API correspondant en fonction du routage du fournisseur, dans le but de trouver un équilibre entre les interfaces unifiées et les fonctionnalités du fournisseur. La v2.5.0 ajoute la prise en charge de l'API xAI/Grok Responses, qui reflète également la voie à suivre pour suivre les changements écologiques du modèle.

Chemin OpenTelemetry clair : après le retrait de Cloud, Mirascope rétablit les capacités d'observation aux normes OTEL. Mécaniquement, les équipes peuvent exporter des traces vers des piles APM/observabilité existantes ; l'effet est de réduire la dépendance vis-à-vis du fournisseur ; les scénarios applicables sont les organisations d'ingénierie qui disposent déjà de pipelines Langfuse, Jaeger, Grafana Tempo, Datadog ou OTEL auto-construits.

Comment utiliser

Chemin d'utilisation	Entrée	Étapes typiques	Scénarios d'adaptation
SDK Python	PyPI/uv/pip	Installez mirascope[openai] ou mirascope[all] -> Configurer la clé API du fournisseur -> Écrivez l'appel @llm.call ou llm.Model	Service backend, script Prototype d'agent
Appel d'outil	@llm.tool	Déclarez la fonction métier en tant qu'outil -> Transmettez-la à l'appel du modèle -> Exécutez response.execute_tools() -> resume() Continuer	Agent multi-étapes, calcul/récupération/opération commerciale
Sortie structurée	Documenter le module LLM	Définir le schéma de sortie -> Modèle d'appel -> Vérifier et utiliser les résultats structurés	Extraire, classer, remplir un formulaire Vérification RAG
Observation opérationnelle	mirascope.ops	Configurez TracerProvider -> ops.configure() -> Marquez les fonctions avec @ops.trace, @ops.version	Débogage de production, backtrace de version, analyse des coûts et de la chaîne d'appels
Modèle local	Fournisseur Ollama / MLX	Configurer le contexte d'exécution local -> Utiliser le préfixe de modèle correspondant -> Partager la couche d'appel avec le fournisseur distant	Expérience hors ligne sensible à la confidentialité, PoC à faible coût

Le chemin de mise en œuvre minimum consiste à sélectionner d’abord un véritable appel professionnel au lieu de partir de la plateforme d’agent complète. Utilisez d'abord Mirascope pour envelopper un seul appel LLM afin de vérifier le routage du fournisseur, la gestion des erreurs et la sortie structurée ; puis ajoutez des appels d'outils et des réponses en streaming ; lorsque le projet entre dans une collaboration multi-personnes ou un pilote en ligne, connectez-vous au module « ops » pour exporter les informations de trace, de session et de version vers le système d'observation existant de l'équipe.

Prix des produits

Mirascope SDK est un logiciel open source et il n'existe actuellement aucun prix d'abonnement SaaS accessible au public. Il est important de noter que la page officielle Cloud montre clairement que Mirascope Cloud a été abandonné et que l'équipe se concentrera sur Python et TypeScript SDK ; par conséquent, elle ne doit pas être décrite dans le catalogue comme une plateforme de surveillance cloud encore disponible à l’achat.

Élément de coût	S'il doit être facturé par Mirascope	Descriptif
Frais d'utilisation du SDK	Non	Licence MIT, package Python et code source public
Frais d'appel modèle	Non	Déterminé par OpenAI, Anthropic, Google, xAI, Together ou un environnement de modèle auto-hébergé
Moteur d'observation	Non	Peut être connecté à des systèmes compatibles OTEL tels que Langfuse, Jaeger, Grafana Tempo, Datadog, etc.
Nuage Mirascope Nuage	Indisponible	Le service officiel a été arrêté et n'est plus un parcours d'achat
Assistance entreprise	Non divulgué	Le site officiel ne divulgue pas le package de support commercial indépendant, et la communication officielle en temps réel devrait prévaloir

Jugement d'achat : Si l'équipe souhaite acheter une « plateforme cloud LLMOps à guichet unique », Mirascope n'est pas une option appropriée pour le moment ; si l'équipe souhaite standardiser le code d'appel LLM et laisser les observations dans son propre backend OTEL, le modèle open source de Mirascope est plus flexible.

Scénarios d'application

• Développement d'applications multimodèles : basculez entre les modèles OpenAI, Anthropic, Google, xAI ou locaux pour la même entreprise, réduisant ainsi les coûts de transformation causés par les différences entre les SDK des fournisseurs.
• Du prototype de l'agent AI à l'ingénierie : utilisez du code explicite pour contrôler la boucle de l'agent, l'exécution des outils et les branches d'erreur afin d'éviter que les premiers prototypes ne soient liés par des états de structure implicites.
• Extraction d'informations structurées : convertissez des textes tels que des contrats, des bons de travail, des conversations avec le service client et des documents de recherche en objets structurés vérifiables, et utilisez le système de types pour réduire la probabilité que des données sales pénètrent en aval.
• RAG et Knowledge Assistant : préservez des limites claires entre la récupération, la réponse, la vérification des citations, l'invocation d'outils et l'observation pour faciliter les tests de régression et le suivi de la qualité.
• Accès à l'observabilité de la production : intégrez les appels LLM, les sessions de version de fonction et les extensions dans le système de surveillance existant via OpenTelemetry, adapté aux équipes disposant de capacités d'ingénierie DevOps/plateforme existantes.
• Expérience de modèle local/hybride : associez-vous à des fournisseurs tels qu'Ollama et MLX pour mener des expériences sensibles à la confidentialité ou à faible coût, puis migrez vers le modèle de frontière cloud en fonction de l'effet.

Personnes concernées

• Ingénieur d'application IA : a besoin d'appels stables à plusieurs fournisseurs LLM dans le code et souhaite conserver le contrôle de l'exécution des outils, des réponses en streaming et de la gestion des erreurs.
• Plateforme et équipe back-end : J'espère fournir une couche d'appel LLM unifiée pour le secteur d'activité, et en même temps connecter l'observabilité à la pile OpenTelemetry existante.
• Équipe produit de l'agent : vous disposez déjà d'un processus commercial clair et souhaitez intégrer la boucle d'agent, l'invocation d'outils et la sortie structurée dans le processus de test et de publication.
• Équipe de recherche et de prototypage : Besoin de comparer rapidement différents fournisseurs, modèles et méthodes d'écriture rapide, mais ne souhaitez pas introduire un cadre trop lourd.
• Ne convient pas aux limites : Ne convient pas aux utilisateurs totalement sans code, aux équipes qui doivent héberger l'interface utilisateur de chat, aux acheteurs qui souhaitent uniquement acheter la console LLMOps SaaS ou aux scénarios qui nécessitent une plate-forme de base de formation/de réglage du modèle.

Résumé et Outlook

La valeur fondamentale de Mirascope est de faire progresser le développement d'applications LLM depuis « l'épissage manuel de divers SDK de fournisseur » vers des « interfaces d'ingénierie unifiées mais contrôlables ». Il n'essaie pas de définir la structure entière de l'application comme le framework Agent robuste, mais élimine les parties les plus courantes et les plus sujettes aux erreurs : appels de modèle, outils, sortie structurée, fournisseurs de réponses en continu, boucles d'agent de routage et observations OpenTelemetry.

Le plus grand changement à noter à l'heure actuelle est que Cloud a été interrompu et que Mirascope est revenu au SDK open source principal. Ce changement réduit le verrouillage de la plate-forme et signifie que les utilisateurs doivent préparer leurs propres processus d'observation, de gestion des clés, de masquage des journaux et de publication en production. Pour les équipes disposant de capacités d’ingénierie, il s’agit d’une voie de création de composants plus propre ; pour les utilisateurs recherchant une plate-forme unique, ils doivent être associés à Langfuse, Grafana Tempo, Datadog, Jaeger ou à d'autres outils compatibles OTEL.

Les observations futures se concentreront sur trois éléments : si la couverture des fournisseurs continue de suivre les changements du modèle de frontière, si les capacités de TypeScript et du SDK Python restent cohérentes, et si la route de-Cloud après la v2.4.0 peut conduire à des contributions de la communauté open source plus stables. À court terme, Mirascope convient comme « base d'abstraction légère » pour la couche de code d'application LLM, en particulier pour les équipes qui souhaitent maintenir la flexibilité de migration et la testabilité de l'ingénierie dans un écosystème multimodèle.

Outils associés : Copilote GitHub, Curseur

Informations de version

• Mirascope v2.5.0 ：La dernière version divulguée par GitHub Releases et PyPI ajoute XAIProvider, prend en charge Grok via l'API Responses et augmente simultanément le numéro de version mineure. （2026-06-24）
• Mirascopev2.4.0 ：Modifications importantes de la version. Mirascope Cloud a été officiellement abandonné, le module API et les fonctionnalités liées au backend cloud ont été supprimés, la ligne principale du projet a été convertie en SDK LLM pur et il est recommandé aux utilisateurs d'utiliser d'autres backends OTEL. （2026-03-08）
• Mirascopev2.3.0 ：La série v2.3 de versions publiques inclut des correctifs de style de document/site et la fusion des contributions de la communauté, poursuivant ainsi la ligne principale du SDK v2. （2026-02-27）