The thing about AI workflows is that just because they complete, doesn’t mean they did the right thing. Step-level iteration is crucial, but paying for the entire run from top to bottom is untenable.
Rerun-from-step is the mechanism that makes iteration cheap. Here's how it works, when to use it, and why.
Automatic retries and manual reruns are separate mechanisms
Before we get into it, I know what you’re thinking—isn’t the point of durable execution that retries happen automatically? Yes! You’re very astute. Inngest has always let you configure a number of automatic retries, triggered by a failure, inside a run that's already in progress. But there will come a day—and that day was likely months ago—that you’ll want to rerun a step because you need to change something about it, even if it doesn’t result in a failure.
Re-run from step lets you do that.
Rerun-from-step is a separate, manually triggered capability. It works on a run that has already finished—succeeded or failed—and you invoke it on demand, from the dashboard, CLI, or REST API, whenever you want to test something new. You can go back into a run that completed successfully and rerun one step with different input, with no failure required to trigger it.
Inngest reconstructs every step before the one you select as memoized output, then re-executes the selected step and everything after it. When the step takes input, you can edit it directly using the same rerun and REST API primitives documented for step-level reruns.
Why this is a big deal for AI-building teams specifically
Let’s follow the $$$: Prompt tuning takes ten, twenty—however many it takes to get the output right. In a workflow with model calls stacked in sequence, each of those attempts touches every call ahead of the one you're actually testing, unless something stops it from doing that.
Take a function with three model calls: extract data, generate a summary, draft a reply, orchestrated as steps. Assume the team is tuning the reply step, and each call costs $0.50.
Full rerun on every iteration:
| Calls per iteration | Iterations | Total calls | Cost | |
|---|---|---|---|---|
| Rerun from the start | 3 | 10 | 30 | $15.00 |
Rerun-from-step on every iteration:
| Calls per iteration | Iterations | Total calls | Cost | |
|---|---|---|---|---|
| Initial run | 3 | 1 | 3 | $1.50 |
| Rerun from step 3 | 1 | 9 | 9 | $4.50 |
| Total | 12 | $6.00 |
Ten iterations, 60% less cost, using placeholder pricing for illustration. The gap widens with more calls ahead of the step under test, or more iterations required to land the prompt—both of which are the normal working conditions of AI development, not exceptions to it.
Other annoying problems with rerunning from scratch that aren’t about cost
Duplicate side effects. A step that sends an email or charges a card, rerun from the start, re-executes that action on every iteration. That produces a duplicate message or a duplicate charge landing somewhere outside your system.
Rate limits. A step that calls a rate-limited provider, rerun from the start, consumes that limit again on every iteration, on calls that already succeeded. Ten iterations burn ten times the rate-limit budget on calls unrelated to what's being tested, and the run can start failing for reasons that have nothing to do with the actual problem.
Wall-clock time. A step with a sleep or a wait adds real elapsed time to a full rerun, on top of the cost. Waiting through that delay again, before reaching the step under test, turns a one-step fix into a multi-hour one.
The most essential mechanism for AI workflows (maybe)
Memoized step output and editable step input remove the need to wrap every step in idempotency keys or build custom bookkeeping to make reruns safe. The platform tracks and restores state at the step level by design; rerun-from-step exposes that state as something you can act on directly.
For a team iterating on AI workflows, ten prompt attempts should cost what ten prompt attempts cost—not ten full function runs.
