Plan vs Build in Mythos: choose the right mode before you change code
Use Plan to settle important decisions without changing your app, then use Build when the result and success checks are clear.
Quick answer
Choose Plan when the question is “what should we build?” Choose Build when the question is “make this defined change.” Plan gives you an editable draft without changing the app. Build can change the app and makes the new version current only after Mythos completes its checks.
Each successfully saved Plan response—whether a message, questions, or a draft—uses one credit. Editing, saving, approving, or canceling that draft does not use another Plan credit. Approving the plan passes the exact version you accepted to a separate Build, which uses the normal Build charge.
A focused copy correction with clear success criteria should usually go straight to Build. A new workflow with unresolved roles, information, or navigation should be planned first. Choose based on uncertainty, not task size.
The decision is uncertainty, not project size
People often describe Plan as “for big tasks” and Build as “for small tasks.” Size matters, but uncertainty is the better signal. A one-screen billing change may still hide unresolved pricing rules and access decisions. A large but mechanical rename may already be completely defined.
Before choosing a mode, ask:
- Do we agree on the user and the exact problem?
- Do we understand what the app does today?
- Have we decided who can access the feature and where its information belongs?
- Can we describe success with steps another person can repeat?
- Could two reasonable solutions create meaningfully different products?
If the first four answers are yes and the fifth is no, Build is usually appropriate. If an important decision is missing, use Plan to surface and settle it. A useful Plan ends with clear choices, steps, and checks rather than a long list of possibilities.
The selected mode also communicates intent to collaborators. Plan says the decisions are still open for review. Build says the team is ready for the app to change within the stated scope.
Use this decision table
| Situation | Use | Why |
|---|---|---|
| Correct a known label or validation message | Build | The outcome is explicit and local |
| Add a workflow whose roles and states are unsettled | Plan | Product rules must be resolved before files change |
| Repair a reproduced bug with a known expected result | Build | Reproduction and acceptance bound the change |
| Choose between two navigation models | Plan | Either option changes product behavior beyond implementation |
| Apply an approved design with named responsive criteria | Build | The target and checks are known |
| Introduce authentication or a new data boundary | Plan first | Authority, migration, and failure behavior need decisions |
| Continue an accepted plan | Approve, then Build | The exact approved draft becomes Build input |
| Explore ideas with no commitment to change source | Plan | The read-only boundary preserves the current app |
Do not use Plan to postpone a decision only the owner can make. State the options and tradeoffs, make the decision or ask for it, then finish the draft. Likewise, do not ask Build to invent pricing, access rules, or workflow policy while it changes the app. Settle those choices first.
What Plan does in Mythos
Plan is a read-only workspace for thinking through a change. It can use the project context available to it, ask questions, and propose a draft, but it does not edit the app or create a new Preview.
The draft is saved and editable. Approval sends the exact saved version into Build, so review any changes before approving. The charge boundary is described in the quick answer above and the Plan documentation.
Plan has three useful jobs:
- expose assumptions before they become product behavior;
- turn an idea into a clear user flow, constraints, and success checks;
- give collaborators one reviewable version of the decision.
Ask Plan to follow the patterns already used in the project. It should show unresolved questions instead of quietly inventing pricing, access rules, or other product policy.
A copyable Plan protocol
Use a prompt that separates known facts, open decisions, constraints, and proof:
Plan a saved-search feature for the existing project. Do not change the app.
Known outcome:
- A signed-in user can save the current search query and filters.
- Saved searches appear in the existing navigation.
- Opening one restores the exact query and filters.
Open decisions to resolve:
- maximum number of saved searches,
- duplicate-name behavior,
- whether a saved search is private or visible to the workspace.
Constraints:
- reuse the current sign-in, information, navigation, and visual patterns;
- do not add an outside service or background process;
- preserve the current behavior for searches that are not saved;
- explain any important storage, access, or transition risks.
Return:
1. questions that require my decision,
2. the proposed user flow,
3. a short sequence for delivering it,
4. empty/loading/error/success states,
5. a checklist covering access and conflicting changes,
6. explicit out-of-scope items.
When the draft returns, answer every product question and remove speculative extras. Make sure each step ends in something a user or reviewer can observe. If you edit the draft, approve it only after the saved version says exactly what you intend. Plan mode documentation explains the lifecycle.
What Build does in Mythos
Build is the mode that can change your app. Mythos prepares a new version while the current Preview remains available, runs code and production-build checks, and checks desktop and mobile rendering when browser verification is available. The new version becomes current only after the required delivery checks pass.
If no version is delivered, the previous version remains current. A confirmed platform failure before delivery returns the reserved credits. Choosing Stop settles the observed usage under the Build's original pricing terms and releases the unused reservation. If delivery has already started, the balance remains pending until its outcome is confirmed. Passing the delivery checks is valuable, but it does not prove that your business rules, access model, or every user state is correct. Test those separately.
A good Build request says:
- what happens now;
- what should happen instead;
- which part of the app is in scope;
- what must remain unchanged;
- which steps another person can repeat to confirm success.
Avoid requests such as “make it better” or “fix all UX.” They do not give Mythos or the reviewer a clear stopping point.
A copyable Build protocol
For a defined change, use a focused prompt:
Build the approved saved-search plan.
Scope:
- implement only the saved-search flow described in the approved draft;
- reuse the existing sign-in, information, navigation, and visual patterns;
- preserve current unsaved-search behavior and unrelated pages.
Acceptance:
- saving keeps the exact query and filters for the signed-in user;
- an empty name, duplicate name, limit breach, and failed request have clear states;
- opening a saved search restores the URL and visible controls consistently;
- another user cannot view or change the saved search through the interface,
a copied link, or another available path;
- keyboard and mobile users can create, open, rename, and delete a saved search;
- private configuration never appears in the browser.
If the current project cannot support part of the request, explain the limitation
instead of silently replacing real behavior with sample data.
For a bug, include reproduction and a regression check:
Fix only this regression: clearing the Status filter updates the control but
refreshing the page restores the old Approved filter.
Start from /requests?status=approved. After Clear, the URL and visible results
must both show that no status filter is active. Refresh must preserve that state.
Keep other filters and the requests layout unchanged.
The prompt stays short because the expected behavior is precise. Writing good prompts has more patterns.
Switch modes at a visible boundary
A healthy sequence is question → Plan → review → approval → Build → test. Each boundary asks for a different decision:
| Boundary | Question to answer |
|---|---|
| Question to Plan | Is the problem clear enough to explore? |
| Plan to review | Did the draft expose assumptions and tradeoffs? |
| Review to approval | Does this saved version describe what we actually want? |
| Approval to Build | Are we ready for the app to change within this scope? |
| Build to test | Does the result work as intended without breaking nearby behavior? |
You can stop after Plan. The draft may show that the feature is unnecessary, too risky, or blocked by a missing product decision. Canceling is a valid outcome and does not change the app.
New evidence after a Build may make the old plan incorrect. Do not keep following it simply because it was approved once. Use Plan again when decisions have changed, or send a focused Build when the correction is already clear. A plan is a decision aid, not a permanent promise.
What neither mode proves
Plan is only as good as the context and decisions you provide. It can organize uncertainty, but it cannot choose your pricing, legal policy, access model, or risk tolerance for you. A detailed draft may still be wrong when important information about the project or an outside service is missing.
Build checks useful technical and browser behavior, but it does not prove complete security, privacy, accessibility, performance, safe data changes, or business acceptance. Outside services and production environments also need their own review.
With an active paid workspace subscription, you can use the workspace editor for a code change you understand directly. Save is explicit with Save or Ctrl+S; there is no autosave, and a manual save does not use an AI Build charge. Earlier versions remain read-only. Check the current plan features and Workspace editor.
FAQ
Does opening Plan change my app?
No. Plan is read-only and does not edit the app or start a Build.
What does a Plan request cost?
Each successfully saved Plan response—whether a message, questions, or a draft—uses one credit. Editing, saving, approving, or canceling that draft does not use another Plan credit. The separate Build after approval uses the normal Build charge.
Should every feature start with Plan?
No. Use Build directly when the desired result, constraints, and success checks are already clear. Planning everything adds delay without resolving additional uncertainty.
Can I approve part of a Plan?
Edit the draft to the exact scope you accept, save it, then approve that version. Do not approve a broad draft and expect a later request to narrow it automatically.
What happens if a Build fails?
Before successful delivery, the current version remains unchanged. A confirmed platform failure before delivery returns the reserved credits. Choosing Stop settles the observed usage under the Build's original pricing terms and releases the unused reservation; delivery already in progress must be resolved before settlement. Check the balance and reported outcome before trying again.
Is a successful Build production-ready?
Not automatically. It means the new version passed the checks Mythos performed. Your release still needs the product, security, data, operational, and compliance review appropriate to its risk.
Sources
Current Mythos documentation used for this guide:
Last updated
