36 sessions into autohunt, 44 minutes, zero commits: sprint with no durable output

Signal

36 sessions on autohunt in 44 minutes, $43.04 burned, and not a single commit landed. The Haiku-heavy distribution signals tool-call loops, not deliberative architecture work. This is the failure mode of agent-driven exploration without a commit gate, captured in a single day’s metrics.

Evidence

32 of 36 sessions were scoped to autohunt, with the remaining 4 split between misc and mycraft. Average session length was 1.2 minutes, which is exploration bursts, not deep work. A 1.2-minute session cannot produce durable output. It can barely produce a coherent question. The model distribution skewed heavily to claude-haiku-4-5 with a single opus-4 session at 14,969 tokens, which is probably the only moment of the day where the agent had time to think through something larger than a single tool call.

Zero commits across any repo today. The work stayed in scratch buffers and agent runs. That $43.04 spent across 44 minutes is a roughly $59 per hour burn rate, with no shippable diff to show for it. In a normal deep-work day that burn rate buys a feature. Today it bought transient context that evaporated on session exit.

So What

This is the failure mode that matters. Haiku sessions that spawn and die in under two minutes rack up cost while producing nothing the next session can build on. Each one probes, finds something, then terminates before anything crystallizes into code. The knowledge lived entirely in transient context windows. The next session starts blind.

The pattern is diagnosable: when you see many short Haiku sessions on the same project with zero commits, the agent is stuck in a loop where it keeps rediscovering the same facts. A commit gate, even for scratch commits on a throwaway branch, forces at least one durable artifact per session. Without that gate, the default is to pay for exploration that benefits no future session.

The deeper issue is architectural. Autohunt right now is a project where I have not built the memory layer that lets session N+1 inherit session N’s investigation. Until that exists, every session pays the full discovery cost again, which is exactly what today’s metrics show.

What’s Next

If every autohunt session is a fresh probe, what is the memory layer that lets tomorrow’s session inherit today’s investigation instead of redoing it? The options are roughly: a persistent scratch file in the repo that every session reads first, a skill that captures the current investigation state on exit, or a more aggressive commit cadence where even unfinished work lands as WIP commits. The cheapest is probably the scratch file. The most durable is the skill. The most immediate is the commit cadence.

I will pick one tomorrow and watch the metrics. If the Haiku-burst pattern persists into a third day, the problem is not the tool, it is the workflow.

One more observation worth keeping. The single Opus session at 14,969 tokens is almost certainly the moment of the day where something real got investigated. If I had designed the session flow to channel more of the day into that mode instead of the Haiku bursts, the cost profile would look different and the commit count might not be zero. The takeaway is not that Opus is better than Haiku. It is that session length is the variable that matters. A 15-minute Opus session with a clear question is strictly more productive than a dozen 90-second probes across the same surface area. Tomorrow’s experiment is to force at least one longer session per day with a pre-stated goal.

Log

• Sessions: 36 across 3 projects, 44m total
• Top projects: autohunt (38m), misc (Documents) (5m)
• Commits: 0 across 0 repos (0 +, 0 -)
• Models: haiku-4-5 dominant, one opus-4 session
• Cost: $43.04