Docs / plan-mode

Plans for big prompts

When a request is too broad for one run, the AI proposes a plan instead of building it blind. You review the steps, edit them, approve — then each step runs and saves on its own.

When you get a plan

Poleved reads every substantial prompt before running it. If the request covers a lot of ground, you get a Plan ready for review card instead of a build, and the prompt sits at Awaiting approval. Nothing is written to your project until you approve it.

Short prompts are never planned — under roughly 60 characters the AI just builds. Steps inside a plan are never re-planned either.

One flow builds a plan without asking you to review it: picking more than one screen when you add a mobile app. There is nothing for a planner to decide there — you already chose the screens, and each one is a step — so it runs straight away. Everything below about per-step progress, halting and retrying applies to it unchanged.

The card summarises what you would get: Your request was broken into 4 phases · 11 steps. A phase is a grouping you review; the steps inside it are the units that actually run.

Occasionally the planner does not finish in time. You then get a Needs a decision card with two choices: Try planning again, or Run as one go — a single build with no plan, which is riskier for a large request.

Reviewing the plan

Click Review & approve to open Adjust the plan.

  1. Pick a phase in the left-hand list. Reorder it with the arrows, or delete it.
  2. Edit the Phase title and What gets done on the right. That description is the instruction the AI receives for that step.
  3. Click Split into sub-tasks to break a phase into smaller steps, each with its own title and instructions.
  4. Use Add phase or Add sub-task for work the AI missed.
  5. Click Approve & run.

The counter in the dialog header tracks both ceilings, for example 11/60 steps · 4/20 phases. Editing is worth the minute: the descriptions you approve are what gets executed.

On a project with a mobile app, each phase also carries a Web or Mobile badge saying which app it builds in. A plan you started from the Mobile tab stays on the mobile side — except for work that can only live on the web, such as an API route or a database change, which is marked Web so you can see it. If most of a plan is on the side you did not ask for, that is worth catching here rather than after it runs.

A step can also arrive with an amber warning: Looks like a catch-all step…. That flags a step written to police the others — "make sure every screen shows the data", "final polish" — rather than to build one thing. Those have no natural stopping point, so they routinely turn out to be the most expensive step in the plan while producing nothing new. Deleting it and putting the requirement into the step that builds the thing is almost always the better trade. The warning never blocks approval; if you meant it, keep it.

Cancel on the card drops the plan without running anything.

What it costs

The card shows an estimate: ≈13.86 credits estimated — about 1.26 per step. You have 42.00.

That is an estimate, not a quote. Each step is metered from the tokens it actually uses when it runs, so the real total lands above or below. What the estimate is reliable about is magnitude — whether this is a 3-credit plan or a 30-credit one.

Steps are charged as they run, not up front. A plan you stop halfway only charged the steps that ran. Approving costs nothing on its own; the planning turn was already charged as the run that produced the plan.

If your allowance is short, the line changes to It should build about 8 of 15 steps, then pause until you add more — and you can still approve. See How credits work.

Watching it run

Once approved, the chat replaces the card with a Plan tracker: a progress bar, a done/total count, and the current Phase k/N. Steps run strictly one at a time, each with its own activity timeline, output and changed-file list — click a step to expand it. Stop halts the step that is running.

Each step starts with a summary of the project rather than a blank slate: the routes and screens that already exist, your data models and their fields, what the earlier steps of this same plan changed, and anything the platform has flagged as still broken. It is why a later step extends the page an earlier one built instead of writing a second copy of it.

Acceptance checks

Some steps arrive with acceptance checks attached: small promises the planner writes down before any code exists, which the platform re-runs once the AI says the step is done. Only two kinds exist — opening a page path (written like curl /orders, meaning the app must answer at /orders without a server error) and validating your database schema (prisma validate). A step carries at most three.

The AI is told to run them itself before declaring the step finished, and the platform runs them again afterwards; the AI's own word is not enough. A page that answers proves it exists, so a redirect to login or a 403 counts as a pass — only not there (404) or there but broken (500) fails.

A check that could not run is neither a pass nor a failure. If the preview server was not up, no page could be opened, and that check is reported as skipped rather than clean — a check that never ran is not evidence the step worked.

Checks are optional, and they survive your edits: rewrite a step in Adjust the plan and its checks stay attached to it. Most steps carry none, and a plan without any behaves exactly as before.

When a step fails

The chain stops at the failure. The remaining steps stay pending rather than building on top of broken code, and you get a banner naming the phase plus a Retry button. The step that stopped opens by itself, so the exact reason is on screen — the failing check, the page that errored, or the compile error — rather than something you have to go looking for.

Retry re-runs that same step in place, and when it succeeds the chain carries on from there. Finished steps are never repeated and never charged again. The retry itself is a new execution, so it is charged.

Two more cases stop the chain without being outright failures:

  • A step that ends in Build issues — the code was saved, but a check on it did not pass. That covers four things: the code may not compile; a page the step touched returned a server error when the platform opened it; an image or font the code points at could not be loaded; or an acceptance check the plan declared failed. One automatic repair attempt is made before you see this. Send a follow-up prompt describing the problem, then retry the step.
  • Running out of credits. The banner turns amber with an Add credits link, and on a paid plan a second Top-up button beside it. Add credits first: retrying without credits fails the same way.

Limits & notes

  • A plan holds at most 20 phases, 8 sub-tasks per phase, and 60 steps in total. Above 60 steps, Approve & run stays blocked until you remove some.
  • An unapproved plan expires after 30 minutes and is cancelled. Send the prompt again to get a new one.
  • Credit figures on the approval screen are estimates. The charge always comes from the tokens each step really used.
  • Retrying a step costs credits again.
  • A step carries at most 3 acceptance checks, and only the two kinds above. Anything else the planner writes is dropped.
  • Whether a step gets acceptance checks is the planner's call — nothing forces it, so many steps run with none.
  • Steps run one at a time, in the order you approved. There is no parallel execution.
  • Limits may change during alpha.

Related