This week — 23.5M core tokens (43% of your typical 5-hour window); strong cache reuse but Opus is oversized for operational tasks.
Where it's going — auto-social-posting (29%), research-console (24%), ai-learning-path (21%) drive 74% of usage; Opus claims 50% despite light total volume, signaling model-routing gaps.
Optimize - Downgrade auto-social-posting to Haiku (29% of usage; content generation and pipeline runs don't need Opus—saves ~5% of window per session and frees capacity for new work). - Route anim and spike projects to Haiku (5% combined; video/CLI operations cost 60–70% less on Haiku, reclaiming another ~3% of window). - Reserve Opus for ai-learning-path prompt iteration only (currently 21% usage; video rendering and Studio updates run fine on Sonnet, cutting this project's footprint by ~30%). - Start fresh research-console sessions every 3–4 days (24% of usage; cache amplification 202.9× is efficient per-turn, but dragging context across multiple projects limits throughput—breaking mid-week and reloading scoped memory trades per-turn reuse for session velocity, fitting 20–25% more distinct work in the window). - Consolidate spike/cd9fc51521f7/678b16ee3190 into one weekly batch session (5% split across loose contexts; eliminates per-session memory reload overhead, saving ~2–3%).
6 earlier reviews
This week 21.5M core, 0.58× typical 5h window—strong efficiency, but context drag is extreme (197× amplification).
Where it's going Three projects dominate (research-console 33%, auto-social-posting 32%, ai-learning-path 25%). Opus 42%, Sonnet 37% is balanced; the bottleneck is cache weight, not model choice.
Optimize
- Scope memory to active project: Load only research-console + globals in research-console sessions, not all 8 projects. Halves context drag. (Aligns with your session-switch rule.)
- ai-learning-path to Sonnet 80%: Generation + testing is Sonnet-tier. Move routine work off Opus. Drops 42% → 35%.
- Auto-social-posting batch: Group 3–5 reel prompts in one call if overlapping; 32% usage suggests per-post iteration. Sonnet is cheap for batch.
- Headless pipeline runs: Verify claude -p prompts (reader.py) are self-contained, not pulling session context.
- Cache rebuild 3% (healthy): Don't break reuse ratio; scope what you cache instead.
This week
20.7M core tokens over 16.3k messages (1.55× rolling 5-hour typical); cache amplification at 184× indicates context is being re-sent inefficiently.
Where it's going
Three projects dominate evenly (research-console 31%, ai-learning-path 28%, auto-social-posting 28%), with Opus taking 55% of load — mostly deterministic work (categorization, filtering) that Sonnet handles fine.
Optimize
-
Cut cache amplification from 184× to <100× — Scoped reads with
grep+Read(offset+limit)+/compactbetween phases stop re-sending full 30MB contexts every turn. Cuts window usage by ~50% on cache alone. -
Route categorization/filtering from Opus to Sonnet (drop Opus 55% → 40%) — Research pipeline's verdict (APPLY/IGNORE), schema validation, and routing are deterministic; Sonnet is faster and sufficient. Reserve Opus for novel routing conflicts only.
-
Batch research pipeline into one Workflow (research-console 31%) — 16.3k messages suggests per-repo turns rebuild context sequentially. Pipeline 50+ repos in parallel agents (shared context once) instead of 50 serial turns. Saves ~40% of that project's load.
-
Lock AI Learning Path scope + TDD upfront (ai-learning-path 28%) — Iterative tweaks (commit → test → adjust) pyramid context cost. Use
superpowers:test-driven-developmentat session start to nail requirements; fewer re-runs mean fewer context carries. -
Template auto-social-posting to one daily pass (auto-social-posting 28%) — Per-post iteration rebuilds context repeatedly. Lock generation prompt + model routing (Gemini Flash + edge-tts). One full pass/day + spot fixes costs far less.
This week 16.5M core tokens over 8,423 messages; 36% below rolling 5h typical, but cache drag (1.98B cached tokens read, 125.6× amplification) reveals bloated context per turn.
Where it's going auto-social-posting (46%) and research-console (25%) concentrate volume. Opus at 28% is overprovisioned—most of this is deterministic work that Sonnet or Haiku can handle.
Optimize
- Fix cache amplification (125.6×): Reading 125 cached tokens per core token signals massive context per turn. Compress heavy sessions with /compact; pin facts to memory instead of re-sending; read files with offset+limit. Target <40× amplification.
- Downgrade auto-social-posting to Haiku (46% of volume): Reel generation (TTS → whisper → layout) is deterministic pipeline. Benchmark one full cycle on Haiku; if quality holds, swap default. ~7–8% weekly savings.
- Sonnet for reviews, Opus for design only: Routine diffs/tests run fine on Sonnet. Opus (28%) should be <15%—reserve it for novel architecture and complex debugging. ~5% savings.
- Consolidate research-console parallel reads: If catalog pipeline fans out agents per repo, batch 3–5 summaries into one prompt instead. Cuts agent spawning overhead and context fragmentation.
- Stop re-sending context in /loop runs: State-threaded loops (research, diagram gen) shouldn't reload full context each iteration. Thread state via files or agent outputs instead. Reduces cache per cycle.
This week
22.9M core tokens over 9,991 messages; 0.66× typical 5h rolling window—a light week, but cache amplification is the bottleneck.
Where it's going
research-console (38%) and auto-social-posting (33%) dominate; Opus carries 57% of the load despite Sonnet/Haiku being adequate for most reads, summaries, and mechanical work.
Optimize
-
Move research-console reads off Opus (38% of usage) — Most crawl/read/categorize work is lookup + summarization, not reasoning. Default to Sonnet here, reserve Opus for cross-project synthesis or schema decisions. Frees ~15–20% of model capacity per session.
-
Scope large YAML/JSON reads before caching — Cache amplification at 89.8× indicates huge files (catalog.yaml, state/*) are dragged through each turn. Before
Read,grepthe key section (e.g.,grep "^ - name: research-console" catalog.yaml), then Read with offset+limit. Can reduce effective context footprint by 2–3×. -
Batch auto-social-posting operations (33% of usage) — If posting to 3+ platforms, fan out with parallel agents in one session instead of sequential sessions per platform. Reuse one cache context instead of rebuilding. Cuts cache rebuilds by ~66% on this workload.
-
Haiku for pipeline mechanical ops (AI-learning-path, financial-analysis batch work) — Video narration, i18n batch rendering, schema transforms don't need reasoning tiers. Move to Haiku for <1% of model cost; reserve Opus budget for architecture decisions.
-
Explicit
/compactbetween project switches — You already know this (memory: context-hygiene rule); calling it explicitly before context-hop resets the cache state cleanly instead of dragging 200MB of research context into a UI sprint.
This week: 16.2M core tokens over 8,205 messages—lighter than typical (0.51× rolling 5h)—but 103.3× cache amplification is a critical efficiency leak.
Where it's going: auto-social-posting (43%) and ceo-workshop (26%) absorb two-thirds; Opus at 52% despite Sonnet being sufficient for content and routine work.
Optimize:
- Crash cache amplification from 103.3×. Use /compact weekly; grep before Read; avoid full-file loads for single symbol searches. Goal: <50×. Saves 40–50% on context rebuilds per turn.
- auto-social-posting → Sonnet. 43% of weekly tokens on repetitive generation. Sonnet is ~40% cheaper per message. Validate on 10 posts; swap model if quality holds.
- Batch ceo-workshop feedback loops. If you're cycling design→feedback→tweak→feedback, gather all feedback once, implement, validate once. Halves round-trip messages and context rebuilds.
- Pre-grep before dispatching agents. ceo-workshop (26%) + research-console (17%) likely spawn Explore on full trees. Grep the target symbol first; send agents narrow file paths instead.
This week
17.5M core tokens over 9,245 messages; lighter than your rolling average (0.81x typical), but cache amplification at 154.6× signals massive context drag each turn.
Where it's going
Three projects own 85% (auto-social-posting 35%, research-console 27%, ceo-workshop 23%). Opus runs 58% of all work; likely overkill for routine feature shipping across the first two.
Optimize
-
Compact 1.5–2× more aggressively. Context rebuild is low (4%) — caching works — but you're dragging bloated context every turn. Compacting every 30–45 min instead of 60 would halve the carried load at no accuracy cost.
-
Route auto-social-posting and ceo-workshop to Sonnet. These are feature work / integration, not deep analysis. Saves ~30–40% per turn; keep Opus for research-console only. (Addresses 58% → ~40% Opus).
-
Grep + offset/limit before every Read. Your CLAUDE.md already mandates this; 154.6× amplification suggests full-file reads are the norm. Find the symbol with grep, identify the range, Read lines N–M only. Cuts context load per query 3–5×.
-
Batch sequential agent spawns into one turn. "Research, then process, then format" as separate agent calls reloads context three times. Combine with
agent().parallel()or.pipeline()inside one session turn. -
Declare scope upfront. Start each session with "I'm working on: [task]. Relevant files: [3–5]. I will not read outside this." Forces prioritization and prevents context drift across unrelated files.