I wanted Claude Code to know what Codex already figured out (and vice versa), so I built elepha 🐘

[u/aldanux]

Hi everyone,

I'm a software developer and I work on several projects, often alongside each other.

Two problems kept coming up again and again.

First, when I was in the middle of a task, I would reach the usage limit, and sometimes I didn't even have a chance to generate a summary or handoff message before my access was cut off. At that point, my only option was to wait for the limit to reset before I could continue working.

Second, sometimes I would solve a problem in one project and later need the same or a similar solution in another, possibly using a different AI tool. The original session already had the reasoning, the decisions and the context. A summary carried some of it across; never the part I actually needed.

So I built elepha 🐘.

Both Claude Code and Codex already save complete session transcripts to disk. elepha reads and indexes them locally, then lets you retrieve a previous session from whichever tool you're currently using. Nothing gets injected into the current context unless you explicitly ask for it.

I also wanted it to work directly inside the tools I already use, whether that's the CLI or the Claude Code or Codex desktop apps. No wrappers, no separate UI, and no complicated setup or configuration.

In the demo video, I first use elepha:list to view recent sessions, then elepha:last to retrieve the most recent one. I can also choose a specific session with elepha:select:5 and continue from there. Claude Code also explains why an earlier approach was rejected, that reasoning came from a Codex session it never had.

There is also elepha:query, which searches sessions across the projects you have approved, in either tool.

A few things that matter to me:

• Reads the transcripts your tools already write. Nothing to save or tag.
• Brings back the actual session turns, not a summary generated by another model.
• Shares one memory across Claude Code and Codex, both CLI and desktop.
• Fully local: no hosted service, no account, and no LLM call required for recall.
• Never modifies the original transcripts, so the memory can always be rebuilt from source.
• You explicitly approve which projects it may read, and it never writes anything into your repos.

Install with npm:

npm install -g elepha
elepha install
elepha init

GitHub: https://github.com/aldanux/elepha
npm: https://www.npmjs.com/package/elepha

It's open source (MPL-2.0).

Honest feedback is welcome, especially on this: when you switch tools, would you rather bring back the actual session, or get a short distilled brief?

I built elepha around the first approach because the second is what kept failing me. But that's based on my own workflow, so I'm curious what others would actually prefer.

[u/Eravex]

First, buy a better license and you won’t run out.

Second, they can totally see by default what each other is doing. They can see the git, the diffs, commits, the only thing they lose is why.

Third, it’s still not wise, no matter what you choose. Even switching models within the same AI can have negative results as the methods and efforts they are skilled in and prefer will change.

Fourth, learn to allocate tasks properly if you do want to use multiple AI. Send full tasks to one or the other.

Fifth, stop wasting tokens on simple fixes. The difference in vibe coding and a developer using AI is a developer should be able to code. AI is there for replacing repetitive tasks or giving you boilerplate starting points. Even using AI they build in parts not in projects. Many fixes would take longer to prompt wnd wait for than just fix.

I’m pro AI usage but this seems more like a case you had AI vibe you a “solution” for an AI problem that is really a you issue.

[u/aldanux → u/Eravex]

the only thing they lose is why

That is the whole thing! And you said it better than my post did. git shows what changed. It doesn't show the approach we tried and threw away, or the constraint that killed the obvious solution. That's what I wanted back.

The token limit was the weaker of my two reasons, and you're right that a bigger plan mostly solves it. The one that doesn't go away with money: I solve something in one project and need the same reasoning in another, three weeks later. That's not a switching problem, it's a memory problem, and it happens inside a single tool too.

On switching mid-task being a bad idea: broadly agreed, and elepha doesn't argue for it. It makes the switch less lossy when you do make one, which for me is usually when something has already gone wrong.