Athenode vs OpenSpec: comparison

Short answer: OpenSpec is a lightweight, open-source workflow for existing codebases: the current specs live in openspec/specs/, and each change is a folder with a proposal, spec deltas, a design and tasks that is archived when done. Athenode keeps a shared tree of specifications on the server and covers the whole range — a one-spec fix applied in minutes, or a whole application specified up front and implemented unattended for hours.

At a glance

	Athenode	OpenSpec
Where specs live	On the Athenode server, shared by the project	Markdown in your repo (`openspec/`)
Team work	One shared tree, owner / editor / viewer roles, live progress	One change per branch and pull request
Old specs	Stay in the tree with Q&A, plan and changed files	Changes archived to `changes/archive/`, deltas merged into specs
Structure	A tree with blockers between any specs, up to a whole project	One change → one task list; no dependencies between changes
Small changes	One spec, a few questions, apply — no decomposition	`/opsx:propose` creates everything in one step
Large work	Unattended runs through a whole subtree, in blocker order	`/opsx:apply` works through one change's tasks
Clarifying questions	Rounds of questions at every level	`/opsx:explore` as a thinking partner
AI tools	9, including Claude Code, Cursor, Codex, Copilot and Kiro	30+ tools
Licence and price	Hosted service with a free plan	Open source (MIT), free

How OpenSpec works

OpenSpec by Fission AI is built for brownfield work. openspec/specs/ holds the current truth about the system. A change starts with /opsx:propose, which creates a folder with proposal.md, delta specs (added, modified and removed requirements), design.md and tasks.md. /opsx:apply works through the tasks one by one, and /opsx:archive merges the deltas into the main specs and moves the change into a dated archive folder.

It is fast to adopt, local, needs no account, and the spec delta is reviewed in the same pull request as the code — a genuinely good fit for incremental changes to an existing system.

Two ways to work: a small change or a whole application

Athenode is built for both ends of the scale, and you choose per task:

A small change. Run /mindmap-specification with a sentence about what you want. The agent asks a few basic questions you might have forgotten — edge cases, what should stay unchanged — and writes one specification. You then apply it straight away with /apply-specification, without decomposing anything. Minutes from idea to reviewed code.
A whole application or a large feature. Specify the project, decompose it into features and stages, and keep going — /decompose-specification asks its own questions at every level — until the entire tree is ready, before a single line of code is written. Blockers between specs set the build order. Then /apply-specification works through the tree on its own: it plans, implements and reviews every prepared leaf in dependency order without stopping to ask you anything, for hours on a large tree, even days.

Where the specs live

In Athenode, specifications live on the server, not in one developer's working copy:

The whole team sees the same tree. Everyone on a project works from the same specs, with owner, editor and viewer roles, and the app updates as agents make progress.
Nothing gets lost. Completed specs stay in the tree together with the questions and answers that shaped them, the implementation plan, and the list of changed files with a summary of what was done — so you can always look back at why and how something was built.
Your code stays in your repository. Agents read and update specs through the Athenode MCP server; Athenode never needs your source code.

The trade-off: you need an Athenode account and a connection to the service, and specs are reviewed in Athenode rather than in the same pull request as the code.

When to choose OpenSpec

You make incremental changes to an existing codebase and want a light process with little ceremony.
You want the spec delta reviewed in the same pull request as the code.
You want everything local, open source and free.
One change at a time, without dependencies between changes, fits how you work.

When to choose Athenode

Your team needs one shared, always-current tree of specs rather than change folders spread across branches.
You want to plan a large feature or a whole application up front, with dependencies between its parts.
You want the same tool for a quick fix and for a spec tree that agents implement unattended for hours.
You want each completed spec to keep its questions, plan and changed files in one place.

Can you use both?

You can, for different projects. On the same codebase, pick one place where requirements live, or the two will drift apart.

Frequently asked questions

Can Athenode handle both quick fixes and large projects?

Yes. A quick fix is one specification and a few questions, applied straight away. A large project is a tree of specifications decomposed up front and implemented unattended, leaf by leaf in dependency order, for hours on a large tree.

Is Athenode heavier than OpenSpec for small changes?

Not much. A small change in Athenode is one spec: a couple of questions from the agent, then /apply-specification — no decomposition, no extra files in your repository.

Where do OpenSpec's archived changes go, and where do Athenode's?

OpenSpec moves finished changes into openspec/changes/archive/ in your repository. Athenode keeps completed specs in the project's tree on the server, with their questions, plan and changed files.