Skip to content

[pipeline] Opus unreachable since 2026-04-13T20:51Z — 100% Haiku fallback for 4+ days #175

@verkyyi

Description

@verkyyi

Source

14-day usage_log.md analysis (2026-04-18 CLI session), cross-checked against project_state.md self-reports.

Pattern

The scaffold's own reports understate this. project_state.md says "Haiku dominance 26.8%" but the actual usage_log data shows:

Date Haiku % Opus count Haiku count
Apr 10 0% 19 0
Apr 11 0% 20 0
Apr 12 0% 18 0
Apr 13 10% 18 2
Apr 14 100% 0 13
Apr 15 100% 0 14
Apr 16 100% 0 15
Apr 17 100% 0 12

Opus flipped off at 2026-04-13T20:51Z and has not returned over 96+ hours. This is not a partial rate-limit — it's total and persistent. Every claude -p --model opus invocation is being served by Haiku.

Why it matters (cost, not just reliability)

Per-turn cost comparison from the same window:

Workflow Opus $/turn Haiku $/turn Haiku premium
analyze $0.039 $0.041 +5%
evolve $0.039 $0.042 +8%
watcher $0.041 $0.050 +22%

Haiku is NOT cheaper per turn on these workloads. And because Haiku takes more turns to reach the same conclusion (cf. coder #173: Haiku hit 41/40 max-turns for $4.22 on a task Opus would likely have finished), total cost rises.

The assumption "fallback saves money" baked into current pipeline reasoning is empirically wrong on this repo's workload.

Proposed investigation

  1. Check account rate-limit status: is Opus 4.6 genuinely quota-capped, or is the claude -p --model opus request resolving to opus → Haiku via some alias/routing issue?
  2. Check CLAUDE_CODE_OAUTH_TOKEN — has it been downgraded to a Haiku-only plan, or expired and silently replaced?
  3. Inspect one recent "Opus" run's raw API response. The usage_log reports model:claude-haiku-4-5-20251001 from modelUsage keys — confirm this is the actual inference model, not a fallback flag.
  4. If it IS a persistent rate-limit: raise the question of whether current cron cadence is structurally incompatible with available Opus quota. Either reduce cadence further or upgrade the account.

Proposed action

Once root cause is known, one of:

  • Restore Opus access (account/billing fix) → immediate 5-22% per-turn cost reduction
  • Explicitly pin workflows to Haiku where acceptable, and acknowledge cost-per-quality tradeoff
  • Document in CLAUDE.md that "Opus" is effectively aliased to Haiku at this account tier

Risk of leaving it

  • Cost reporting across the scaffold is misleading (baseline assumes Opus)
  • Complex tasks like coder on 11-file changes keep failing at max-turns because Haiku needs more turns
  • Future evolve findings that recommend Opus-based features (prompt caching tuning, extended context) are unactionable

Evidence artifacts

  • state/usage_log.md (full 14d window)
  • state/agent_log.md (reports "rate-limit" events Apr 14-15 ~25h, but never attributes the subsequent permanent switch)

Needs-human

Requires account-level investigation (billing, tokens, plan tier) that the coder agent cannot perform.


Surfaced from 14-day retrospective CLI session 2026-04-18.

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-humanRequires human action (external platform, secrets, permissions)pipeline-fixPipeline failure to fix

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions