mdflow — Context OS for AI Coding Agents

Give your agent an exoskeleton

[ContextOS desktop walkthrough]

ContextOS is a local development runtime between an AI coding agent and your repository. It keeps source evidence, command logs, plans, architecture, and verification receipts outside the main conversation, then returns the pieces needed for the next decision.

OS supports the entire AI development lifecycle: understand the project, plan, inspect evidence, execute, implement, verify, review, and resume. Precise reads, reusable commands, pipelines, Blocks, Chains, persistent plans, Micro, and CLI all serve the same purpose: reduce unnecessary token consumption and context occupancy while keeping development grounded in inspectable project state.

Your existing coding assistant stays in charge. OS supplies the execution and memory layer beneath it, including bounded API Micro assistance and isolated CLI implementation when a task benefits from delegation.

In a recorded real development task, the full OS + Micro + CLI workflow reduced peak main-thread context by 63.8% and main-thread cumulative raw tokens by 77.4% compared with native tools. See the task, comparison, and limits below.

Why long coding sessions get expensive

A small question often triggers a large file read. A failed test fills the conversation with logs. The agent revisits the same code, repeats a command, and spends its attention reconstructing decisions made earlier. Multi-file implementation then shares the same context window as planning and review.

The result is familiar: a crowded conversation, repeated explanations, uncertain project state, and less room for the next useful decision. A larger context window postpones the problem; development needs a way to carry this work across tools and sessions.

How OS carries the work

You → Main agent: plan, scope, architecture, review          │          └─ ContextOS: evidence, commands, changes, persistent state                ├─ API Micro: bounded discovery, summaries, small checks                ├─ CLI worker: isolated implementation → report → integration                └─ Desktop App: architecture, plans, checkpoints, settings

Evidence and logs are saved locally. Workers read task evidence in their own contexts and return compact reports. Changes pass through OS so file ownership, verification, and the project graph stay connected. A fresh session can recover the plan and receipts instead of reconstructing the entire transcript.

Capabilities and their practical effect

Micro and CLI help when the task contract is clear. A small deterministic read can use OS directly; a broad implementation belongs to a CLI worker. Delegation has overhead, so OS makes its execution and results inspectable.

Three development workflows, measured

The recorded comparison started from commit 0dd6431. Fresh host conversations and isolated worktrees received the same real feature: plan dependency add/remove/list, persistence, validation of unknown targets, duplicates, self-reference and cycles, MCP routing, and tests across domain, application, storage, and MCP layers. Historical measurement record.

What “60% less context” means here: peak input to a main-agent request fell from 234,174 to 84,681 tokens. It describes this measured task, rather than a promise for every repository or the combined tokens of every worker.

python3 docs/benchmarks/plan-dependencies/recalculate.py --check

See your project in the App

The desktop App projects the same OS state that agents use: Blocks, Chains, plans, checkpoints, rules, and knowledge. Its white canvas, restrained color, and precise connections make a large project readable.

[Live Block and Chain architecture canvas]

Read the whole system at a glance. Follow a Chain through its Blocks, inspect the selected capability, and see implementation and verification progress alongside the graph.

Install with one prompt

Paste this into your AI coding assistant:

读取 (https://github.com/yubinbin32-ops/ContextOS/blob/main/setup.md) ，为我安装OS

The agent reads setup.md, installs OS and matching host plugins/skills, registers your repository, configures API Micro and your CLI, and verifies the result with real tool calls. It handles dependency checks, adapter creation, plugin setup, and diagnosis for you.

You do not need to download and configure a Release package by hand. The setup guide is written for the installing agent, including diagnosis, adapter configuration, plugin installation, and acceptance checks.

Micro is required

Micro is the small assistant for routine work, and its API connection is required for the OS workflow. Prepare an API key, provider base URL, and model. A main-agent subscription or CLI login alone does not configure API Micro.

Recommended options:

• Command Code GOAT: includes Provider API access. Create a key in its console; let the agent use the provider's current endpoint and exact model ID.
• OpenCode Go: provides a subscription API key and available coding models. Have the agent check the current model list and API configuration.
• Your own compatible API: use a provider you already trust, including the DeepSeek API.

For bounded Micro tasks, we recommend DeepSeek V4.1 Flash with medium reasoning where the provider supports it. The official DeepSeek model ID is deepseek-flash; gateways can use different IDs. The installer must verify model availability and map the provider's reasoning setting instead of assuming every API accepts the same parameters.

Keep the key in the local credential/configuration path established by the installer. Do not paste it into repository documentation or tracked source.

CLI setup is completed by the agent

CLI workers require a working CLI installation, an adapter, the matching ContextOS plugin/skills, and a verified authenticated execution path. Tell the agent which CLI you use; it should consult that CLI's official documentation, write the adapter, configure OS, and run a real probe and isolated implementation check.

A login, browser authorization, or operating-system permission may require your action. The agent should identify that exact step, continue the remaining setup, and verify readiness after you complete it. A discovered binary or saved adapter alone is not a successful installation.

Node.js 22 or later is required. After a plugin/runtime update, reload the host's MCP process as directed by setup. Keep the App, plugin, skills, and runtime on matching versions.

Daily use, in ordinary language

The main agent keeps the acceptance criteria and final review. Micro and CLI take bounded assignments; OS retains the evidence and progress between them.

What's new in 3.0.0

The 3.0 line, prepared from 4706c38, restructures ContextOS into an exoskeleton for the full AI development lifecycle:

• Precise evidence and reusable commands keep source inspection and execution results focused and recoverable.
• Pipelines and verified changes connect batched execution, scoped edits, and reviewable results.
• Architecture and continuity keep plans, tasks, sessions, Blocks, Chains, and receipts available across conversations and in the desktop App.
• Task-appropriate delegation adds bounded API Micro assistance and isolated CLI implementation to the same OS lifecycle.
• AI-led installation makes provider configuration, host plugins, CLI adapters, diagnosis, and real acceptance checks part of setup.

See the 3.0 release notes, installation guide, and release history.

If ContextOS helps your agent stay focused, give the project a star. Reproducible tasks and issue reports help us improve the next release.