Put Any Model Into Elpis, and It Becomes Elpis
I just released Elpis, an open-source terminal agent shell built around one idea:
Put a model into Elpis, and it becomes Elpis.
The model should not be the agent.
You should be able to move between models and providers while keeping the things that actually define your agent: its goal, context, memory, rules, evidence, and working state.
That is what Elpis is trying to do.
GitHub: https://github.com/MasihMoafi/Elpis
The problem with long-running coding agents
Coding agents are extremely useful at the beginning of a session.
Then the session grows.
They read files, run commands, inspect logs, try things that fail, retry, generate patches, and accumulate thousands of tokens of intermediate work.
Eventually the useful state is buried inside the history.
The model starts receiving an increasingly large transcript simply because something happened earlier—not because it still matters.
Then comes compaction.
Or a new session.
Or you decide you want another model.
Suddenly the agent that understood what you were doing no longer really exists.
You explain the project again.
You explain the decisions again.
You remind it what worked and what failed.
That felt backwards to me.
Context should be managed, not accumulated
Elpis treats context as a managed resource rather than an ever-growing conversation.
After work has been done, large transient outputs such as command dumps, file reads, and failed probes do not need to remain inside every future model request.
Elpis can replace older transient material with compact representations while keeping the exact underlying evidence available.
The important distinction is:
Removing something from the model's working context is not the same as deleting it.
The transcript and artifacts remain available.
They simply stop consuming the active context window by default.
You should be able to see what the model sees
One thing that bothers me about current agents is how opaque context becomes.
You know there is a context window.
You know things are being added and removed.
But what, exactly, is the next request going to contain?
Elpis has a Context Ledger for this.
Goals, checkpoints, rule files, added files, and other admitted sources are visible individually.
The idea is that context should become something you can inspect and reason about rather than invisible state hidden behind the agent.
Sessions should have continuity without replaying everything
Elpis separates the durable state of the task from the transcript.
The current goal lives in GOAL.md.
A lean execution checkpoint lives in ES.md.
That means a session can continue from a compact representation of:
- what we are trying to accomplish,
- what has already happened,
- important decisions and constraints,
- the last verified result,
- and the next useful action.
The entire conversation does not have to be replayed just to reconstruct that state.
You can still resume the exact native thread when that makes sense.
But you can also start a lean continuation.
Memory should be earned
I also didn't want "memory" to mean dumping every conversation into a giant persistent file.
Most things an agent encounters do not deserve permanent memory.
Elpis keeps evidence searchable and allows information to become durable memory only after demonstrating repeated usefulness across different contexts.
Memory therefore becomes selected reusable knowledge rather than another transcript.
And when durable memory is removed or reset, Elpis archives it rather than silently destroying it.
The model is a runtime
This leads to the part of Elpis I find most interesting.
The surrounding agent environment does not have to belong to one model provider.
Elpis can sit underneath different runtimes.
The runtime performs the model loop.
Elpis owns the surrounding continuity.
So you might use Codex today, another provider tomorrow, or eventually a local model.
The underlying intelligence changes.
The agent does not have to start from zero.
Its goal is still there.
Its memory is still there.
Its context rules are still there.
Its evidence is still there.
Its working state is still there.
Put a model into Elpis, and it becomes Elpis.
Why Rust, and why Codex?
Elpis is written primarily in Rust and its execution foundation comes from a deliberately reduced fork of OpenAI's Apache-2.0 Codex CLI.
That gave the project an already hardened base for terminal interaction, patches, permissions, sandboxing, sessions, and command execution.
I've been building the Elpis control layer around that foundation rather than rebuilding a coding-agent execution environment from scratch.
The goal is not to create another skin around one API.
The goal is to make the surrounding agent persistent, inspectable, and increasingly independent of whichever model happens to be underneath it.
The first release
This is still early.
There are parts of the context-management system I want to push substantially further, particularly post-turn pruning and making the amount of context saved after each turn directly visible.
But enough of the architecture now exists that I wanted to release it and see whether this model makes sense to anyone besides me.
Elpis is open source and MIT licensed.
For now, the main target is Linux x86_64.
From a checkout:
git clone https://github.com/MasihMoafi/Elpis.git
cd Elpis
scripts/install-elpis.sh
If you're working with coding agents for long sessions, I'd particularly like to know:
Does separating the agent from the model runtime make sense to you?
And how much control do you actually want over what enters an agent's context?
Top comments (0)