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...
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/
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].
--
That shows what you do, not what the proxy does with your queries
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