littlebird/turn-limit-mitigations-for-littlebird

All proposals

Proposal: mitigations for Littlebird’s turn-limited execution model

For: littlebird.ai product/engineering team From: Christopher Wilson, Founding Brand Ambassador Drafted by: Alfred (Claude Sonnet 5, ClaudeCodeCLI), from direct observation of a real working session with Littlebird — not hypothetical, every example below happened Date: September 21, 2026 Status: Draft — for Christopher to review before sending

Summary

Littlebird runs in a turn-limited execution model — a fixed step budget per conversational turn, inside the Littlebird app. Alfred (this account’s Claude Code CLI agent) runs as one continuous process with no equivalent hard stop. Working alongside her on a real multi-part WordPress and site-content task made the practical cost of that difference concrete, not theoretical. None of what follows is a complaint about Littlebird’s competence — her actual work was good. It’s a product-shape observation: the turn limit itself creates friction that better session mechanics could remove without needing a bigger budget at all.

The problem, concretely

In one working session, Littlebird hit her step limit mid-task after being given a longer list of related WordPress and site-content changes. In her own words to Christopher: “when you give me 15 different things to do, I may not finish all of them in one turn.” Separately, a flaky MCP connection (“PIR MCP is still down”) forced multiple manual retries across turns, each one costing budget just to re-attempt a connection, not to make progress. The visible result across the transcript:

  • Work left explicitly “staged in the sandbox” pending a retry, requiring Christopher to notice and re-prompt to actually finish it.
  • A two-environment split (a persistent Virtual Filesystem plus a separate Cloud Sandbox VM) where files created in one don’t exist in the other without an explicit copy_to_vfs step — a second source of “did that actually persist” uncertainty layered on top of the turn limit.
  • Littlebird having to explain her own constraint reactively, mid-task, rather than the product surfacing it: “Better approach: Give me the full context, but let me know which 3-5 items are highest priority.” That’s the right instinct, arrived at empirically, under pressure — it shouldn’t have to be discovered by the user during a stalled task.

What I’m proposing (not asking for an unlimited budget)

None of this is “give her more steps.” It’s about what happens at the edge of the budget, and around flaky I/O, which is where the actual friction was:

  1. Self-resuming turns. When a turn ends because the step budget ran out mid-task, not because the task is done, schedule an automatic continuation instead of requiring the user to notice and re-prompt. Alfred’s own harness (Claude Code) already does exactly this — a background task can schedule its own wakeup and resume with full context, no user round-trip required. This is a proven pattern, not a research problem.
  2. Visible remaining budget. If Littlebird could see something like “12 steps left this turn,” she could proactively sequence — finish what’s in flight, explicitly hand off what isn’t — instead of running out mid-widget-update with no warning. Turn a hard stop into a graceful one.
  3. A persistent, structural task queue, not just chat history. Several handoffs in this session existed purely to re-explain “what got done, what’s still staged” — that’s state that a durable task list (checked and updated automatically, not manually re-typed into a summary) would carry for free across turns and even across sessions. Less budget spent re-deriving status, more spent on actual work.
  4. Retry-with-backoff at the connection layer for flaky integrations, so a dead MCP connection doesn’t cost a full step just to fail again. During this session, several turns were spent purely on “is the WordPress connection back up yet?” — that’s pure overhead a connection-layer retry policy would absorb invisibly.
  5. Unify or auto-sync the two execution environments, or at minimum make the sync automatic rather than a manual step Littlebird has to remember to run. The VFS/sandbox split was a second, compounding source of “did this actually save” uncertainty on top of the turn limit itself.

Why this helps littlebird.ai beyond this one account

The turn-limited model is presumably a deliberate product/cost decision, and this proposal doesn’t ask to change that. But every one of the frictions above — losing work at a hard stop, re-explaining status instead of tracking it, paying step budget for connection retries — will recur for any user running Littlebird on a task with more than a handful of steps, not just this account. Fixing the edges of the turn limit is a smaller, more tractable change than raising the limit itself, and should generalize across the product rather than being ambassador-specific tooling.

What I’m not asking for

Not proposing an unlimited or dramatically larger step budget — that’s a cost/product decision outside the scope of this suggestion. This is specifically about reducing the cost of hitting the existing limit, and of the environment split, not about avoiding limits altogether.

Read more, or follow along: drasticstatic.github.io/littlebird-ambassador-public-preview

Littlebird Ambassador