I don't think I've ever /resumed a Claude Code session even once. What do people use that for? The way I use it is to make a change, maybe document the change, and then I'm done. New session.
Interesting.
What kind of context usage does it have when switching between the two providers? Like is it smart about using the # tokens when you go from claude -> codex or vice versa for a conversation?
How does ctx "normalize" things across providers in the context window ( e.g. tool/mcp calls, sub-agent results)?
Tooling like this is why I really want to build my own harness that can replace Claude Code, because I have been building a few different custom tools that would be nice as part of one single harness so I don't have to tweak configurations across all my different environments, projects and even OS' it gets tiresome, and Claude even has separate "memories" on different devices, making the experience even more inconsistent.
I've actually had the same itch and decided to give it a go ... So far I'm one year into the project, learned a ton and highly recommend to anyone who'd listen - try writing you own harness. It can be fun, it can be intoxicating, it can also be boring and mundane. However you'll learn so much along the way, even if you thought you already were well versed.
Great callout about the prompt caching, this switch is going to burn subscription limits on Claude real real fast.
Unless the goal is to move from one provider to another and preserve all context 1:1. And I can’t seem to find a decent reason why you would want everything and not the TLDR + resulting work.
The way this works is that it stores workstreams and session state in a local SQLite DB, and links each ctx session to the exact local Claude Code and/or Codex raw session log it came from (also stored locally).
Prompt caching is done on the provider side. If you send two requests to a provider in short succession and the beginning of your second request is the same as your first (for example, because your second request is the continuation of an ongoing chat), the repeated tokens are much less expensive the second time.
Obviously, your tool does not provide this. But I think GP is undervaluing the UX advantages of having your conversation history.
Yes that's it. I actually just ask codex/claude code to look up the session id when I want to resume sessions cross harness, it's just jsonl files locally so it can access the full conversation history when needed.
How does ctx "normalize" things across providers in the context window ( e.g. tool/mcp calls, sub-agent results)?
But yeah, after the price hikes, it's inevitable that people will run open source harnesses
Unless the goal is to move from one provider to another and preserve all context 1:1. And I can’t seem to find a decent reason why you would want everything and not the TLDR + resulting work.
The way this works is that it stores workstreams and session state in a local SQLite DB, and links each ctx session to the exact local Claude Code and/or Codex raw session log it came from (also stored locally).
What do you mean by prompt caching?
Obviously, your tool does not provide this. But I think GP is undervaluing the UX advantages of having your conversation history.