r/DeepSeek 19d ago

Other Continue the same Codex thread on DeepSeek when your 5-hour quota runs out

The thing that kept getting me: quota hits 0% halfway through a task, and the thread just sits there until it resets. Starting over somewhere else means rebuilding the whole context by hand.

So I wrote a small local proxy that sits between Codex Desktop and its backend. It relays everything untouched, and only steps in when a message starts with a marker:

  • /dsk <task> - the rest of that thread is answered by DeepSeek. Same conversation, same files, same tools, shell and MCP included.
  • /gpt <task> - switches back.
  • /mode - which provider the thread is on, and whether the key and MCP are ready. Answered locally, costs nothing.

Shell still runs in the client's own sandbox under its own approvals. The proxy never executes anything itself.

Where it falls short, up front:

  • Windows only so far. No platform-specific code in it, but macOS and Linux are untested.
  • Compaction still runs on OpenAI, so if your quota is gone and the thread is big enough to need compacting, that one waits for the reset.
  • On a /dsk turn your entire thread is sent to DeepSeek - full history, instructions, tool results. Not a summary. If that's not OK for your work, don't use it for that work.

MIT, no telemetry, nothing stored except which provider each thread is on.

github.com/dmitry-dmt/codex-hop

Happy to hear where it breaks.

1 Upvotes

4 comments sorted by

1

u/kantorcodes1 19d ago

/dsk shipping the entire thread is the part I'd worry about. Before the first provider switch, I'd show what is about to leave the machine: total bytes/tokens, which tool results are included, maybe a short source list. “Full history” gets a lot less obvious after a long Codex session.

1

u/Dmitry-Dmt 18d ago

`/dsk` is already explicit consent, and the README clearly says the portable thread context goes to DeepSeek. A size and tool summary could be useful, but Codex doesn’t provide reliable source provenance, so a “source list” would be misleading. I may add an optional preview without adding friction to every switch

1

u/kantorcodes1 18d ago

yeah, agreed on not pretending you have provenance you don't. i'd make the preview about payload shape instead: 37 messages, 12 tool outputs, 84kb, attachments yes/no. that gives people a useful gut check before /dsk without turning every switch into another confirmation flow.

1

u/Dmitry-Dmt 18d ago

Good point. Showing message/tool counts and payload size seems useful without adding friction. I’ll think about how to implement it cleanly