A $1,200/month AI Operation, Run Solo for $0 Incremental — The Caching + Dreaming Stack
Two patterns make the math work. Prompt Caching turns my persistent project context into a 90%-discounted prefix. Anthropic's Dreaming, announced five days ago, keeps the dynamic memory sharp. Together they're how I run 10+ agents on a single Claude Max subscription. Apart they're either expensive or stale.
I run 10+ AI agents across 13 projects on a single Claude Max subscription. A small operator paying retail API rates for that volume would be writing checks around $1,200/month. I pay $0 incremental on top of the subscription I already have.
Two patterns make that math work. One is Prompt Caching — the 90%-discount mechanism Anthropic and OpenAI both ship but most builders never reach for, because the UX of Claude and ChatGPT hides it. The other is Dreaming — the memory-consolidation feature Anthropic announced five days ago at Code w/ Claude.
Caching is what makes the stable half of my context cheap. Dreaming is what keeps the dynamic half from rotting. One without the other is half a system. This is how the two fit together — and what happened when the first dream pass on my trading bot surfaced a clean profit pattern that the next day's backtest crushed.
The dollar number, explained
The thing nobody spells out: both Anthropic and OpenAI discount cached prefix tokens by roughly 90%. If the first ~4K tokens of every request are stable — your persona, your project rules, your domain knowledge — you pay full price once, then near-nothing on every reuse.
A 10-agent operation running ~40 sessions/day with ~4K tokens of context each runs the math like this (illustrative, not invoice numbers):
| Setup | Estimated monthly API cost |
|---|---|
| Re-explain context every session (typical) | ~$1,200 |
.md context file, no caching | ~$900 |
.md context + Prompt Caching enabled | ~$240 |
That's a 5x swing on the same work. The cost calculator in my Context Engineering Kit lets anyone plug in their own usage and see the real number. v0.1, 2 stars at the moment — I'm under no illusion that I shipped a famous tool. I shipped a working tool. Those are different facts and both are fine.
The kit is just Markdown files. No framework, no dependencies, no install. Pick a template, fill in your persona / rules / knowledge / examples / anti-examples / recovery layer, save it as CLAUDE.md in your project root (or .cursorrules, or a cached system prefix on raw API calls). Twenty minutes to a working context that pays for itself the first week.
That covers the stable half — the parts of your context that don't change between sessions. But running ten agents over months produces a second, harder problem: the dynamic half — accumulated transcripts, partial conclusions, contradicting notes — keeps growing until it's lying to you.
That's the half Anthropic shipped a fix for five days ago.
What Anthropic shipped five days ago
Dreaming is a memory-consolidation feature for long-running Claude agents. When an agent has been working in a codebase or domain for hours or days, its context window fills with raw transcripts, tool outputs, partial conclusions, and contradictions. Dreaming runs an offline pass that scans accumulated state, extracts patterns, resolves contradictions, prunes stale references, and writes a clean consolidated memory back. The agent wakes up with a smaller, sharper, less-contradictory view of what it knows.
Anthropic described the design in their managed-agents post on 2026-05-06. A third-party reimplementation, dream-skill by grandamenium, formalized the four-phase loop into a skill anyone can install: Orient → Gather Signal → Consolidate → Prune & Index. That is the pattern I adapted.
Why the two halves need each other
Think of an agent's context as having two surfaces.
Stable prefix — persona, rules, project facts, domain knowledge. Changes slowly. This is what the Context Engineering Kit handles. Caching it makes it nearly free to reuse.
Dynamic accumulation — what happened yesterday, what we tried, what worked, what we decided, what we'd like to forget. Changes every session. This is what Dreaming handles. Periodic consolidation keeps it from drifting into contradiction soup.
Caching without consolidation: your prefix stays cheap but your memory file grows past 300, 500, 1000 lines, contradicts itself, and the model starts making decisions on stale facts. Consolidation without caching: your memory stays sharp but every session pays full freight to load it.
Together: the persistent stuff is paid-once-cached-forever, the dynamic stuff gets periodically pruned, and the same Claude Max subscription that costs me a flat monthly fee runs work that would cost a small operator over a grand if they paid by the token.
The 4-phase pattern (the meat)
I wrote a slash command, /dream-sniper, that runs once a week (Sunday 09:33 KST) on my trading bot's accumulated state. The four phases.
Phase 1 — Orient
Inventory all input surfaces. Count lines, note last-modified times, scan for pattern frequency. Don't read full files yet — just measure.
Inputs span four categories: current-state notes (active-work memos), accumulated trade logs (last 4 weeks), runtime logs (last 7 days), and bot health state files. The pass measures size and recency only. Actual content reading happens in Phase 2.
Output of Phase 1 is a small JSON snapshot: per-domain line count, last-modified timestamp, key pattern counts. Cheap by design.
Phase 2 — Gather Signal
Targeted extraction. Search categories are deliberately abstract — the actual bot-side entry conditions, position sizing, and threshold values stay in the bot, not in the writeup. The dream pass surfaces whether a category is showing signal; the bot keeps the what.
Categories the pass scans for: time-of-day pattern shifts, recurring failure modes per symbol, success-condition clusters, user decisions logged in Recent activity, corrections and preference changes that should propagate forward.
Heavy analysis is delegated to a domain-specialist subagent rather than pulled into the main context. This keeps the dream pass cheap and the analysis sharp.
Phase 3 — Consolidate
Integrate findings into the canonical memory. Convert relative dates ("yesterday", "last week") to absolute. Resolve contradictions by adopting the most recent. Drop stale references.
The critical safeguard here is a protected-file list. Certain memory files — autonomy rules, family PII, cross-project context, the user's personal preferences — are explicitly excluded from any dream-pass mutation. Without that list, a dream pass can cheerfully "consolidate" away information that is load-bearing across other projects, or worse, drift the user's stated rules.
Phase 4 — Prune & Index
Hard cap on file size. Old "Previous current state" blocks move to an archive folder. The memory index gets a one-line summary of the new insight.
The archive is not deletion. Everything stays recoverable. The active file stays sharp.
The first dream — what it found
First pass ran 2026-05-10 23:42 KST. Pool: the currently-running bot version's sub-era A, trades from 4/7 through 4/30, N=236.
Headline reconfirmation: realized R:R 0.499. Expected value per trade -$0.039. Cumulative PnL over 24 active trading days: -$9.25. Internally consistent — this strategy is a slow leak, not noise.
The new finding was a sharp time-of-day pattern in KST:
| Hour (KST) | N | WR | PnL |
|---|---|---|---|
| 00 | 12 | 83.3% | +$1.49 |
| 01 | 16 | 87.5% | +$0.94 |
| 04 | 13 | 76.9% | +$0.04 |
| 05 | 25 | 64.0% | +$0.33 |
| 07 | 28 | 42.9% | -$1.65 |
| 08 | 10 | 20.0% | -$1.69 |
| 10 | 19 | 10.5% | -$2.34 |
Late-night Asia (00-05 KST): WR 64-87%, net positive. Mid-morning Asia open (07-10 KST): WR 10-43%, net dump. The 10:00 hour alone leaked -$2.34 on N=19.
Cleanly suggestive. Easy story to tell: "the bot has an edge in low-volume Asia-night windows and gets shredded by the morning open."
The honest follow-up
The next day I ran a full-history backtest across all 920 live paired trades, twelve bot versions, 47 days of data. Entry-side features only (using post-trade observables like exit type or slippage at entry time is lookahead bias — first pass made that mistake, second pass fixed it).
Results across 69 univariate hypotheses:
- Bonferroni-significant signals (alpha = 0.000725): 0
- BH-FDR-significant signals (alpha = 0.05): 0
- Raw-p < 0.05 signals: 3 (hour 10, hour 8, Friday)
Of those three raw-p hits, the strongest (Friday, p=0.0235) turned out to be 102 of 128 Friday trades coming from one Friday — 2026-04-03. "Fridays are bad" was structurally "April 3rd was bad."
The dream's 00-05 KST signal does not appear in the corrected list. On the broader pool: hour 0 raw-p 0.039, hours 1-4 not even raw-significant, hour 5 actually loses. The pattern was real inside the bot's sub-era A but did not generalize across other bot versions.
The walk-forward 70/30 split (train cut at 04-20 05:35 KST) is the deciding test. Filter derived from train, applied to test:
| Set | N | Cum PnL | WR |
|---|---|---|---|
| Test baseline | 276 | -$16.61 | 43.1% |
| Test filtered | 250 | -$14.06 | 42.8% |
The filter saves $2.55. The 95% bootstrap CI under conservative costs: [-$23.90, -$11.53]. Firmly negative both ways.
And the most uncomfortable finding from the self-correction round: the worst three days (04-03, 04-25, 04-26) account for -$13.01, which is 69% of the entire 47-day -$18.82 loss. Drop those three days and the bot is nearly break-even.
The "00-05 is good" pattern was not a signal about time-of-day. It was an artifact of a few specific catastrophic trading days falling outside that window. Patch the symptom and the disease keeps eating.
Dreaming surfaced a hypothesis cheap. The backtest disproved it expensively. That is the right loop, and most "what is Dreaming" posts skip the second half.
The caching layer underneath
Here's how the whole loop runs without burning a token budget.
One healthcheck pass costs roughly 2k tokens. One weekly dream costs roughly 10k. Daily total under 14k tokens — well below 1% of an average user's monthly Claude Max limit. Most subscribers use 5-15% of their plan; the remaining 85% is unused quota that expires monthly. Putting a monitoring agent on that surplus costs $0 incremental.
But that's only true because the stable prefix — the project context the agent loads every session — is paid for once and cached. Without caching, each session would re-tokenize the full project context and burn the daily budget on lookup overhead rather than on actual work. With caching, the prefix lives in the discount tier and the per-session marginal cost collapses.
The infrastructure pattern: one slash command per cron, two crons per active project (healthcheck every 4 hours, dream weekly Sunday). Auto-rehydration on session start ensures the cron jobs survive PC restarts without manual intervention.
What this combo is good for, what it isn't
Good for:
- Running multi-agent operations on a flat-fee subscription without the cost scaling like an enterprise API bill.
- Memory hygiene that survives months. The 331-line memory file has a path to staying under 200 without manual archival.
- Hypothesis generation at near-zero marginal cost. The dream gave the next day's backtest its question.
- Reproducibility. Context-as-file means the same input produces the same behavior. You can A/B test the system, not just prompts.
- Multi-agent consistency. One shared context file means every agent in a swarm shares the same world model. Silent drift between agents is the most expensive bug in multi-agent setups and a shared
.mdeliminates it.
Not good for:
- Validating the patterns the dream surfaces. That's a separate, expensive step — backtest, walk-forward, multi-comparison correction. The dream is allowed to be wrong; the validation pass is the part that has to be right.
- Acting on dream output without a confirmation pass. The system should make hypotheses cheap and actions expensive.
- One-off, throwaway questions where no stable persona exists. If you're asking the model a single question once, caching has nothing to cache and consolidation has nothing to consolidate.
- Replacing domain analysis. The dream pass is shallow by design (grep + counts + delegated analyst). The real work happens in the follow-up.
Caching saves money on stable context; it does not validate hypotheses. Dreaming surfaces hypotheses; it does not fund itself. Together = sustainable. Neither alone = either expensive or stale.
Closing — the loop matters more than the tools
Neither Prompt Caching nor Dreaming is magic. Caching is a billing mechanism most builders never enable. Dreaming is a four-phase pattern any solo builder can implement in a weekend on top of an existing slash-command system. Both are documented openly: the Context Engineering Kit lays out the caching half (v0.1 today, more templates/examples/guides landing in staged drops), and Anthropic's managed agents post plus grandamenium's dream-skill repository are enough source material for the consolidation half.
The thing worth taking from this post is not "go install the kit and dream-skill." It's the loop: cache the stable, consolidate the dynamic, validate the surfaced. When all three pieces exist, a solo builder runs ten agents on a flat-fee subscription and the math stays sane. When only one or two exist, the system gets either expensive, confidently wrong, or both.
The bot keeps running unchanged. No filter was added. The next two weeks are observation.
Receipts, not promises.