Skip to content

v0.2.30: feat: ask the user how to proceed when reviewer quota is exhausted

Choose a tag to compare

View all tags
@OrenAshkenazy OrenAshkenazy released this 05 Aug 12:16
· 24 commits to main since this release
v0.2.30
6b8f58e

Problem

A reviewer refusal was terminal. The loop stopped, recorded a human outcome, and the run was over.

But the two refusal causes aren't the same:

  • Service withdrawn (Gemini sunset, "no longer supported") — gone for good, nothing the user can do.
  • Usage quota spent (You have reached your Codex usage limits for code reviews) — a billing limit the user can lift in a minute.

Ending the run on a quota cap throws away a cycle the user would happily have paid to keep. Real case: OrenAshkenazy/SignalScout#168 (comment)

Change

  • REVIEWER_REFUSAL_RES patterns are now labeled REFUSAL_QUOTA / REFUSAL_WITHDRAWN; reviewer_refusal() returns the label as kind, which flows through run_wait_chunk and the JSON wait payload unchanged.
  • print_reviewer_refusal() on a quota refusal prints an ask-the-user block (stop + record, or upgrade/add credits and re-run the same wait) instead of the record-and-stop instruction. Withdrawn keeps the existing terminal wording.
  • SKILL.md splits the refused status by kind. On quota the loop prompts immediately via the runtime's choice mechanism and does not record a terminal outcome or re-request the review — the re-review was already delivered and refused, so re-asking spends a cycle for nothing.

Verification

  • pytest — 701 passed, including 4 new tests: kind labeling for both refusal families, quota stop-block wording, and withdrawn offering no retry path.
  • Ran the classifier against the live Codex comment body from SignalScout#168: classifies quota_exhausted and prints the ask block with the billing dashboard link intact.

🤖 Generated with Claude Code

https://claude.ai/code/session_018FBzqdm2VrefT9QDJeYQdL

Summary by Sourcery

Distinguish recoverable quota exhaustion from permanent service withdrawal in reviewer refusals and update loop behavior and docs to prompt users appropriately instead of always terminating.

New Features:

  • Label reviewer refusals as either quota_exhausted or withdrawn and surface this kind in the wait JSON payload and CLI output.
  • Prompt operators with explicit choices when a reviewer refusal is due to quota exhaustion, allowing them to either stop the loop or upgrade/add credits and retry the same wait.

Enhancements:

  • Refine reviewer refusal detection patterns to classify usage-limit and service-sunset messages into separate categories.
  • Update SKILL documentation to describe the new refusal kinds and the corresponding runtime behavior for each.

Tests:

  • Add tests covering refusal kind labeling, JSON wait payload contents, and the different stop-block messages for quota exhaustion versus service withdrawal.
Assets 2
Loading