DeepAgent Code: a persistent-memory coding agent with a control plane
DeepAgent Code: AI coding agent with persistent memory and control plane
At a glance
- What is it?
- DeepAgent Code is a TypeScript AI coding workspace built around durable project memory and human steering of long-running tasks. It ships as a desktop app and a terminal entry point, and it expects you to bring your own model API keys.
- Who is it for?
- Adopt DeepAgent Code if your work spans days rather than prompts: migrations, refactors, or anything where you want to inspect what the agent learned and correct it before the next run. Skip it if you want a one-shot edit tool, if you need a permissively licensed codebase, or if you are not willing to supply your own model API keys.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What DeepAgent Code is actually for
Most coding agents treat each prompt as a fresh start. You paste context, it edits files, the conversation ends, and tomorrow you paste the same context again. DeepAgent Code is aimed at the opposite case: work that outlives a single session. The README frames it as an AI coding workspace for "work that lasts longer than one prompt", and the comparison table it publishes is explicit about the difference it cares about. A typical agent "understands only what's in the current prompt"; DeepAgent Code claims to remember the project across restarts.
The audience follows from that. This is for engineers running migrations, multi-day refactors, or any task with completion criteria you can state up front and verify later. It is also for teams that want a record of why an agent made a decision, since the memory system stores provenance, confidence, scope and status on typed documents rather than burying everything in a prompt. If your use case is "rename this function", the machinery here is heavier than the job.
Three collaboration modes and an independent permission axis
The design separates how much autonomy you grant from how much permission the agent has. Those are two different dials, and conflating them is a common flaw in agent tooling.
The mode dial has three positions. In Auto you supply a request and the agent defines the objective, plans, and executes end to end. In Loop you supply a goal and it writes an editable goal+plan.md, then advances that plan through plan, execute, verify and iterate ticks. In Design you supply the goal+plan.md yourself and the agent executes it without redefining the objective or the completion criteria. That third mode is the interesting one, because it gives you a way to pin down what "done" means before the agent starts spending tokens.
The permission dial is separate: Read-only, Request approval, or Full access, selectable without changing the collaboration mode. You can run Design mode with Full access, or Auto mode with Request approval. The README does not explain how the two interact when a Design-mode step needs a permission the current level denies, which is the first thing I would probe in a real repository.
How the memory and context layers fit together
The mechanism the README describes is a Session V2 runner that assembles context from explicit sources under something it calls a durable Context Epoch. It selects linked evidence within a budget, records why each reference was admitted or rejected, and preserves the current goal, constraints, decisions, open questions, next steps and relevant files during compaction. Compaction is the point where most agents quietly lose the thread, so recording admission decisions is a reasonable answer to it.
Memory is scoped rather than global. Session-private working context stays with the conversation. Project-shared facts and decisions follow the repository. User-global preferences travel across projects. Built-in skills and domain packs stay versioned system knowledge. Sealed evaluator material stays audit-only and never enters model context. That last scope is a deliberate exclusion, not an oversight.
Four graphs are connected: a code graph (files, symbols, imports, calls, diagnostics, references), a knowledge graph (strategies, methodologies, facts, skills, failure dossiers), project memory (decisions, constraints, environment facts, learned conventions) and a document graph (plans, designs, worklogs, evaluations, run context, evidence). Learning runs through a lifecycle: evidence creates a candidate, review or a human decision changes its status, and regression or ablation gates publish a knowledge snapshot. Rejection reasons persist so a discarded pattern is not silently relearned. The prompt-caching design is also stated: stable system instructions stay byte-stable while volatile state is appended in a tail block.
Installing DeepAgent Code and running a first goal
The repository is a Bun workspace. package.json pins packageManager to bun@1.3.14 and declares workspaces under packages/*, packages/console/*, packages/stats/*, packages/sdk/js and packages/slack. The top level contains an install entry alongside flake.nix and flake.lock, so there is a Nix path as well. The README does not publish a copy-paste install command, so the honest starting point is the repository's own install script or the desktop release.
The development entry point is defined in package.json. Running it starts the terminal client from packages/deepagent-code:
bun run devThe desktop variant is a separate script and pulls in packages/desktop:
bun run dev:desktopThere is a postinstall hook that runs fix-node-pty inside packages/core. That matters on machines where the pseudo-terminal binding needs rebuilding, and it is the step most likely to fail first on an unusual platform. If you are working from a checkout rather than a release, the install script at the repository root is the intended path.
The first real use is a Loop-mode goal, because that is where the plan artifact becomes visible. The README states that Loop mode writes an editable goal+plan.md and then advances it through plan, execute, verify and iterate ticks. What you should look for after starting is that file: it is the thing you edit to correct the agent's understanding before it burns a long run on the wrong objective. The README does not document the exact schema of goal+plan.md, so read the generated file rather than guessing at fields.
Steering, worktrees and the limits of the write path
Live steering is the feature with the most specific mechanics. Guidance sent while a model turn or tool is running is durably admitted and absorbed at the next safe provider-turn boundary without aborting in-flight work. Goal steering folds guidance into the next tick while preserving tool and plan state. Hot plan editing carries stable step IDs, evidence, completed work and the new plan version into the next tick. There is also explicit queueing for instructions that should start after the current activity instead of modifying it. Those are four distinct behaviours, and the distinction between steering and queueing is the one users will get wrong.
For parallel work, the README describes bounded isolated workers with dedicated worktrees. Delegated runs persist identity, generation, owner, lease, phase, terminal state, result and parent delivery, so an exact retry resumes the same work rather than starting a second worker. The write path is a Git/PR flow: workers commit only their scoped changes, one Reviewer session checks each exact worker SHA, the coordinator performs serial --no-ff merges on the Session branch, and one Senior Reviewer examines the merged batch. Resume, timeout, cancellation, takeover, review feedback and cleanup are generation-fenced so a stale worker cannot settle or overwrite newer work.
That is a lot of machinery, and it is also the limitation. Generation fencing, leases and reviewer sessions only pay off when tasks genuinely run in parallel over hours. On a single-file edit they are pure overhead, and the worktree-per-write-subagent model assumes your repository is comfortable with concurrent branches. The README also marks the Expert Panel and parts of the enterprise story as living in a separate repository, so the open source tree is not the whole product.
Where DeepAgent Code is the wrong tool
Three cases stand out. First, short-lived edits: if you want a single function rewritten, the mode system, the Context Epoch and the memory lifecycle are cost without benefit. Second, licensing-sensitive adoption: the repository reports NOASSERTION for its license, and the LICENSE and NOTICE files are present at the top level but the license body is not reproduced in the README. Anyone embedding this in a commercial product has to read those files directly. The README links an Enterprise repository, which strongly suggests a split between open and paid capability, but the README does not enumerate which features sit on which side.
Third, the model dependency. The README states 75+ model providers with your own API keys. That is a real constraint as much as a feature: there is no bundled inference, so cost, rate limits and data handling are yours to manage per provider. The README also does not document rollback semantics for a completed goal, though it does list roll back as a control path alongside pause, resume and take over. Treat the audit trail as the recovery mechanism until you have confirmed otherwise.
One more gap worth naming: the README documents domain packs activating from a problem profile and resolving conflicts with stricter-policy-wins semantics, but it does not describe how a pack is authored or versioned by a third party. Until that is documented, domain packs are a core-team feature in practice.
How it differs from LangChain Deep Agents and Claude Code
The searches around this project mix it up with LangChain's Deep Agents, and the confusion is understandable because both use the word deep and both target long-horizon coding work. The difference is where the state lives. LangChain Deep Agents is a library you compose into your own application; the orchestration, memory and tool wiring are things you assemble in code and own. DeepAgent Code is an application. It ships a desktop app and a terminal client, a Repo & Wiki view for browsing knowledge and execution archives, and a control plane for steering running work. You adopt it rather than build on it, and the SDK directory in the repository suggests programmatic access exists, though the README does not document the SDK surface.
Against Claude Code the contrast is narrower and more practical. Claude Code is a terminal agent tied to one model family. DeepAgent Code's README claims 75+ model providers with your own API keys, plus a memory layer you can inspect and reject. Whether that trade is worth it depends on how much you value provider choice and auditable memory versus a single vendor's tuning. The README does not publish benchmarks comparing the two, and neither should be chosen on a feature table alone.
Maintenance, licensing and what an upgrade costs you
The last push to the dev branch was on 2026-09-01, and the most recent release is app-v2.0.0-main.51, dated the same day. The repository is not archived. That is a recent, active cadence, but the release tag naming (main.51) indicates continuous main-branch builds rather than a slow, curated release train. Expect to track the dev branch if you want fixes.
The upgrade surface is defined by the workspace layout. It is a Bun workspace with a turbo pipeline, and the root scripts include lint (oxlint), typecheck (bun turbo typecheck) and test (bun turbo test). Any fork or internal deployment should run those three before pinning a new revision, because the memory snapshot and domain pack systems are described as versioned and snapshot-locked, which means a schema change can invalidate stored knowledge. The README does not document a migration path for existing project memory across major versions.
On licensing: the repository metadata reports NOASSERTION, and LICENSE and NOTICE are both present at the top level. That is not a permissive identifier, and it is not a clear one either. Read both files before you depend on this, and check whether the Enterprise repository carries different terms for the features you actually need. Nothing here is legal advice; the point is that the license is a question you have to answer yourself.
Editorial conclusion
Adopt DeepAgent Code if your work spans days rather than prompts: migrations, refactors, or anything where you want to inspect what the agent learned and correct it before the next run. Skip it if you want a one-shot edit tool, if you need a permissively licensed codebase, or if you are not willing to supply your own model API keys. Before you commit, read LICENSE and NOTICE, confirm what the install script does on your machine, and check the Enterprise repository for the features the README marks as enterprise-only.
Frequently asked questions
What is DeepAgent Code?
It is an AI coding workspace for tasks that last longer than a single prompt, built in TypeScript. The README describes persistent project memory, three collaboration modes (Auto, Loop, Design), live steering of running tasks, and support for 75+ model providers using your own API keys.
How much does a DeepAgent Code subscription cost?
The README does not state a price. It says the tool works with 75+ model providers using your own API keys, so inference is billed by whichever provider you configure, and it links a separate Enterprise repository without listing terms.
What are the key differences between DeepAgent Code and Claude Code?
The README positions DeepAgent Code around provider choice and inspectable memory: 75+ model providers with your own API keys, plus memory documents with provenance, confidence and scope that you can inspect and reject. Claude Code is not discussed in the README, and no benchmark comparison is published.
When should you use DeepAgent Code?
The README targets work that outlives one prompt: migrations, goals with objective completion criteria, and multi-step tasks you want to steer while they run. Loop mode is the fit when you have a goal but want the agent to write an editable goal+plan.md first.
Community notes