Orc Incremental Dark Rebirth

Quick facts

Reset scope

The current run resets.

Persistent value

Permanent bonuses are retained.

Progression

Further progression can unlock after the reset.

Decision boundary

Exact reset contents, timing, and an optimal threshold are unpublished.

Start with the wall, not the clock

A reset decision begins with the part of the run that has stopped responding. “This run feels slow” is not a diagnosis. Name the blocked encounter, purchase, or unlock, then record what has already been tried. A good note distinguishes a combat wall from an economy wait and both from a formation mistake.

The official image shows an amulet-breaking choice beside the Accursed Elf. It is useful interface context, not proof of a current threshold, reward amount, or complete list of reset consequences. Read the prompt in the named build before acting.

Use the progression diagnosis to identify the layer first. If one affordable change still has a clear chance to alter the wall, use the upgrade-priority framework before giving up the current cycle.

Record the opportunity cost

Every reset abandons whatever the current cycle could still produce. That cost is easier to evaluate when written down before the choice.

Field	Question to answer
Build	Which exact version or dated build is running?
Wall	What observable event prevents further progress?
Current option	Which affordable purchase or position test remains?
Expected next-cycle change	What permanent choice should address the wall?
Evidence	Which prompt, tooltip, or result supports that expectation?
Stop condition	What result would show the reset did not solve the problem?

Do not replace these fields with an inherited level threshold. A threshold without the army, economy, build, and intended next purchase cannot explain why the decision should work.

Use a two-cycle comparison

The most useful reset observation compares the end of one cycle with the beginning of the next under a shared checkpoint. Save a note immediately before resetting. After the reset, return to the same named encounter or progression marker and record the first meaningful difference.

Keep the comparison narrow:

1. Preserve the old build label and wall description.
2. Record the visible reset prompt before confirming it.
3. Note the first permanent choice made afterward.
4. Rebuild toward the chosen checkpoint without changing the test objective.
5. Record whether the prior failure moves, disappears, or remains.
6. Keep another explanation open when the army or route changed.

This method does not calculate an optimal time. It produces a bounded result for one decision and one setup.

Treat push-versus-reset advice as a heuristic

A transparent heuristic states its inputs. “Push while an affordable change still alters the wall; reset when the next cycle has a specific testable advantage” is a decision rule, not a mathematical optimum. It can be wrong for a different build or objective, which is why the note must name both.

Avoid turning time spent into proof. A long cycle can still have a useful near-term purchase. A short cycle can still be ready to reset if the intended permanent change is already clear. Compare remaining opportunity, not frustration.

The Blight evidence guide explains how to preserve historical gain wording without deriving an equation. The Blight Tree reference shows how to record a current choice once the relevant interface is visible.

Verify what persists in the named build

Do not infer the complete reset inventory from a broad system description. Capture the before state of any field that matters to the comparison, confirm the prompt, then record the same field afterward. Separate retained permanent progress from resources or choices that belong only to the abandoned cycle.

If a field is not visible, mark it unknown. Do not edit the save or rely on memory to fill the gap. A screenshot pair or written before-and-after list is safer than a confident summary made later.

For a disputed result, repeat on a later cycle with the same field list. One surprising transition may come from a patch, a missed purchase, or a changed unlock condition rather than the reset itself.

Common reset mistakes

• Resetting immediately after changing formation, purchases, and route, then crediting one cause.
• Publishing a universal level or elapsed-time threshold from one run.
• Treating promotional interface art as a current reward table.
• Assuming every permanent system is available at the same point in every build.
• Comparing the old cycle’s late state with the new cycle’s early state without a shared checkpoint.
• Rewriting an old observation after a patch instead of starting a new build-labeled row.

Write the conclusion narrowly

A useful conclusion states the build, old wall, remaining option, permanent choice, shared checkpoint, and observed change. It can support a repeatable decision for that setup. It cannot establish the fastest route for every army or future patch.

When the comparison is incomplete, say what is missing. “The next cycle reached the checkpoint, but the formation also changed” is more useful than declaring the reset successful. That caveat tells the next test which variable to hold fixed.

Official source

Verification boundary

Build boundary

version 1.0 official system copy

Evidence check

2026-08-28

Still unknown

exact reset contents, exact reset timing, universal optimal threshold

Frequently asked questions

What is verified about Dark Rebirth?

Dark Rebirth resets the current run while retaining permanent bonuses, and further progression can unlock after the reset. Boundary: version 1.0 official system copy. Checked 2026-08-28. The checked official sources do not publish a universal reset moment or an exact list of everything removed and retained.

How should a reset decision be recorded?

Write down the build, current wall, affordable short-run options, permanent option expected next cycle, and the result after resetting. That makes the decision reproducible without pretending one threshold works for every run.

Does a slower run automatically mean it is time to reset?

No. First state which wall has stopped changing and whether one affordable purchase or formation test can still alter it. A feeling of slowness is not enough evidence for an optimal reset claim.