Skip to main content
Glama

Never lose a thread again.

You run an agent inside Elpis, and it becomes Elpis.

Elpis is an open-source fork of OpenAI's Codex CLI that keeps the proven execution foundation while adding explicit context control, durable continuity, auditable pruning, and provider-neutral ownership around the model loop.

Linux verification License Telemetry

InstallFeaturesEvaluationDocs

Elpis v0.2.0 is available for Linux x86_64. Start with the versioned guide or interactive demo. The accepted release passed its exact-source shipping checks. The release tag, not this development branch, identifies the shipped runtime.

Elpis interactive terminal demo

Elpis context audit — selective pruning and evidence trail

Contents

Related MCP server: MCP Agent Memory

Quickstart

Linux x86_64; macOS and Windows are not included in v0.2.0. Review the installer before running it:

curl -fsSL https://raw.githubusercontent.com/MasihMoafi/Elpis/v0.2.0/scripts/install-elpis.sh | bash && ~/.local/bin/elpis

The installer downloads the latest published Elpis Linux binary and verifies its SHA-256 sidecar. RTK is an optional, separate shell-output filter; this installer does not install it. On first launch, choose a provider and sign in or enter its API key.

v0.2.0 is the current release. Smart Prune is experimental and off by default; /prune enables it for subsequent turns without rewriting already-sent history.

What is Elpis

Elpis is a provider-neutral coding-agent environment. The selected model or runtime performs inference; Elpis owns the surrounding working state: context admission, continuity, memory, permissions, tools, evidence, and the terminal interface.

It starts from OpenAI's Apache-2.0 Codex CLI and preserves its execution foundation — terminal UI, patches, permissions, sandboxing, sessions, and tool lifecycle — while adding a continuity- first control layer around it. Change the provider without throwing away the project context. Nothing about the project has to be explained twice.

Different paths. Same roots. One shared project.

Why Elpis

Long sessions fill up with transcripts, file reads, searches, command output, and dead ends. The useful state gets buried in the story of how the agent reached it, while every request pays for more context.

Agents using excessive tool calls and tokens to gather redundant context

Elpis separates the active working set from durable evidence. The next request receives a small, inspectable context; the exact record stays on disk and can be retrieved when it is needed.

Three paired configured historical runs with automatic pruning enabled under the superseded high-frequency setup used one byte-identical prompt, the same model, and the same source commit on both arms. In those runs, peak context per request fell 47–65%; median context stabilized at 26.6–27.1%. Codex peaked above 90% of the window in each run, while Elpis stayed safely bounded in the green zone.

Elpis never modifies a model's own output or a request already in flight. Pruning rewrites only harness-supplied tool output, using a separate model instance sequenced against the main agent.

Core Features

Context engineering

Context is a budgeted working set, not a dumped transcript. Elpis makes admission visible and uses a layered pipeline to keep useful findings while removing disposable exploration:

Elpis Context Architecture

Layer

What it does

When

1. RTK shell-output filtering

Compacts supported command output before it reaches the model.

Before the agent sees it

2. Deterministic safety cap

Bounds exceptionally large tool results. This is inherited from Codex.

Before the agent sees it

3. Smart Prune — Experimental

Optimizes eligible fresh textual tool results before their first main-model exposure; admitted history is not revisited.

Enable with /prune

4. Emergency Ace pruning

Selectively rewrites eligible old tool evidence toward a working-set target, preserving recent context and evidence pointers.

Explicit /force-prune <1-100> only

These controls describe v0.2.0. /prune only enables Smart Prune; /force-prune is a separate emergency history rewrite that may reduce cache reuse. Neither rewrites user instructions, assistant messages, or model reasoning. /compact runs native Codex compaction. See the release context contract.

Historical emergency-pruning example

Task 1 Context Flow and Pruning Lifecycle

One real pass from disk. A search command whose raw output ran to 18,930 characters — close to 5,000 tokens carried across requests:

Before — what the model was carrying:

Script completed · Wall time 0.1 seconds · Output:

tui/src/external_agent_config_migration.rs:800:   item_type: …ItemType::AgentsMd,
tui/src/external_agent_config_migration_flow.rs:75: …ItemType::AgentsMd
tui/src/theme_picker.rs:283:  fn theme_picker_subtitle(home: …) -> String
tui/src/theme_picker.rs:392:     subtitle: Some(theme_picker_subtitle(
tui/src/theme_picker.rs:605:     let subtitle = theme_picker_subtitle(…, Some(200));
tui/src/theme_picker.rs:617:     let subtitle = theme_picker_subtitle(…, Some(140));
tui/src/app_event.rs:152:        OpenAgentPicker,
… roughly two hundred more lines of the same shape …

After — what the model carries on the next request:

[Ace pruned 231 lines of ripgrep output (18,930 chars → 248 chars).
Findings:
- Found ItemType::AgentsMd in external_agent_config_migration.rs:800
- Found theme_picker_subtitle definitions in theme_picker.rs:283,392,605,617
- Full raw output preserved in rollout evidence: rollout://sess-01j8/tool-14.log]

Context Ledger and observability

The Context Ledger (Tab; during an active turn, Alt+C always toggles it) lists admitted goals, rules, memory, and other portable sources with their byte sizes and capped character-derived estimates. Toggling a row writes admission.toml, which controls what the next turn receives.

Development rules are ordinary Markdown Ledger rows, not skills: newly discovered rules start included and an explicit exclusion persists. A nonempty configured development-rule root list replaces the managed fallback; an empty list uses it. Elpis leaves ordinary and bundled skills off by product default, while deliberate user configuration can enable a selected skill. Enabled skills expose compact metadata and keep their bodies lazy; /skills shows available candidates and their origins, but mentions and the model-visible list contain enabled skills only. The Ledger has no skills-catalog token row; its per-source estimates are not tokenizer measurements.

The Context Ledger listing admitted instruction files with their token counts and included state

In v0.2.0, Ledger and /context share category colors and a full-window scale. They distinguish active context usage from locally estimated request categories: user and agent messages, reasoning, tool calls/results, instructions, developer messages, and tool definitions. Category estimates are not provider-billed counts. Available backtrack checkpoints and local evidence links remain inspectable.

Sessions and continuity

Keep the working context across model switches, compaction, and restarts:

  • GOAL.md holds the current task. It is carried into each request, stays visible across compaction, and is editable during a run.

  • ES.md is an event-derived executive summary. It records modified files, commands run, blockers, and next steps, and is updated as the run progresses.

  • Exact resume continues an existing thread with its full history, using the provider-native session when one is available.

  • Lean continuation starts a clean thread from the current GOAL.md, ES.md, and active rules. This sheds old exploration without losing the objective.

Memory

Durable memory is one Markdown file, MEMORY.md, in the Elpis memory directory (derived from CODEX_HOME). The Context Ledger discovers it and lists it as a row, switched off until you admit it: like every optional row, memory does not reach the model unasked.

  • One visible file. Plain text. Read it, edit it, commit it to git, or delete it.

  • Admitted in the open. Because it is a Ledger row, you can always see whether memory reached the model, switch it on when you want it, and drop it when you do not.

  • Retrieval beyond that file is your choice. Register an MCP server — for example rag-mcp-lancedb — and Elpis will use it.

Elpis previously ran an extraction, consolidation, and promotion pipeline. It was removed because it did not work: across two threshold settings it produced zero durable promotions, every sweep landing one recall short of the gate. Memory that rewrites itself in the background without appearing anywhere is the failure mode the Ledger row exists to prevent.

Deterministic work graphs

A coordinator can fan work out to several agents under an engine that validates the plan before anything runs. This is Elpis's own; it is not part of the Codex foundation.

Elpis deterministic work graph

The coordinator submits a complete task graph — tasks, dependencies, write scopes, acceptance criteria, and environments. Elpis then owns the scheduling:

  • Cycles cannot be scheduled. Kahn's topological algorithm proves the graph is acyclic and rejects it otherwise, so no worker is created for a plan that could only deadlock.

  • Write conflicts are caught by construction. Path-prefix intersection detects overlapping write scopes, and all writable tasks in one environment are serialized even when their declared prefixes do not overlap.

  • Verification is not optional. A writable task without a directly dependent verify task in the same environment is rejected before dispatch.

  • Evidence gates progress. Dependent work is released only after an accepted result; a failed, cancelled, or blocked prerequisite blocks its descendants.

Elpis never creates, merges, rebases, deletes, or pushes branches or worktrees. Preparing and integrating them stays coordinator-owned, because those operations change durable user state and deserve deliberate review.

Off by default. Enable with enable_fanout = true under [features]; there is no slash command. Full rules and the graph schema are in docs/WORK_GRAPHS.md.

Bring your own provider

Elpis is not tied to a single model vendor:

  • OpenAI: GPT-4o, GPT-5.6-Luna, o1, o3, and compatible endpoints.

  • Anthropic: Claude 3.5 Sonnet, Claude 3 Opus, Claude 3.5 Haiku.

  • Google: Gemini 2.0 Flash, Gemini 1.5 Pro.

  • Local & self-hosted: Ollama, vLLM, and any OpenAI-compatible server.

Switch models mid-session without restarting. The working context, goal, and session memory are preserved across provider boundaries.

Integrations and tools

Extend Elpis with external capabilities that stay in their own processes through MCP:

  • Workspace retrieval: rag-mcp-lancedb provides local LanceDB/Tantivy search over your documents.

  • Voice transcription: WhisperType provides local speech-to-text without adding its model/runtime dependencies to Elpis core.

Privacy and ownership

Telemetry is off by default and no analytics are uploaded unless you explicitly configure an exporter. Bring your own provider keys. Durable Elpis state is local files and SQLite that you can inspect, edit, export, or delete.

Evaluation status

The published evaluation reports three paired, byte-identical configured historical workloads with automatic pruning enabled under the superseded high-frequency setup, on gpt-5.6-luna (258,400 token context window).

RQ1: Context Reduction & Operating Hygiene

Across those configured historical runs, Elpis maintained working sets within safe operational thresholds.

Peak Context Utilization

In those configured historical runs, Codex expanded into the critical danger zone (>90% window) in every run, forcing 3 emergency compactions. Elpis maintained peak window utilization at 32.5–49.5%, achieving a 47–65% reduction in peak context footprint:

Peak Context Window Utilization (Elpis vs. Codex)

Input Token Distribution & Interquartile Stability

In those configured historical runs, Codex suffered wide distribution variance as transcripts accumulated, while Elpis tightly stabilized median token input at 68.8k–69.6k tokens (26.6%–27.0% of the window):

Input Tokens per Model Call (Interquartile Range & Median across 3 Runs)

Trajectory Dynamics across Context Health Bands

When normalized across the request lifecycle (0% to 100% completion), Codex exhibits unbounded monotonic growth until emergency rollover occurs. The Elpis trace shown here is a configured historical run with automatic pruning enabled under the superseded high-frequency setup; it is not current default behavior:

Normalized Task-Progress View (0%–100% Sequence Overlay)

Operating Zone Breakdown

Across those configured historical requests, Elpis spent over 95% of its operating lifespan inside the safe and healthy bands, with zero requests entering the critical danger zone:

Context operating zones by run

RQ2 & RQ3: Target Retention & Task Quality

  • RQ2 (Information Retention): In benchmark audits testing recall of key file paths, schemas, and error signatures after pruning, 100% of tested targets (6/6) were retained intact in active context.

  • RQ3 (Task Performance): Not established. The executed runs are incomplete and unreplicated, so they do not support a comparative correctness claim in either direction. No per-arm score is reported, and there is no evidence that pruning improves task completion or output quality.

RQ4: Pruning Overhead & Token Economics

The historical history-rewriting configuration added optimizer calls and could invalidate cached prefixes. Its measured totals were 730,810 auxiliary tokens to reclaim 605,377 context tokens (0.83 reclaimed per spent token). These are not v0.2.0 Smart Prune results. Smart Prune acts before first exposure and does not revisit admitted history, but it still adds optimizer work. Controlled OFF/ON cache, net-cost, and general task-quality effects remain unproven. See the release experiment log.

What Pruning Spent to Hold That Window (41-Pass Breakdown)

RQ5: Forensic Auditability

Every pruning event produces an immutable audit record on disk under ~/.elpis/logs/pruning/. In full forensic reconstruction evaluations, 7 of 9 properties were completely recoverable from disk, 2 partial, and 0 absent.

Research Question

Empirical Finding

RQ1 — Context Efficiency

Historical superseded high-frequency setup: peak reduction of 47–65%; median context stabilized at 26.6–27.1% of the 258k window.

RQ2 — Information Retention

6/6 tested post-prune targets preserved intact (100% retention).

RQ3 — Task Performance

Not established. The available runs do not support a comparative correctness claim.

RQ4 — Pruning Economics

Penalty established, current magnitude open. The measured figures describe a superseded high-frequency configuration.

RQ5 — Forensic Auditability

7/9 properties fully recoverable from local rollout evidence; 0 lost records.

Documentation

License

Apache-2.0.

The execution foundation — terminal UI, patches, permissions, sandboxing, and sessions — derives from OpenAI's Apache-2.0 Codex CLI. Elpis extends that foundation with context admission and pruning, continuity checkpoints, auditable evidence, and provider control. Codex-derived source retains its upstream notices under codex-rs/.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    Not graded
    maintenance
    A sophisticated MCP server providing advanced memory capabilities with RAG, hallucination detection, and enterprise-grade AI infrastructure for intelligent agent ecosystems.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    A production-ready MCP server that enables multiple AI agents to collaborate through a shared, concurrency-safe memory space. It supports advanced search, full CRUD operations, and automatic backups to facilitate asynchronous communication between agents.
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A robust, lightweight Model Context Protocol (MCP) server designed to empower your AI Agents with context-awareness, safe execution sandboxes, and dedicated thought logs.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MasihMoafi/Elpis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server