UltraContext polls your agent session files and ships them to an API

It globs three session directories and polls them

The mechanism is more concrete than the pitch suggests. UltraContext does not ask your agents to cooperate; it reads the files they already write.

The shared environment file names the sources with glob patterns: Codex sessions under `~/.codex/sessions/**/*.jsonl`, Claude Code projects under `~/.claude/projects/**/*.jsonl`, and OpenClaw sessions under `~/.openclaw/agents/*/sessions/**/*.jsonl`. Three booleans, one per agent, let you turn ingestion on and off individually, and a separate flag keeps Claude subagent sessions out of the ingest by default.

On top of that sits a daemon that polls on a timer, with the interval set to 1500 milliseconds, plus log level, verbose and append toggles. It maintains its own state in a local directory: a config file, a SQLite database for the daemon, a lock file, an info file carrying its runtime details, and a log file. The dashboard talks to it over a websocket bound to the loopback address on an ephemeral port, chosen at runtime rather than fixed.

So the architecture is a file watcher with a local database and a terminal UI, and the interesting question is not how it captures but where it sends.

The default destination is a hosted API, not your disk

This is the part to read before installing. The environment file sets the base URL to a hosted endpoint and expects a live API key in the same block, and the quick start does nothing to change that: you install the CLI globally, run one command to start sync, and the captured context goes to the service.

Everything the README describes follows from that. Context captured from your Claude Code and Codex sessions becomes queryable by any agent with the MCP server attached, which is how the example requests work, such as asking Codex to fetch the last plan Claude Code made and implement it, or asking what a named teammate is working on right now.

The alternative is in the repository rather than in the quick start. The monorepo root has scripts to bring up a local database with Docker Compose, run a migration script from the API app, and generate a local development key. Self-hosting the API is therefore a supported path with real work in it: a database, a migration, a key, and a base URL pointed at your own deployment.

For an open-source project that is an honest split, but it is worth being explicit that the path of least resistance sends a transcript of your coding sessions to someone else's server.

The MCP server is what makes agents aware of each other

Three pieces ship in the box, and the MCP server is the one that changes how agents behave.

The CLI ingests sessions and shows a terminal dashboard. The Context API stores, versions and retrieves context. The MCP server is what exposes that context to agents, either built into the API or run standalone over stdio, so attaching it to a client is what gives that client awareness of what the others have been doing.

The difference from asking an agent to read a file is that the context arrives as context, in the form the agent expects, rather than as a document it has to interpret. The framing is that this works like having a context engineer present everywhere, and the practical effect is the three example requests: continue a session in a different agent, ask what the team is building, ask what one person is working on.

Forking is mentioned alongside those, which implies you can branch a captured context and take it in a different direction, leaving the original intact.

Five methods, and every change is a version

The Context API is deliberately small, and the git analogy is the design.

There are five methods: create, get, append, update and delete. Every change creates a new version, so full history is a property of the data model rather than something you enable. You can jump to any point in a context's history, and the documentation has guides for storing and retrieving, editing, forking and cloning, and viewing history.

The JavaScript and Python SDKs mirror each other closely. The JavaScript one is asynchronous and takes an object with an API key:

import { UltraContext } from 'ultracontext';

const uc = new UltraContext({ apiKey: 'uc_live_...' });

const ctx = await uc.create();
await uc.append(ctx.id, { role: 'user', content: 'Hello!' });

// use with any LLM framework
const response = await generateText({ model, messages: ctx.data });

The Python one is synchronous and returns dictionaries:

from ultracontext import UltraContext

uc = UltraContext(api_key="uc_live_...")

ctx = uc.create()
uc.append(ctx["id"], {"role": "user", "content": "Hello!"})

# use with any LLM framework
response = generate_text(model=model, messages=uc.get(ctx["id"])["data"])

Both hand you a messages array and say to use it with any LLM framework, which is the framework-agnostic claim made concrete: there is no agent runtime here, only a store that produces a message list.

The CLI is four commands and a wizard

Installation asks for Node 22 or newer and one global install:

npm install -g ultracontext

Running the binary with no arguments starts sync, which is described as starting the daemon and the dashboard together. The rest is four subcommands:

ultracontext sync     # start sync (daemon + dashboard)
ultracontext stop     # stop daemon
ultracontext config   # run setup wizard
ultracontext update   # update CLI globally

There is no documented flag for pointing the CLI at a different API host, no documented flag for a different data directory, and no documented uninstall command. The configuration wizard is the documented way to change settings, which means the initial configuration is interactive rather than declarative, and a headless or scripted deployment has to go through the environment file instead.

That asymmetry is the practical limit on this tool. Interactive setup is a reasonable choice for one developer on one machine, and it does not scale to provisioning several workstations.

A resume path that writes back into the agent's own directory

The last piece of configuration describes the one feature that goes in the opposite direction from ingestion, and it is the most consequential setting in the file.

The resume workflow pulls sessions from UltraContext back into an agent. It has a context limit of 200, a source filter that defaults to all, a summary tail of 14 lines, a flag to open a new tab, and an output directory pointing at `~/.codex/resume`.

So the loop is closed: UltraContext reads JSONL out of your agents' directories and can write files back into one of them. The settings are deliberately conservative, with a bounded context and a short summary tail, but the capability is the one to think about, because it means the tool can author files that another agent will treat as its own history.

The identity fields sit alongside it. There is a daemon engineer identifier with a placeholder value, a host field left empty, and separate log toggles including one for appends, which is what you want if you are reconstructing a session from appends rather than trusting the agent's own transcript.

Five months of commits since the last tag

Maintenance is the last thing to check and it needs care in both directions.

The repository is not archived and the last push was on 2026-09-12, so work is happening. The newest release is v1.6.0 from 2026-04-20, with v1.5.0 a week earlier and a v1.4.13 two days before that. That is a five-month gap between the last tag and the last commit, and no changelog entry in the repository explains what happened in between.

The documentation is hosted rather than in the tree. There is a quickstart guide, a set of practical guides, a full endpoint reference and a changelog, all on the project's own site, and the repository itself holds the README, contribution guidance, and the agent instruction files.

The licence is Apache-2.0, and the code is a pnpm workspace with SDK packages, a sync package, an API app and a Postgres app. That is a real open-source codebase around a service, which is exactly the shape to evaluate carefully: read the client and the protocol you care about, then decide whether the server has to be yours.

Editorial conclusion

UltraContext suits a developer or team already running several coding agents who keeps re-explaining context and wants one agent to pick up another's plan, and it is worth an afternoon if you can point its base URL at infrastructure you control. It does not suit anyone whose agent transcripts are confidential and who cannot self-host the API, because the documented quick start sends them to a hosted service. Verify first that the three session globs match where your agents actually write their logs, that you have read the terms for what leaves the machine, and that the automatic versioning gives you a deletion path for context you would rather not keep.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ultracontext/ultracontext on GitHub