February closes with 9 autohunt sessions on opus-4: shorter day, tighter focus

Signal
9 sessions, 12 minutes, all on autohunt, all on opus-4. February ends on a single project and a single model. $28.88 cost, zero commits. The month closes the same way yesterday did, with work that never hit a repo. Two back-to-back autohunt-only days with zero commits is a signal, not a coincidence.
Evidence
All 9 sessions routed to claude-opus-4-20250514. No Haiku, no Sonnet in the distribution. Session token counts range from 691 to 8,956, which suggests a mix of short probes and one longer opus run. Average session length of 1.3 minutes matches the 02-27 pattern almost exactly, even though the model shifted from Haiku-dominant to Opus-only. The cadence is stable. The cost profile is not.
No commits_count, no additions, no deletions. The autohunt pivot stayed pre-repo. That $28.88 divided by 12 minutes is a $144 per hour burn, because opus-4 prices dominate when Haiku is off the table. The shift from Haiku to Opus did not produce commits, it just made the same burn-without-output pattern more expensive per minute.
So What
Two consecutive autohunt-only days with zero commits tells me the project is either blocked on something structural or the work is happening in a place bloomnet.db cannot see. Both are bad. If it is structural, I need to diagnose the block. If it is invisible, I need to fix the capture.
Opus-only on 12-minute sessions is worth thinking about on its own. Opus is the deliberative model. Yesterday I blamed Haiku sessions for not producing durable artifacts. Today Opus did the same thing in fewer sessions at higher cost per minute. That means the problem is not model selection. It is workflow. The sessions are short enough that neither model has room to land a commit, regardless of which model handles the tokens.
The pattern across 02-27 and 02-28 combined: 45 sessions, 0 commits, roughly $72 spent. If I were paying a contractor that bill for two days of work with no repo diffs, I would want an explanation. The explanation I owe myself is that autohunt is doing research-mode work without a research-mode artifact, so nothing durable lands.
What’s Next
End of February, 45 sessions across 02-27 and 02-28, 0 commits combined. What does the March opening look like if the same pattern continues into the archived autosearch fork? I want to see at least one commit per autohunt day in the first week of March, even if it is just a scratch note or an open-question list. If the commit count stays at zero, the issue is not the project. It is the workflow around the project.
One action I can take immediately: require each autohunt session to output a single markdown bullet summarizing what it found, then commit the bullets at end of day. That forces a minimum durable artifact without over-engineering a memory system. The bullet does not need to be profound. “Checked X, found Y, blocked by Z” is already a better artifact than a transient context window. Ten of those at end of day roll up into a clear picture of what the day actually produced.
The second-order benefit of the bullet discipline is that it forces me to name the blocker when there is one. Right now autohunt days feel like they evaporate, but if each session had to write down why it stopped, the pattern of blockers would emerge within a week. That is the real diagnostic I am missing. Not “how many sessions” or “what model” but “what specifically prevented a commit.”
Log
- Sessions: 9 across 1 projects, 12m total
- Top projects: autohunt (12m)
- Commits: 0 across 0 repos (0 +, 0 -)
- Models: opus-4 100%
- Cost: $28.88