Orbital stores coding-agent context as local files so any agent can pick up the work

A project agent rather than another session

An open-source project called Orbital, which reached the front page of Hacker News on 18 September, targets a specific annoyance of AI-assisted development: context that dies with the session. According to the project's GitHub README, published under the username zqiren, Orbital is a "project agent" — a coordinator that stays responsible for a project across tasks, sessions and worker agents, while the coding assistants it dispatches become interchangeable labour.

The scenario the README opens with will be familiar: Claude Code hits its usage limit three rounds into a design discussion, and although unused Codex quota is right there, Codex knows nothing about the goal, the decisions already made or the half-edited files. The human is left restating goals, hunting for artifacts and shuttling context between tools to keep their own project moving.

Context stored as plain files

Orbital's answer is to treat the project, not the session, as the durable unit of work, and to express that project as ordinary files in the local folder. The README says it maintains five things that normally fragment between sessions:

• State — what is currently true, kept in PROJECT_STATE.md
• Decisions — what was settled and why, kept in DECISIONS.md
• Lessons — heuristics the project has accumulated, kept in LESSONS.md
• Work — a task queue in queue.
• Artifacts — the workspace itself plus agent output under orbital/output/

On a cold start, Orbital assembles these files into its system prompt before acting. When it delegates, the worker is pointed at the same files and told to treat them as the authoritative record, with the briefing generated anew for each dispatch rather than pasted in by hand. Each worker also keeps a personal memory file inside the project so it builds experience across dispatches, and Orbital records what matters from the result back into the project files when the task finishes.

One detail stands out: enforced closure. Every queued task must end as either Completed or Blocked. An agent that stops without a verdict is re-prompted and then force-marked Blocked with the reason recorded — an attempt to keep unfinished work from disappearing without a traceable outcome.

Which agents it can drive

Per the README, Orbital drives Claude Code through its SDK, Codex through its app-server, and Gemini CLI, Cursor and other tools through PTY or ACP connections. A comparison table dated July 2026 — the project's own, not an independent benchmark — argues that memory, scheduling and sub-agent features are now common, and that the real differences are three: whether a different agent can pick up the next task, whether queued tasks are forced to a terminal state, and whether budget, approvals and audit trail sit with the project rather than the tool. It credits Claude Code with permissions and run history and Codex with approvals and enterprise audit, scoring both as partial on the questions Orbital claims to answer fully.

Local-first with bring-your-own keys

The README is explicit that Orbital is not a cloud service; everything runs on the user's machine. Setup is claimed to take under five minutes with no Python or Node runtime required, and the tool supports DeepSeek, Anthropic, OpenAI, Moonshot and roughly a dozen other providers through user-supplied API keys, with a separate sign-in path offering free tokens in mainland China. Optional connectors cover Google Calendar and Drive, and site logins for services such as Google and GitHub so agents can browse without hitting CAPTCHAs.

Other stated features include remote supervision from a phone — approving actions, browsing workspace files, uploading to them — plus budget controls, autonomy presets and credentials stored in the OS keychain. Full autonomy is explicitly not implemented yet: the system is scheduler-driven today, with broader autonomy on the roadmap. The README also says the agent loop was built from scratch and is not a fork of OpenClaw.

Why it matters

Per-session memory is becoming a weak link in multi-agent development. If a project's state, decisions and lessons live in portable Markdown and JSON, the model doing the work becomes a swappable component: developers can rotate to the strongest model, spend spare quota elsewhere, or match a tool to the task without losing momentum. Plain files are also diffable, auditable and vendor-neutral in a way proprietary session history is not. The caveat is that every claim here — including the comparison table — comes from the project's own README, and the reliability of its cold-start prompting and closure enforcement has not been independently tested. Because the code is open source, anyone can run that test, and the core idea, that context should outlive whichever agent produced it, speaks to a problem most heavy users of coding agents now hit.