Help
When a run stops early
Step and spend ceilings, cancelling a run, and what you keep when one is hit.
Every run has a ceiling on how many steps it may take and how much it may spend. Hitting one is not a crash, and it does not throw away what the run had worked out; the partial result is kept, shown, and paid for exactly as much as it used.
The two ceilings
| Ceiling | What it bounds |
|---|---|
| Step limit | How many actions a run may take: reading a file, compiling, simulating, editing, and so on. It stops a run from circling a problem indefinitely. |
| Spending limit | How much a single run may cost. It bounds the tail rather than typical work; most runs finish well under it. |
The limits differ by what the run is doing. A debug or optimize run is given more room than a straightforward build, because both spend real effort establishing the starting position before they can try anything at all.
Note
Your wallet balance can lower a run's spending ceiling but never raise it. That is what makes it safe to start a run with a small balance; it simply gets less room, rather than being able to spend money that is not there.
What you keep when one is hit
The run stops where it is and reports why in plain words. Everything produced up to that point comes back with it:
- A partial diagnosis, with the evidence gathered and the hypotheses already eliminated.
- Any static-check findings, which are cheap and usually complete well before a ceiling.
- Whatever code or measurements were produced along the way.
Asking again continues from there rather than starting over, because the workspace and the conversation are still intact. A follow-up after a stopped run is usually much shorter than the run that stopped.
What to do about it
| Message | The useful next step |
|---|---|
| Reached its spending limit | Add credit and ask again, or narrow the question so there is less ground to cover. |
| Hit its step limit | Ask a narrower question. Naming the module or the signal you suspect cuts an enormous amount of searching. |
Tip
Two focused turns are usually cheaper and better than one open-ended one. "Why does full assert a cycle late?" is a question a run can finish; "something is wrong with this FIFO" is a search.
Cancelling a run
You can stop a run yourself while it is in progress. Anything it had already finished is kept on the turn, and the reservation on your balance is settled against what it actually used rather than what it might have used.
Cancelling is the right move as soon as you realise the request was wrong; rewriting the request and asking again costs less than letting a run finish work you are going to discard.
When it is not a ceiling
A run that fails for another reason says so and does not describe itself as a budget stop. The two are distinguished deliberately, so a genuine fault never hides behind a reassuring message about limits. If a run reports a failure you do not recognise, that is worth raising with us along with the chat it happened in.