Compare

You already use Claude Code or Codex. Why add Flanner?

Because of what happens to a project's context — its plans, its memory, its skills — when work moves between sessions, between agents, between machines and between people. Each agent keeps some of it. This page is what each one keeps, what it loses, and what tells you when it has gone wrong.

Every cell was read from the linked docs, repository or pricing page in September 2026, with the version named where it matters. Where the docs did not say, the cell says so. If a cell is wrong or has gone stale, tell us and it gets corrected.

Does it: the tool does this
Partly, or by hand: part of it, or a manual route
No: it does not, or does not apply
With Mesh: flanner does this on a paid Mesh plan
Not documented: the tool's own docs do not say

Your agent, on its own

Claude Code and Codex each carry some context between sessions on their own, and a docs folder in git carries whatever you commit. This is what each one keeps, what it loses, and what tells you when it has gone wrong.

Flanner beside

	Flannerplans, memory and skills as files on your disk, versioned and checked0.12.0	Claude Codeplan mode, CLAUDE.md, auto memory, skills and pluginsv2.1.252	Codexplan mode, AGENTS.md, skills and plugins	Markdown and gita docs folder in the repository, committed
A plan, after the session ends	Kept A file in .plans/, every revision kept and diffable, whether or not it was committed.	For the session Plan mode writes a plan you can edit before approving. ~/.claude/plans/ is listed as internal, not user-facing.	Not documented Plan mode drafts the plan in the terminal view. Where it goes afterwards is not in the docs.	If committed A plan is a file like any other.
Evidence a plan has gone stale	Shown File references that no longer resolve, commits since it was written, and age. Evidence, not a verdict.	None Nothing reads a plan against the code later.	None Nothing reads a plan against the code later.	git log Tells you what changed since the commit. Nothing reads the plan.
What memory loads each session	Search hits only Nothing loads until an agent searches. Each hit says why it matched.	All of it CLAUDE.md in full, plus the first 200 lines or 25 KB of MEMORY.md. Topic files on demand.	Instructions only AGENTS.md files up to 32 KiB, rebuilt every run. No memory across sessions is documented.	What you paste A file is context only when somebody puts it there.
Screens a credential before saving it	Recognised patterns Known key formats, password-style assignments and long high-entropy tokens are refused. Placeholders pass. A screen, not a guarantee.	Not documented	Not documented	Manual Whatever you do not commit. Pre-commit scanners exist.
Which skill copy loads when names collide	Shown per collision Across the project, your home directory and every plugin. Claude Code layouts only.	Documented rule Enterprise over personal over project. /skills lists what loaded.	Not merged Two skills with one name both appear in the selector.	Not applicable
Moving it to another machine or a teammate	With Mesh Plans, memories and skills, signed device to device. Personal memory never leaves.	Commit or plugin CLAUDE.md and skills travel by commit or marketplace. Auto memory is machine-local.	Commit or plugin AGENTS.md and .agents/skills travel by commit; plugins for wider distribution.	Built in That is the job.

Plan mode in both agents is for one session: it drafts, you approve, it edits. Flanner does not draft a plan. It keeps whichever plan exists and says when the code has moved away from it.

One product at a time

Each flanner product beside the tools people use instead of it.

Memory

All four store what an agent should remember. They differ in where it lives, how much of it lands in context each session, and who else can read it. mem0 and Zep are memory infrastructure for applications you build; Claude Code's memory and flanner's are for the coding session in front of you.

Flanner beside

	Flanner Memoryone markdown file per memory, indexed on your disk0.12.0	Claude Code memoryCLAUDE.md you write, plus MEMORY.md and topic files Claude writes itself	mem0a memory API; hosted, or self-hosted under Apache 2.0	Zepa temporal knowledge graph; Graphiti is the open core, Zep Cloud the service
Where it lives	Your disk .flanner/memory/ in the repo, or your home directory.	Your disk CLAUDE.md in the repo; auto memory under ~/.claude/projects/.	Theirs, or yours Hosted, or self-hosted on your own vector store.	Theirs, or yours Zep Cloud, or Graphiti on your own Neo4j, FalkorDB or Neptune.
What loads each session	Search hits only	All of it CLAUDE.md in full; MEMORY.md to 200 lines or 25 KB.	Query hits only	Query hits only
Retrieval	Keyword SQLite FTS5. Each hit says why it matched.	File reads Claude reads the MEMORY.md index and opens topic files with its file tools. No index to query.	Hybrid Semantic, BM25 keyword and entity matching, scored in parallel and fused.	Hybrid and graph Semantic, keyword and graph traversal.
Knows when a fact stopped being true	Supersede The old text stays readable under the new. No time model.	Timestamp A modified field on each file.	In the algorithm Temporal reasoning when a memory is added.	Validity windows Every fact carries when it became true and when it was superseded.
Screens a credential before saving it	Recognised patterns Known key formats, password-style assignments and high-entropy tokens. Placeholders pass.	Not documented	Not documented	Not documented
Sharing with a team	With Mesh Signed, one memory at a time, on request. Personal memory never.	Commit CLAUDE.md Auto memory is machine-local and not shareable.	By the service Scoped by user and project. Unlimited end users on every tier.	By the service Per project, with MCP seats by tier.

Codex is not a column here because its docs describe no memory across sessions; AGENTS.md is instructions, rebuilt every run. Letta was left out because its memory docs could not be reached to check.

Skills

Both agents can list their skills, and Claude Code can now say how often each is used. What neither shows is which of two same-named copies is actually in effect, and neither keeps a snapshot to roll back to.

Flanner beside

	Flanner Skillsinventory, precedence, usage and safe change for skill packages0.12.0	Claude Codeskills in .claude/skills/, plugins through /pluginv2.1.252	Codexskills in .agents/skills/, plugins for distribution
Lists what is installed	One inventory Project, home directory and every plugin.	/skills and /plugin Skills in the /skills menu; marketplace plugins with version and state in /plugin.	Selector Skills appear in the $ selector. No listing command is documented.
Which copy loads when names collide	Shown per collision Each duplicate, and which one is in effect.	Documented rule Enterprise over personal over project. You apply the rule yourself.	Not merged Both can appear in the selector.
Records which get used	Opt-in hook Explicit invocations only. The coverage window is printed beside every count.	/skill-doctor Context cost and invocation frequency. v2.1.252 or later.	Not documented
Rollback	Snapshot Taken before every install; rollback restores it.	No Old plugin versions are purged after about 14 days.	Not documented
Team distribution	With Mesh A signed package, verified on arrival. Receiving is a separate step from installing.	Commit, plugin or managed settings No signing documented.	Commit or plugin $skill-installer for curated skills.
Agents it manages	Claude Code Codex layouts are not read in 0.12.0.	Itself	Itself

Two community CLIs, claude-list and claude-code-plugin-manager, list what Claude Code lists, in one command. Neither adds precedence, usage or rollback.

Sharing

Getting plans, memory and skills to a teammate. Git does this well for anything you are willing to commit; a marketplace does it for skills; a hosted service does it by holding the content centrally.

Flanner beside

	Flanner Meshsigned, device to device, one item at a time0.12.0	Gitalready set up, already trusted with the source	Plugin marketplacesClaude Code's and Codex's route for distributing skills	Hosted memorymem0 or Zep, where sharing is a property of the service
What travels	Plans, memory, skills One at a time, when somebody asks.	Whatever is committed	Skill and plugin packages	Memories
Who holds the content	Your machines Our servers issue accounts and access. They never receive a plan, a memory or a skill.	Your git host Which most teams already trust with the source.	A git host The marketplace repository.	The vendor Or you, if self-hosted.
Verification	Signed and checked Signed by the sending device, verified on arrival. A tampered package is refused.	Commit signing If the team set it up.	None documented	TLS To the vendor.
Receiving versus installing	Separate steps A skill a teammate sends waits until somebody installs it.	A pull changes your tree	Installing is receiving	Not applicable
Keeps private material out	By construction A shared skill carries no record of who used it. Personal memory can never be shared.	Whatever is not ignored ships	Whatever is in the package	Scoped by user and project
Setup and cost	Account and subscription A workspace, a device pairing, a 14-day trial. Nothing to host.	Already done Free.	A repository and a settings entry Free.	An API key Priced per tier.

Works with your planning workflow

These four help you write a plan and drive an implementation from it. Flanner does neither. It has no template and no opinion on authoring; it versions whatever plan exists and says when the code has moved away from it. Use one of these to produce the plan, and flanner to keep it.

GitHub Spec Kit

A constitution, a spec, a plan and tasks, through slash commands in 30+ agents.

Writes to: specs/ in the repo
License: MIT

AWS Kiro

requirements.md, design.md and tasks.md per spec, inside its own IDE and CLI.

Writes to: Files in the project; the directory is not named in the docs
License: Free tier of 50 credits, then $20 to $200 a month

Task Master

A task graph parsed from a PRD, worked through over MCP.

Writes to: .taskmaster/ in the repo
License: MIT with Commons Clause

BMAD-METHOD

Planning, building and learning phases with agent workflows and plugins.

Writes to: docs/ and skills/ in the repo
License: MIT

Flanner tracks the markdown in one directory per project, set with flanner init --plan-dir. We have not tested it against each tool's layout. If you have, tell us what happened.

Which approach fits

Your plans are done by the end of the session and your CLAUDE.md fits in 200 lines.

Stay with your agent's built-ins. They are included and on by default.

You are building an application that needs a memory layer of its own, with the best retrieval available.

mem0 or Zep. Zep's validity windows do something flanner does not.

You are happy committing plans and skills to the repository and pulling them on the next machine.

Git. It is free, configured, and better at merging than anything we will build.

Plans do not get written, or get written badly.

Spec Kit or Kiro. Flanner has nothing to say about authoring.

A plan outlived the session and the code moved on; memory loads whether or not it is relevant; you have lost track of which skill copy an agent loads; or the material must not be committed or uploaded.

Flanner. Free locally; Mesh when it has to reach a teammate.

Try it on one repository

One install, no account. Run it in a repository that already has a plan, and see what freshness says about it.

uv tool install flanner

Five-minute walkthrough Mesh, when it has to reach a teammate