|
Walks through four **textbook** patterns:
1. Progressive timeout with staged UI (10s / 30s / 60s)
2. Fast-fail + exponential backoff retry
3. Hedged parallel requests
4. Streaming with keepalive
Lands on a **hybrid** recommendation โ 15s first-token timeout, 30s between-token timeout, 90s absolute, one auto-retry. Sensible. Google SRE Book ch. 22. The answer a senior engineer gives in 30 seconds.
**What's missing:** no traps named, no acknowledgement that the *user* might want to bail out of a slow request, no questioning of the "wait then retry the same model" frame.
|
Spawns 6 isolated frames, surfaces a **wide set** of 30+ ideas across `economic-incentive`, `async-control-surface`, `gamification`, `perceptual-distortion`, `collective-intelligence`, `redundancy-race` clusters, then:
- โ
**Non-obvious pick:** *"rage-quit = instant abort + branch to cheaper/faster model"* โ a button that pulses hotter the longer you wait. One click cancels and re-submits to Haiku-class. The thing baseline never considers: **the slow model might just be the wrong model for this prompt.**
- Plus shortlist: scout-fork to alternate endpoints at 30s; daemonize the CLI with ticket IDs; race 3 LLM replicas, cache the winner.
- **20 traps flagged with one-line reasons** โ including the cute "stream tokens in reverse" and "patience-token billing" ideas before they cost engineering time.
|