Token-rich vs Token-poor Loops in Loop Engineering
Token-rich loops pass large context into every iteration. Token-poor loops pass summaries, retrieved memory, or scoped observations to reduce cost.
The example below was recalculated with the browser-only budget calculator; it is an illustration, not provider pricing.
Why it matters
Context is multiplied by every iteration and every run. A loop that re-sends a huge prompt each turn is easy to build but expensive and more likely to hit context limits; a token-poor loop is cheaper and faster but needs real memory and state management.
Practical checklist
- Estimate input tokens per iteration before scheduling
- Decide what to keep, summarize, retrieve, and forget
- Pass only the observations relevant to the next action
- Re-estimate cost when iterations or runs/day increase
Example
Instead of re-sending an entire repository each iteration, a token-poor loop passes a summary of the last error and the few files involved — cutting input tokens from 80k to 8k per turn.
Common failure modes
Practical evidence
Illustrative token calculation
Assume 8,000 input tokens and 1,500 output tokens per iteration, eight iterations, and four runs per day. Provider prices are deliberately omitted because they change.
80,000 input tokens × 8 iterations = 640,000 input tokens per run before retries.
8,000 input tokens × 8 iterations = 64,000 input tokens per run before retries.
Keep full context only when omitted material can change the decision; otherwise summarize or retrieve the smallest relevant evidence.
Enter current provider prices in the calculator. These token counts are illustrative and are not a pricing promise.