Comment by CharlieDigital | Hacker News Reader

Comment by CharlieDigital | Hacker News Reader

You don't need a proxy to do this. I would argue you should not use a proxy to do this because the end result is a single point of failure direct in the line of your productivity.

Both Codex[0] and Claude Code[1] output OTEL traces that you can ingest and process.

Other harnesses like OpenCode, Pi, etc. you can hook into their plugin architecture and implement your own OTEL emission from a plugin (or use an off the shelf plugin[2]).

Host an OpenTelemetry collector[3][4] or rely on your existing collector infra (e.g. Datadog (no affiliation), AppInsights, etc.)

The OTEL traces will have exactly what you need. Tool calls, full prompts, token usage/cost, etc. It is less intrusive and does not become a single-point-of failure since the OTEL emission and collection is best-effort whereas a failing/overloaded proxy is going to strand your team until resolved. It's OK if you lose some OTEL traces; no productivity lost.

The configuration to enable this for Codex and CC is very straightforward (see [0][1] + [5])

--

[0] https://learn.chatgpt.com/docs/config-file/config-advanced#o...

[1] https://code.claude.com/docs/en/monitoring-usage

[2] https://github.com/DEVtheOPS/opencode-plugin-otel

[3] Open source collector: https://opentelemetry.io/docs/collector/

[4] Sample configuration for filtering noise: https://github.com/zeeq-ai/zeeq-app/blob/main/build/otel-col...

[5] Concrete examples of .codex/config.toml and .claude/settings.json: https://zeeq.ai/docs/key-features/session-telemetry#configur...

Wouldn't a fair criticism of OTEL be that you only see what these harnesses are willing to show you?

There have been numerous scandals of AI companies offering CC/cursor alternatives, then indexing data they never should have; specifically Z.ai [0], ByteDance Trae [1] and Alibaba Qwen [2]. Maybe the argument should be that all harnesses should be sandboxed and monitored for all networking.

If it were me, all AI harnesses would be running on a VM with network logging enabled. Beyond not being able to trust what data they send via the harness, you should audit what data they access.

[0] https://www.chosun.com/english/industry-en/2026/09/22/ABYLC3...

[1] https://github.com/segmentationf4u1t/trae_telemetry_research

[2] https://github.com/QwenLM/qwen-code/issues/11198

Well if you own the harness ( and you should ) you see everything you want.

But I’ve seen approaches using eBPF to collect telemetry to OTEL

Sometimes, it gets to very hacky solutions, such as what we did at Laminar with Claude Agent SDK. Basically we spin up a tiny in-process proxy that intercepts requests and responses and emits the telemetry as OTEL traces. We repoint the Python / JS SDK to convince the harness that our proxy is the anthropic URL, and the proxy then forward the request downstream. I wrote about it some time ago [1]. This is definitely not elegant, but it generally works.

[1] https://laminar.sh/blog/2025-12-03-claude-agent-sdk-instrume...

Otel is only a quarter of what the llm proxies solve for you. What happens when an agent goes down some random rabbit hole and burns through $100 before you even notice? It's nice to have post-disaster visibility with Otel, but even self hosting an LLM proxy prevents the disaster.

Shameless plug, I've been building Relay for this exact reason. You get real-time visibility into what your agents are doing, how much they're spending, and can set hard limits so things don't spiral out of control. Plus a lot of other features they bring to the table if you want.

It's open source and self-hostable too.

https://github.com/anchorshell/relay https://anchorshell.com/

You can do that with MCP or hooks as well.

not really, for example relay gives you model "groups" ie: fallbacks if one is down, or prefer to use a free-endpoint while you have daily capacity, etc.

Maybe you need a decision model to route, or maybe you want to have guardrail-type models pre or post response for an enterprise client.

https://github.com/tzachbon/claude-model-router-hook no?

Disclosure: I work on Origin [1]. We built a platform for enterprises that consumes OTEL, and other traces without a proxy or an LLM gateway. We even support collecting traces from local inference workloads.

For supported tools, we collect prompts, responses, and tool calls, then tie them to the user, organizational context and what actually happened on the machine. We can then use this data to detect when agents (or the people piloting them) do bad things [2].

--

[1] https://www.originhq.com/

[2] https://www.originhq.com/investigations

That shows what you do, not what the proxy does with your queries

If you are using a Datadog, Langfuse, Langchain, or other OTEL target, you do nothing. Just query it. Build alerts, dashboards, and datasets; whatever you normally do with your OTEL collector. A forward OTEL collector deployment is still useful for filtering but the Datadog Agent, for example, already has buffering and filtering built into it.

If you want to deploy your own collector and write your own handler (e.g. put it into a database), you can generate the stubs for the OTEL payloads and convert to domain records.

1. Get the protos here: https://github.com/open-telemetry/opentelemetry-proto

2. Generate the type/class stubs and endpoints for your platform.

3. I strongly recommend pre-filtering with the open source `opentelemetry-collector` before your custom endpoint handles the inbound telemetry payload. The collector is optimized for performing the filtering and I put it upstream of my custom ingest endpoint on a very small VM just to pre-filter and perform auth checks[0][1] on the inbound channel.

4. Do what you need to with the inbound payloads. Examples below:

- Ingest endpoint (Codex/Claude -> OTEL collector -> API): https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...

- Codex telemetry adapter: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...

- CC telemetry adapter: https://github.com/zeeq-ai/zeeq-app/blob/main/src/backend/Ze...

I run my backend on Postgres with partitioned tables. You can forward to Elastic or other OLAP-type database targets for querying. You can see examples of what I do with the session telemetry here: https://zeeq.ai/docs/key-features/session-telemetry

[0] https://github.com/zeeq-ai/zeeq-app/blob/main/build/otel-col...

[1] https://github.com/open-telemetry/opentelemetry-collector-co...

You can build a proxy setup that is not a SPOF.

Sure, but OTEL has all of the right qualities for the majority of use cases here.

Standards based, many off-the-shelf providers, out-of-process + buffered by default, many standard processors for traces + spans, many tools for storing and querying.

OTEL is pretty widely supported and mostly "just works" at this stage of maturity. A failing/mis-configured OTEL endpoint/collector isn't going to stop you from getting work done in the same way that a failing proxy is. You'll drop some traces, but that's probably OK in most cases.

There is a place for proxies, but those places should share the same failure boundary mode. Meaning if the proxy fails, it should necessarily stop forward agent activity. Example: proxy injection of secrets instead of local acquisition.

IMO, a key place for proxies is resource access where the client is not fully trusted (or for any reason it may fail to log correctly).

AI agents seem like a pretty clear case of this. Both because of recent issues, and that they tend to run on end user devices where strict compliance is harder to maintain.

Reply on news.ycombinator.com