Mirascope

Mirascope's pitch is subtraction. Where most LLM libraries add layers between your code and the model, Mirascope removes them. You write a Python function, add @llm.call('openai/gpt-5.2', tools=[...]), and you have a model call. Add @ops.version and every invocation carries a version number, a trace, and a cost. That combination — versioning and cost attached to the same object you're already calling — is the part most teams end up bolting on manually elsewhere, and it is the strongest argument for picking this over rolling your own thin client. The agent loop is intentionally small: response = librarian(query); while response.tool_calls: tool_outputs = response.execute_tools(); response = response.resume(tool_outputs). Nothing is hidden. Tools are just functions decorated with @llm.tool, and they can carry their own @ops.trace so they appear correctly nested in the trace tree. Structured outputs come from Python type hints rather than a separate schema language. Provider-agnostic routing means the same call site can point at OpenAI, Anthropic, or Google, with per-provider configuration handled through environment keys and a providers doc page. Where it doesn't fit: there is no built-in RAG pipeline, no vector store, no session memory beyond what the ops layer records. The docs reference a Sessions concept under the Ops section, but the value proposition is observability and versioning, not a retrieval stack. If your project needs document chunking, embeddings, and a vector database on day one, you will be assembling that yourself or reaching for LlamaIndex. Similarly, multi-agent orchestration, retries, and guardrails are yours to write. Rapid prototyping where high-level abstractions would speed you up is a poor match. Two honest constraints. First, it is Python-only — the docs show pip install "mirascope[all]" and uv add, and every example is Python. Second, the community is small: the site badge reads 1.4k GitHub stars, which means fewer Stack Overflow answers and fewer third-party tutorials than a larger framework offers. The compensating factor is that the abstraction surface is small enough to read the source. Observability deserves a note. OpenTelemetry is a first-class path: the docs quickstart wires a TracerProvider with a ConsoleSpanExporter, calls ops.configure(tracer_provider=provider) and ops.instrument_llm(), and then every call is instrumented. That means traces can go to an existing OpenTelemetry backend rather than a vendor-specific dashboard — useful if your org already has one. The hosted Cloud dashboard covers traces and version history for teams that would rather not run it themselves. Net: choose Mirascope if you are a Python engineer who wants model calls, tools, versioning, and cost in your own codebase under an MIT license, and you are prepared to own the pieces it deliberately leaves out.