Probe0 vs OpenLLMetry
OpenLLMetry watches the calls your application already makes and ships the spans somewhere you can query them. Probe0 sits in the request path on your own machine, so it can answer a call from cache, send it to a local model, or refuse it when a run hits its spend cap.
An open-source (Apache 2.0) SDK from Traceloop that extends OpenTelemetry with LLM-specific instrumentation, exporting traces to Traceloop or any OTel-compatible backend.
| Feature | Probe0 | OpenLLMetry | Edge |
|---|---|---|---|
| What it is | Local proxy on your machine | OTel instrumentation SDK | Even |
| Setup for one developer | One proxy plus a certificate, once | Install SDK, call Traceloop.init() in each app | Probe0 |
| Covers coding agent CLIs | Claude Code, Codex, Cursor, no per-tool config | Instruments code you own and can import into | Probe0 |
| Response caching | Exact cache on disk plus local semantic cache | None, it observes rather than serves | Probe0 |
| Tool-call safety in cache reuse | Refuses to match anything carrying tool calls | Not applicable, never answers a call | Probe0 |
| Routing and fallback | Local models first, tiering, weak answers retried | None, it does not choose the model | Probe0 |
| Spend enforcement | Hard cap per run and per day, warns then pauses | Captures cost data, no request-time gate | Probe0 |
| Attributing cost to the process that spent it | Local ledger records the process behind each call | Spans come from services you instrumented | Probe0 |
| Export to existing observability stack | Local ledger only, no OTel export | Standard OTel to Datadog, Grafana, Honeycomb and more | Competitor |
OpenLLMetry rides on OpenTelemetry, so its spans land in whatever backend a team already runs, and that is a real capability Probe0 does not have. What it cannot do is touch a request. My spend comes out of Claude Code, Codex and Cursor, and what I need from those is a smaller bill, which means something in the path. Probe0 is a local proxy: one install, one certificate, and every coding agent CLI on the machine routes through it with no per-tool configuration. From there it can answer out of the exact cache without touching the network at all, or from the local semantic cache when similarity clears a strict floor and the exchange carries no tool calls, or hand the work to a model already loaded in Ollama or LM Studio and retry on the cloud only when the answer comes back weak.
The structural difference is where the code runs. OpenLLMetry is an SDK you call inside your own process, so it needs a process you control and can import into. Its auto-instrumentation covers a wide surface for that case: OpenAI, Anthropic, Bedrock and Cohere on the model side, Pinecone and Weaviate on the vector side, LangChain, LlamaIndex and CrewAI on the framework side, with SDKs for Python, TypeScript, Go and Ruby. Coding agent CLIs are binaries I did not write and cannot add an init call to, so none of that reaches them. A proxy does not care what language wrote the request or who compiled it, and that is why the same one install covers all three agents and any new one I add later.
I built the spend side because reporting arrives too late to help. Spend Guard is a hard cap per run and per day: it warns, then it pauses. Request Coalescing collapses simultaneous identical calls into one upstream call. Every module switches on and off independently and reports what it saved on its own, so I can tell which one is earning its keep. The ledger stores model, tokens, real cost, latency and which process made each call, which is what lets the plan-tier advice come from actual usage rather than a guess. All of it stays local, and there is no Probe0 server to send anything to, which is the flip side of the OTel row above: nothing leaves the laptop, and nothing fans out to Datadog either. The honest limits are macOS only, private beta, not a team or multi-user gateway, and provider coverage is what coding agents actually call rather than a hundred-provider catalog.
The verdict
Probe0 is the one I would install if your bill comes from coding agent CLIs on a Mac. It takes one certificate to cover Claude Code, Codex and Cursor together, it answers repeat calls off local disk, it sends work to a model you already have loaded, and its cap stops the run instead of describing it afterwards. Take OpenLLMetry instead when the thing you need instrumented is an LLM application you own and its traces have to sit next to your database and queue spans in a backend your team already runs. Those two jobs do not overlap much, and for the money leaving your terminal today, Probe0 is the one in the path.
Questions
- Is Probe0 an OpenLLMetry alternative?
- Only for the cost-control half of the problem. OpenLLMetry is an observability SDK and does not cache, route or cap spend, while Probe0 is a local LLM proxy that does all three but does not export OpenTelemetry traces to Datadog or Grafana.
- Can OpenLLMetry track what Claude Code or Cursor is spending?
- Not directly. It instruments code you can import the SDK into, and coding agent CLIs are binaries you do not control. Probe0 sees that traffic because every AI coding agent on the machine routes through the proxy after a one-time certificate install.
- Does OpenLLMetry cache LLM responses or enforce a budget?
- No. It is an observability layer rather than a request-processing layer, so it records token and cost data for your dashboards but never answers a call itself and never blocks one. Probe0 does both, with an exact cache, a local semantic cache and a hard per-run and per-day spend cap.
- Do my prompts leave my machine with Probe0?
- Only when a call actually goes to a cloud provider. The caches are on local disk, local LLM routing keeps work inside Ollama or LM Studio, and the request ledger stays on your machine. There is no Probe0 server to send anything to.