I don't usually write posts like this. I'm not a library evangelist. But every once in a while something in the tooling layer changes meaningfully enough that I feel like I'd be doing the community a disservice by staying quiet about it.
Toolops just hit stable release, and it's worth knowing about.
Quick background, if you're not familiar
ToolOps is a Python middleware SDK for AI agent infrastructure. The concept is simple: you wrap any async tool function in a single decorator, and it instantly gets production-grade caching, retry logic, circuit breaking, request coalescing, and observability — without touching your business logic.
I've been using it in client work for a few months. I've written about specific use cases before — a startup handling 10,000+ conversations a day that was quietly bleeding money on redundant API calls, multi-agent systems where sub-agents were independently firing the same paid tool queries with no shared memory between them. In both cases, ToolOps was the fix.
The stable release changes the installation story significantly, and that's what I want to talk about.
What just changed — and why it matters
Up until now, using ToolOps with specific database backends meant managing optional extras. PostgreSQL required toolops[postgres]. Semantic caching required toolops[semantic]. If you wanted everything, you installed toolops[all] and hoped your dependency resolver didn't complain.
That's gone now.
pip install toolops
That's the whole command. One install gives you:
-
PostgreSQL via
asyncpg -
SQLite via
aiosqlite -
Valkey / Redis via
redis -
MySQL and MariaDB via
aiomysql -
Semantic caching via
sentence-transformersandnumpy - OpenAI embeddings support
- OpenTelemetry and Prometheus telemetry
All of it. Out of the box. No extras flags, no dependency juggling, no "why is semantic caching not working" debugging sessions at midnight because you forgot to install the right variant.
For anyone who has spent time managing Python dependency extras in CI pipelines or Docker images, you know how much hidden friction this removes.
The new backends are the real headline
Four new first-class cache backends shipped alongside this release, and the expansion matters more than it sounds.
SQLite is the one I'm most immediately glad to have. For local development, single-process tools, or serverless deployments where standing up a Redis instance is overkill — SQLite now works out of the box with full tag-based invalidation. It uses a two-table relational schema with indexed lookups, so it's not a toy implementation. It's genuinely fast for the use cases it fits.
Valkey is the open-source Redis fork that's been gaining serious traction since Redis changed its licensing. If your infrastructure team has already migrated — or is planning to — ToolOps now supports it natively with an async connection pool and O(1) tag-based invalidation using Sets.
RedisCache is provided as a clean alias that inherits from the Valkey backend. If your existing deployment scripts reference Redis by name, nothing breaks. The nomenclature is preserved; the backend is unified.
MySQL and MariaDB round out the database support. Compatible with MySQL 8.0+ and MariaDB 10.5+, normalized dual-table schema, transactional commits, upsert semantics via ON DUPLICATE KEY UPDATE. For teams already running MySQL in production — which is most teams, if you're honest about the industry — this removes the last remaining reason to reach for a separate caching solution.
What this means in practice
Before this release, choosing a cache backend was a deployment decision that also became an install decision. PostgreSQL for one project, Redis for another — each one required a different install command, different CI configuration, different Dockerfile lines.
Now you pick the backend at configuration time, not install time:
ToolOpsManager.register_backend(
"main_cache",
MySQLCache(
host="localhost",
database="toolops_cache",
user="root",
password="password"
)
)
The decorator stays identical regardless of backend:
@readonly(cache_backend="main_cache", cache_ttl=3600, retry_count=3)
async def run_tool(query: str) -> str:
return await paid_tool.call(query)
Backend is a configuration choice. Decorator is business logic. They don't bleed into each other.
Who should care about this right now
Teams already using ToolOps: Upgrade is a single command — pip install --upgrade toolops — and requires zero code changes. Your existing decorators, backends, and CLI commands work exactly as before. You can simplify your requirements.txt or pyproject.toml immediately.
Teams running MySQL or MariaDB in production: You now have a first-class, native cache backend that integrates directly into the infrastructure you already operate. No Redis sidecar, no extra managed service, no additional monthly cost.
Teams doing local AI development: SQLite backend means you can run a fully-featured, properly cached agent pipeline with zero external infrastructure. It's the fastest possible path from "I want to test this tool" to a working, resilient, observable local environment.
Teams building multi-agent systems at scale: None of the core features changed. Request coalescing, semantic caching, circuit breaking — all still there, all still the core reason to use this. The stable release just means you can trust the foundation underneath them.
A note on the codebase itself
For anyone who evaluates libraries by looking at the internals before adopting them — the caching subsystem was refactored into a clean modular package structure as part of this release. Each backend lives in its own module. The interface contracts are properly typed and pass mypy strict mode across all nine cache modules with zero errors. The test matrix covers each new backend with unit and integration tests.
It's the kind of release that signals a project transitioning from "promising experiment" to "something you can actually build on." The internals match the ambitions.
Final thought
The tooling layer for AI agents has been a mess for a long time — not because people weren't trying, but because the problem surface is broad and the solutions kept arriving piecemeal. Caching here, retry logic there, a circuit breaker you wrote yourself two projects ago and copy-paste ever since.
ToolOps has been quietly assembling those pieces into a coherent whole. The stable release, and the database expansion that came with it, is the point where I'd say it's no longer a library you evaluate — it's a library you add to the stack and stop thinking about.
That's the highest compliment I can give infrastructure.
GitHub: github.com/hedimanai-pro/toolops
Happy to answer questions about specific integration patterns or use cases in the comments — particularly around multi-agent setups and high-volume pipelines.
Top comments (0)