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 tree 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 --edit-prompt "Use a more specific search query: focus on peer-reviewed papers only." This creates a new run that shares steps 1-23 with the original and diverges from step 24 onward.

Step 3: tine replay <new_run_id>. The new run executes from step 24 with the modified prompt. Steps 1-23 are cached and free. The replay costs only the tokens for the new steps.

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.