Cross-CLI Session Management: Shared Memory for AI Coding Agents

Every AI coding session starts with amnesia. Close the terminal and everything the agent knew — what it shipped, what broke, what it planned to do next — is gone the moment the process ends. Open a new session and you start over: re-explaining the task, re-pasting the design, rebuilding the context you already built once. And the problem gets worse the instant you cross a boundary — a new terminal, a new UX, or a different AI model entirely.

This video demonstrates the fix: an internal session-management layer that gives AI coding agents a shared memory across sessions and across model families. Claude finishes the work at midnight, and Codex picks it up in the morning knowing exactly where things stand — no re-briefing required.

Why token cost made this necessary

The frontier labs are ending the era of subsidized tokens. Flat subscriptions are giving way to usage-based pricing, and for teams doing real volume that gets expensive fast. The obvious lever is to run each step of the work on the model that’s best and cheapest for that step — plan on a strong model, build on a fast one, review on an inexpensive one.

Today’s CLIs already do part of this. Inside a single product family you can hand off between tiers: plan in Opus or Fable, then build in a cheaper model like Sonnet; in Codex you can plan on one GPT tier and develop on another. But that handoff stops at the family boundary. If you want the plan written by one vendor’s model and the build done by another’s, there’s no shared context to carry across — because each CLI only remembers its own sessions.

The real problem: sharing context across model families

The goal is to plan with one model and build with a completely different one — say, design with Fable, then develop with Grok — and have the second agent inherit everything the first one figured out. That requires memory that lives outside any single agent, in a place every CLI can read and write.

That’s what the session layer provides: a shared, on-disk session state that any agent can pick up. A brand-new instance of any model, in any terminal, reads the current state first and knows the plan, the design, the open issues, and what to do next.

Seeing it work across three CLIs

The demo runs a real investigation on our Hive knowledge-graph project — figuring out why certain entities were being created in the merge-approval queue when they shouldn’t have been — across three CLIs at once: Claude Code, Grok, and Codex.

1. Create an isolated worktree. A dedicated worktree (entity creation) is spun up for the fix, so the investigation never touches the main working tree.
2. A fresh agent reads state first. Moved into the worktree, Grok’s very first action is to check the session state. None exists yet — nothing has happened — so it simply asks what to do. Grok then evaluates the entity-merge queue and sketches out a design.
3. Hand review to a cheaper model. Rather than pay for an expensive reviewer, the design is handed to Codex — cheaper — for a second opinion. The key move: typing wrap up at the end of the session. The agent writes out a clean handoff and marks the session ready for the next agent.
4. The next agent picks up with zero re-briefing. Codex logs in, reads the handoff — Grok’s design summary and full session state — and continues immediately. Nobody had to re-explain what the design was or why it mattered. Codex reviews it, finds blocking issues, documents them, and wraps up. Session Two saved.
5. Resume in a third model. Finally the work is picked up in Fable, which reads Session Two (Session One investigated the junk entities; Session Two recorded the corrective design), evaluates what Codex changed, and starts the build — all with the accumulated context intact.

Why this changes the economics

Once memory is shared, model choice becomes a per-step decision instead of a per-project lock-in. Route planning to the model with the best judgment, development to the one that’s strong and fast, and review to whatever’s cheapest — including open-source models like GLM running on your own infrastructure. Because the context travels with the work rather than with the agent, you can mix and match models freely and optimize each step for capability and cost.

The result is the ability to assign each part of the job to the right worker and drive token costs down by an order of magnitude — without ever losing the thread between one session and the next.

See it in action

Watch the full walkthrough above. If you’re building AI-driven engineering workflows and want to route work across models without losing context — or you want to see how Hive structures the knowledge graph underneath it all — reach out.