PlanExe turns a project brief into an editable planning baseline
Create a plan from a description in minutes
At a glance
- What is it?
- PlanExe is an MIT-licensed Python planner that expands a plain-language brief into a structured, inspectable plan and a folder of editable artifacts. It is built for consulting-scale initiatives, and its own README is explicit that the output is a draft for investigation, not an approved plan.
- Who is it for?
- PlanExe fits under-resourced teams that need a broad, inspectable starting point for a multi-phase program and are willing to verify every generated claim before it reaches a decision maker. It does not fit everyday task lists, and it does not fit anyone who needs a plan they can execute without expert review, because the README states that generated budgets, dates, laws and risk estimates may be wrong or incomplete.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap PlanExe targets: planning capacity, not planning ideas
The README opens with a claim about access rather than capability: good ideas are not limited to organizations that can afford a large consulting engagement, but turning an ambitious idea into a coherent project normally requires time, specialist knowledge, stakeholder interviews and repeated synthesis. PlanExe is aimed at that gap. The intended user is not someone tracking chores. The README says plainly that it is for consulting-scale, multi-phase initiatives and not for everyday task lists or small personal projects, and it lists regional infrastructure programs, regulated healthcare or financial-services transformation, cross-border public-sector work, ERP migration, corporate separation and post-merger integration as suitable material. It also names a second audience: AI agents. The topic list includes mcp and the README points to MCP setup in the documentation, so the project is positioned as something an agent can call, not only something a person opens in a browser. A third audience is implied by the self-hosting section: teams whose project data cannot leave systems they control.
How the pipeline works: parallel planning perspectives merged into one report
The README describes the mechanism at a high level. PlanExe examines a project from several planning perspectives and combines the results into one self-contained interactive report. That is the whole architecture as documented: multiple passes, one merged artifact. The output commonly includes an executive summary and project purpose, assumptions and constraints, strategic choices and alternative scenarios, a work breakdown structure with a dependency-aware Gantt chart, governance bodies and decision rights, roles and stakeholders, a risk register with SWOT and mitigation proposals, a premortem and self-audit, and lists of documents to create, documents to find and data to collect. The topic tags hint at the machinery underneath: pddl and planning-algorithms alongside llamaindex, ollama and openrouter. The repository does not document the internal sequence of those passes in the README, so the ordering and the model calls per stage cannot be confirmed from the supplied material. What is documented is the artifact layer. Each run produces a folder of readable source artifacts alongside the final report, in Markdown, JSON and CSV. That choice matters more than the report itself: the plan is not trapped in a chat transcript, and the editable bundle is the interface for correcting it.
Editing an assumption and rebuilding only what depends on it
The most specific claim in the README is about partial regeneration. If you disagree with an assumption or an early decision, you edit that artifact and continue the plan from there. PlanExe then rebuilds the later work that depends on your change while preserving earlier work you already accept. The README frames this as refining the reasoning behind a plan rather than rewriting its final prose, which is a fair distinction: editing a dependency graph is a different operation from regenerating a document. The catch is that this behaviour depends on the artifacts carrying enough structure for the tool to know what depends on what. The README does not show the schema, the file naming convention, or the command that triggers a partial rebuild. Treat the dependency-aware rebuild as the project's central design claim and verify it against a real run before you build a workflow around it. If the artifacts turn out to be mostly prose with a thin JSON wrapper, the rebuild will be closer to a full regeneration than the README suggests.
Running it: what the README actually gives you, and what it defers
The README does not contain install commands. It routes you to the getting started guide at docs.planexe.org, and it states that MCP, command-line, AI-agent and Docker setup are covered in the PlanExe documentation. So the honest answer to how you run it is: from the repository, not from the README. What the README does establish is the deployment shape. The planning pipeline can use cloud models or run with local models so sensitive material stays on systems you control, and the topic tags name ollama and openrouter as the two ends of that spectrum. A browser path exists at app.mach-ai.com with an early access signup and no installation required, and a separate account flow at home.planexe.org. Beyond that, any config key, environment variable or CLI flag would be invention. If you need a local-only setup, plan to read the documentation before you commit, because the README's self-hosting section is a list of motivations (trade secrets, air-gapped work, provider unavailability, pricing changes, model choice) rather than a setup procedure.
The limitation the README states itself
PlanExe is unusually direct about its failure modes, which is worth crediting. The README says generated claims, budgets, dates, laws, engineering assumptions and risk estimates may be wrong or incomplete, and that the result is not a substitute for stakeholder participation or professional sign-off. It lists what important projects still require: evidence and current local data, stakeholder interviews and negotiation, domain experts, legal, financial, medical, safety or engineering review where applicable, and named people who take responsibility for decisions. The practical consequence is that the output is useful in inverse proportion to how much of it you accept without checking. A risk register with plausible-sounding entries can create false confidence in a team that lacks the domain knowledge to challenge it, and the premortem and expert-criticism sections are generated text, not testimony from people who will carry the consequences. The second limitation is scope. The README excludes small projects, and the 15-minute figure quoted for producing a baseline applies to briefs that are already rich in objective, location, constraints, stakeholders, resources, timeline and success criteria. A thin brief produces a thin plan, and the README says so.
Where PlanExe sits next to a general-purpose chat assistant
The obvious alternative is a general-purpose chat assistant with a long prompt asking for a project plan. The difference is not model quality, since both can call the same cloud or local models. It is the artifact and the process around it. A chat assistant returns prose in a transcript, and correcting an early assumption means either re-prompting the whole thing or hand-editing the output with no notion of what depended on the change. PlanExe returns a folder of Markdown, JSON and CSV files, and the README claims the tool can rebuild dependent later work while preserving accepted earlier work. The second difference is structure. PlanExe's documented output includes a dependency-aware Gantt chart, governance bodies with decision rights and escalation paths, and a work breakdown structure, which are specific planning constructs rather than headings a model was asked to fill. Whether the generated Gantt dependencies are meaningful is exactly the kind of thing you check on a first run. A third difference is deployment: the README positions local execution as a first-class option, which a hosted chat product does not offer in the same form.
Licence, maintenance and the cost of keeping a plan alive
PlanExe is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the code. It does not cover the models you point it at, and the README's self-hosting section is largely about provider risk: vendor censorship, changing usage policies, account restrictions, pricing changes and service shutdowns. If you route confidential project material through a cloud model, the licence of the code tells you nothing about what that provider does with your brief. The repository lists no retrieved releases, so there is no published version history to plan an upgrade cadence around; the last push recorded is 2026-09-06 and the default branch is main. That means you track main or pin a commit you have inspected. The recurring cost is not the software. It is the review labour: every generated assumption, date and risk entry needs a named person to accept or reject it, and the README's own list of what PlanExe does not replace is the best estimate of that workload available.
Who should adopt it, and what to check on the first run
Adopt PlanExe if you are starting a multi-phase program with a brief you can write down in detail, you need a broad first-pass baseline rather than a finished plan, and you have people available to interrogate the output. It is a reasonable fit for an under-resourced organization preparing an ambitious proposal before it can pay specialist advisers, which the README names as a use case, and for teams that must keep project material on their own hardware. Do not adopt it for small projects, and do not adopt it if the plan will be executed without domain review. On a first run, check three things that the README does not settle. Open the generated artifact folder and confirm the Markdown, JSON and CSV files carry enough structure for the partial rebuild described in the README. Pick one early assumption, change it, and see whether later sections actually rebuild while earlier ones hold. Then check the dependency-aware Gantt chart against the work breakdown structure, because a Gantt with invented links is worse than no Gantt. If the artifacts turn out to be prose with a thin wrapper, the editing story is weaker than advertised, and you should treat PlanExe as a report generator rather than a planning baseline you maintain.
Editorial conclusion
PlanExe fits under-resourced teams that need a broad, inspectable starting point for a multi-phase program and are willing to verify every generated claim before it reaches a decision maker. It does not fit everyday task lists, and it does not fit anyone who needs a plan they can execute without expert review, because the README states that generated budgets, dates, laws and risk estimates may be wrong or incomplete. Before adopting it, check the getting started guide at docs.planexe.org for the actual install and run commands, confirm which local model backends your hardware can serve, and confirm the licence terms of any cloud model you route project material through.
Community notes