[FEATURE] Queue reservation for sessions awaiting manual approval to prevent speed penalty for code review

Resolved 💬 2 comments Opened Mar 13, 2026 by sharpTrick Closed Apr 10, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When using Claude Code in auto-accept mode, the next request fires immediately after each edit completes, so any queue wait time overlaps with Claude's execution. The developer experiences a continuous flow. In normal mode with manual approval, the session sits idle from the server's perspective while the developer reviews the proposed diff. The queue wait doesn't start until after the developer approves and sends the next request. The result is that review time and queue wait time stack on top of each other rather than overlapping.

The per-interaction queue wait is likely the same in both modes. The difference is that auto-accept hides it behind continuous execution, while manual review exposes it as dead time the developer has to sit through after every approval. Over a session of 20-30 reviewed edits, this adds up to a meaningfully worse experience for developers who choose to review carefully.

I work on production codebases where reviewing every proposed change matters — bad edits to build configs, database migrations, or auth flows can have serious downstream consequences. The cumulative speed difference is real enough that it tempts me to switch to auto-accept just to maintain a reasonable workflow. The tool shouldn't create an incentive to skip code review.

Proposed Solution

When Claude Code proposes an edit and is waiting for the user to approve or reject, the session should reserve its place in the processing queue. The user isn't consuming compute while reading a diff — they're making a decision. When they respond, the next request should be prioritized rather than cold-starting from the back of the line.

Think of it like a queue token: you hold your spot while you review, and you don't lose it for exercising good judgment.

Alternative Solutions

Instead of an explicit reservation mechanism, prioritize incoming requests based on time elapsed since the session's last server interaction. Sessions that have been idle longer (because the developer was reviewing a diff) would receive higher priority in the queue than sessions that just finished an interaction moments ago. This naturally rewards manual review without requiring a separate reservation system — the longer you spend reading a diff, the higher your priority when you respond. It also degrades gracefully: sessions that have been idle for hours don't need priority, so a reasonable cap could prevent stale sessions from jumping the line.

Priority

High - Significant impact on productivity

Feature Category

Performance and speed

Use Case Example

Developer is working on a production app in normal approval mode. Claude proposes an edit to a Room database migration. Developer spends 45 seconds carefully reviewing the diff. During those 45 seconds, nothing is queued — the session is idle from the server's perspective. Developer approves, and only then does the next request enter the processing queue with the same wait time it would have had anyway. In auto-accept mode, that next request would have fired instantly after the edit completed, so the queue wait overlaps with Claude's execution rather than stacking on top of the developer's review time. The result is that manual review adds dead time that auto-accept doesn't have — not because the queue is slower, but because there's no reservation holding the developer's place while they're reading the diff.

Additional Context

This is most noticeable on Pro/Max plans with shared throughput. The speed difference between the two modes isn't about one being throttled — it's about whether queue wait time is hidden behind continuous execution or exposed as dead time after each review. The cumulative effect over a full session is significant enough to change user behavior, which is the core concern. A system that structurally rewards skipping code review is misaligned with Anthropic's stated values around human oversight of AI-generated output.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗