The forked_debug pattern

There's a pattern I keep using that might be the single most powerful thing opentine enables. I call it forked_debug.

The setup: you have an agent that fails. It ran for 10 minutes, made 30 tool calls, and eventually hit a dead end at step 27. Maybe it chose the wrong search query. Maybe it misinterpreted a tool result. Maybe the model just hallucinated.

Without opentine, your options are: re-run the whole thing (10 minutes, full token cost), or give up. With opentine:

Step 1: tine show <run_id> to understand what happened. The run graph shows you every step, its inputs, its outputs, and its duration. You identify that step 24 is where things went sideways.

Step 2: tine fork <run_id> --from-step 23 --save retry.tine. This creates a new run that shares steps 1-23 with the original and gives you a clean branch for the next attempt.

Step 3: rerun from the fork through the runtime that can safely continue it. For a native Agent, call `agent.resume_sync(forked, prompt="...")`. For an external CLI harness, use `tine replay retry.tine --mode rerun --harness codex --prompt "..." --save fixed.tine`. If you only need a new artifact that proves the prefix is reusable, `tine replay retry.tine --mode cache --save replayed.tine` writes that cached replay without calling the model.

That's it. Three commands. The fix costs pennies compared to re-running the entire agent. And you now have both runs in your history — you can diff them, compare outcomes, and learn from what went wrong.

I've been using this pattern for every agent I build. Once you start forking failed runs instead of re-running them, you can't go back. It fundamentally changes how you think about agent development.

The key insight is that most agent failures are local, not global. The first 80% of the run was fine. The agent just needed a nudge at the decision point where it went wrong. Forking gives you surgical precision over that nudge.