When we rolled AI coding tools across Intevity earlier this year, we hit the same wall most engineering teams are about to hit. Every tool ships its own telemetry, in its own format, to its own dashboard, sitting on the vendor’s infrastructure.
If your team uses Claude Code, Cursor, and Copilot, you’re paying three vendors and getting three blind spots. There’s no unified view of which tools your developers actually use, what those tools cost, or what they produce. Standard observability practice for the rest of your stack is simply missing for the part of your stack that’s growing fastest.
Every AI coding tool ships its own telemetry to its own dashboard on its own vendor's infrastructure — three tools, three bills, three blind spots.We built Trove to fix that for ourselves. We’re open-sourcing it because the problem isn’t ours alone.
Trove is a small desktop app that detects the AI coding tools already installed on a developer’s machine, configures each one to emit OpenTelemetry, and forwards a unified stream to whatever observability backend you already own. It auto-detects twelve tools today: Claude Code, Claude Desktop, Cursor (CLI and IDE), Codex (CLI and desktop), Gemini CLI, Copilot CLI, Cline, OpenCode, Qwen Code, and Aider. The list grows as new tools land.
The data never goes to Intevity. We don’t run a backend, and we don’t see your telemetry. Your team’s traces and metrics flow directly from the developer’s laptop to the backend you choose, whether that’s SigNoz, Honeycomb, Grafana, Datadog, Elastic, Splunk, Dynatrace, or anything else that speaks OTLP. We’ve validated eighteen backends so far.
One local collector auto-detects your tools, normalizes their telemetry, and forwards a unified stream to any OTLP backend you already own.Where is your AI tool spend actually going, and what are you getting for it?
The question gets harder as you scale, not easier. Seat-based tools like Copilot are at least predictable at roughly twenty dollars a head per month, so you can forecast them. The tools developers are increasingly pulling onto their machines, including Claude Code, Codex, and Cursor with API access, are not predictable in the same way. They bill on tokens. A heavy user can spend in a day what a light user spends in a month, and a bad prompt can spend more than a good feature. The bill arrives in aggregate on a credit card statement or a vendor invoice at the end of the cycle, with no breakdown by user, by tool, by project, or by outcome.
From a CIO seat, that leaves a set of questions no current dashboard can answer. What is each AI tool actually costing you, in tokens, per user, per week? Which projects, teams, or kinds of work are driving the spend? Is the cost per accepted change going up or down as you add tools? What should next quarter’s budget be, and what evidence do you have to defend it?
The tools bill on tokens and the invoice arrives as one aggregate number. Trove breaks it back down by tool, user, and team.Without that data, every AI tool decision becomes a judgment call made without a number. You can’t rationalize the portfolio, you can’t justify the spend to a board, and you can’t make a case for expansion or pullback that comes down to anything more solid than anecdote. Most enterprises we talk to are spending six or seven figures a year on AI coding tools and managing that spend with the same rigor most companies apply to office supplies.
Trove emits the cost and usage telemetry the tools themselves already produce, alongside the quality signals — defect density, test coverage, time to resolution — that the OpenTelemetry pipeline carries by default. The combination is what makes the spend legible: tokens in, value out, broken down by tool and by team. That is the first reason Trove exists. The rest of the architecture is downstream of that.
Every vendor’s documentation shows you how to wire their tool directly to your observability backend. It works at small scale, and it breaks at any other scale, for five reasons.
~/.claude/settings.json,
~/.gemini/settings.json, ~/.codex/config.toml, the OpenCode plugin
environment, the Cursor hook scripts, and various shell rc files. Rotating a key turns into
archaeology.OTEL_LOG_USER_PROMPTS=1 exists in
multiple tools. Running one redaction processor in one collector is dramatically safer than
configuring each tool separately and hoping nothing was missed.Trove runs an OpenTelemetry Collector sidecar locally on the developer’s machine. Credentials live in one file that Trove owns. Buffering, redaction, and routing happen once, in one place, the way the rest of your observability stack already works.
If you’re an engineering leader or a platform engineer evaluating this, three parts of the design took the most thought and are worth reading about before you install.
The detection layer. Each tool has its own configuration format, its own file location, and its own schema-versioning quirks. We use a tiered adapter model. Tier 1 patches a native configuration block for tools that support it (Claude, Gemini, Codex, Qwen, OpenCode). Tier 2 wraps an existing IDE hook (Cursor). Tier 3 installs a shell-function wrapper for tools without native OTel support (Aider, Copilot CLI). The architecture documentation walks through the tradeoffs on each tier.
Atomic config patching. Every configuration change Trove makes is bounded by fenced comment blocks, tracked in its own state file, and fully reversible. If you uninstall Trove, your tool configurations return to exactly what they were before installation. We took this seriously because we live in these files too.
The validation matrix. We test each harness/backend pair and record the result. The matrix lives in the repository, and we publish what passes and what’s still pending rather than doing the usual “supports all major platforms” hand-wave.
A few things worth heading off, because they come up.
Trove isn’t a SaaS. No accounts, no backend, no telemetry collected by Intevity. The desktop app talks to your local collector, and your collector talks to your backend of choice.
Trove isn’t a competitor to your observability vendor. Trove forwards to whatever you already use, and if anything, it gives your existing vendor more to work with.
Trove isn’t a governance product. Trove gives you the data. What you do with it — license rationalization, policy enforcement, cost attribution, quality measurement — is your call. We have opinions, and we’re not selling them here.
Trove isn’t vendor-aligned. It is deliberately tool-agnostic. We support every AI coding tool we can detect, and we add new ones as they ship. This is the bet underneath the whole project: the AI tool surface will keep fragmenting before it consolidates, and the practical answer is observability over centralization.
Trove is the second release out of Intevity Labs, the technical track we recently stood up alongside Intevity Insights. It follows Sentinel, our control layer for Claude Code. Where Sentinel is depth on the single tool most enterprise developers are running today, Trove is breadth across the whole portfolio of AI coding tools your team might use. The two are designed to run together, and neither depends on the other.
Sentinel goes deep on Claude Code; Trove goes wide across every tool your team runs. Same posture, complementary axes.Several more tools are in flight, each addressing a problem we hit running AI delivery at scale. The thesis underneath all of them is the same one we’ve started calling dark code: AI-authored output is outpacing human comprehension, and the governance response is still catching up.
The Trove repository is at github.com/Intevity/trove. Install it, break it, and tell us what needs to change.