honey-loop

# Honey Loop A loop is the one place token waste *compounds*: `cost = per_tick × ticks`. The honey levers still apply inside each tick (less code, less prose), but a loop adds two leaks the single-shot levers don't cover — **re-paying for context** every wake-up, and **re-doing work** that didn't change. Cut those. ## The five levers 1. **Pace to the cache, skip the dead zone.** The prompt cache TTL is 5 min. - `< 270s` → context stays warm; right for actively polling external state. - `≥ 1200s` → one cache miss amortized over a long idle wait; the default for idle ticks (use **1200–1800s**). - **`~300s` is the worst choice** — pays the cache miss without amortizing it. Never round to "5 minutes." Drop to 270s or commit to 1200s+. 2. **Event-driven over polling.** Harness-tracked work (background `Bash`, `Agent`, `Workflow`) re-invokes you automatically on completion. Don't schedule a short tick to poll it — that re-reads full context for nothing. Set a long fallback heartbeat (`1200s+`) and let the completion notification drive you. Poll only external state the harness can't see (CI, a deploy, a remote queue), at a cadence matched to how fast that state actually changes. 3. **No-change short-circuit.** Re-generating output is the bulk of per-tick cost. Check cheaply first (a hash, a timestamp, a `git rev-parse`, a status field). If nothing changed: emit **one line** and reschedule. Don't redo the task, don't re-read the world, ...