DEV Community

Cover image for The Proxy That Documents Its Own Memory
Reno Lu
Reno Lu

Posted on

The Proxy That Documents Its Own Memory

The most telling part of the opencodex README is a collapsed details block most readers will never open. Inside it, the author lists 36 categories of process-retained state and the bound on each one: 12 byte-accounted stores under a 256 MiB budget, 4 buffers watched for in-flight byte pressure, 24 state-store registrations swept every 60 seconds. That is not how people document a weekend project. That is how people document something they expect to leave running for a month.

The headline pitch is much simpler. Install the npm package, run ocx start, and Codex, Claude Code, Claude Desktop, and Grok Build will talk to Anthropic, Gemini, xAI, Kimi, DeepSeek, Ollama, or any OpenAI-compatible endpoint you point them at. The proxy listens on localhost:10100 and translates Codex's Responses API into whatever the provider speaks, in both directions, carrying streaming, tool calls, reasoning tokens, and images across. The client UI never changes. As the README says under the Claude Code demo, the picker is stock Claude Code, the brain behind it is not.

Translation is the easy half

Anyone who has written an API shim knows the shape of that work. Map the request fields, map the response fields, handle the streaming format, ship it. What separates a shim from something you leave running in your shell is everything after that.

Look at what this process accumulates while it lives. A request log for the dashboard. Debug ring buffers. An image cache. A model cache per provider. Vision descriptions produced by the sidecar. Cursor blobs and responses-continuation state, because the Responses API is stateful and the provider underneath usually is not. Every one of those is a map that grows. The README's claim is that no unbounded Map or Set survives a config reload, and that GET /api/system/memory, behind the admin token, reports live retained bytes, eviction counters, and watchdog samples. You can argue with the specific budgets. You cannot say the author skipped the question.

The health surface reads the same way. /healthz answers whether the process is alive. /readyz answers a different question, post-sync readiness, returning 503 with Retry-After: 1 while status is pending or terminally failed, and a sanitized identity payload of service, version, uptime, pid, port, and status when it is ready. Two endpoints because liveness and readiness are genuinely different states, a distinction most local dev tools never bother to draw.

Account pooling is a scheduling problem

The ChatGPT account pool is where the design gets opinionated. Add several ChatGPT or Codex logins, refresh their 5h, weekly, and 30d quota from the dashboard, and under quota routing new sessions go to the lowest-usage healthy account. Round-robin and fill-first policies are there too. Existing Codex threads keep affinity to the account that started them, so a long SSH, tmux, or mobile-connected session does not change identity halfway through a conversation.

Then the README does something unusual. It lists the cases where that pin breaks: quota re-evaluation, failover, account exclusion, affinity expiry, and 401/403 or 429 recovery. Affinity is a preference, not a guarantee, and saying so plainly is the difference between documented behavior and a future bug report. You can also give the accounts a selection order for the case where one login, usually your Codex Desktop account, should only be reached for once the others are drained.

A note on who gets to decide

Buried in the agent-facing quickstart is a rule worth stealing. An interactive ocx start may ask once whether to star the repository. The CLI suppresses that prompt for agent-driven runs, and the API refuses it outright with 403 agent_consent_required.

Starring a repo is a trivial action. Treating it as something only a human may authorize, and enforcing that at the API boundary instead of in a comment, is a real position on what an agent may do while wearing its owner's credentials. If you build anything that runs unattended, copy the pattern: decide which actions carry the user's identity, then make the code refuse to take them on a machine's say-so.

Everything else here is a proxy. A carefully kept one, which is the rarer thing.


GitHub: https://github.com/lidge-jun/opencodex


Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Top comments (0)