# Why I quit SaaS AI observability tools and built a local proxy instead

> Source: <https://dev.to/houleixx/why-i-quit-saas-ai-observability-tools-and-built-a-local-proxy-instead-2i7n>
> Published: 2026-06-14 02:02:55+00:00

I've been using Langfuse and Helicone for the last 6 months. They're great products. Their teams are sharp.

But they don't work for coding agents.

| Tool | Architecture | Works for coding agents? |
|---|---|---|
| Langfuse | SDK + async upload to SaaS | ❌ Need to instrument the agent |
| Helicone | HTTPS proxy via HTTP_PROXY | ❌ CLIs ignore HTTP_PROXY |
| Datadog LLM Obs | APM agent | ❌ Same problem |
ccglass |
Local loopback reverse proxy | ✅ Yes |

The reason: Claude Code, Codex, OpenCode, Kimi, etc. are **native CLIs** (Node, Rust, Go). They make HTTPS calls directly to the API endpoint. They do not respect `HTTP_PROXY`

environment variables.

So the standard observability play — "just point your SDK at our proxy" — doesn't work. The agent isn't using a library that knows to call your endpoint.

I needed something that would:

`http://127.0.0.1`

)I built it. It's called [ccglass](https://github.com/jianshuo/ccglass). It does those 5 things. Nothing else.

``` bash
$ npm i -g ccglass
$ ccglass claude
# → starts proxy on http://127.0.0.1:8123
# → overrides ANTHROPIC_BASE_URL to point at it
# → spawns claude
# → opens dashboard at http://127.0.0.1:8123
```

The dashboard shows:

If you use a coding agent heavily, and you don't know which of your prompts are 4,000 tokens of accidental repetition, you're leaving money on the table.

The first time I saw my own cache hit rate (38% — meaning I was re-sending the same system prompt 38% of the time and not knowing it), I had a "wait, that's literally me paying for nothing" moment.

Try it once. The data is eye-opening.

🔗 GitHub: [https://github.com/jianshuo/ccglass](https://github.com/jianshuo/ccglass)