feat(review): per-PR spend cap and token-budget guardrail
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- java
- Domain
- ai, backend-api-design
Research direction
Start by locating the review flow that sends diff content to the model, then trace how retries and review passes are counted; the issue does not name specific files or tests. Identify where per-PR and per-review usage can be measured, and how the dashboard receives spend data. Done means configurable caps stop review work at the limit, post a truncation message, and show the cap and actual spend.
Written by the indexing model from the issue text.
Description
Problem Statement
There is no guardrail on per-PR spend. A very large diff or a retry storm against an expensive model can run up unexpected cost, which matters most for the self-hosted, bring-your-own-key audience.
Proposed Solution
Add a configurable per-PR (and per-review) spend/token cap. When a review would exceed the cap, stop early and post a clear message (e.g. "review truncated: per-PR budget reached") rather than continuing. Surface the cap and actual spend in the dashboard.
Alternatives Considered
- Rely on
max-diff-linesonly — bounds input size but not total spend across retries/passes.
Priority
Important
Code of Conduct
- I have searched for existing issues and this is not a duplicate.
- Dominant language
- Java
- Stars
- 35
- Forks
- 7
- Avg merge
- 9h 32m
- Merged PRs (30d)
- 144
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from devops-thiago/ThrillhouseBot
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
devops-thiago/ThrillhouseBot#1093 ·
Maintainers usually reply within 1 day
-
documentation enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
devops-thiago/ThrillhouseBot#321 ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
devops-thiago/ThrillhouseBot#46 ·
Maintainers usually reply within 1 day
-
fix(review): preserve tilde-fenced code during path screeningPossibly taken @devops-thiago claimed this today. Openbug java
Difficulty 4/5 1-2 days Newbie friendliness 35/100
devops-thiago/ThrillhouseBot#1111 · 1 comment ·
Maintainers usually reply within 1 day
-
fix(review): exclude TAP TODO and SKIP results from CI failuresPossibly taken @devops-thiago claimed this today. Openbug java
Difficulty 3/5 1-2 days Newbie friendliness 35/100
devops-thiago/ThrillhouseBot#1110 · 1 comment ·
Maintainers usually reply within 1 day
All issues in devops-thiago/ThrillhouseBot
Similar issues
-
`RedisList.reversed()` view returns an empty `range` and `trim` removes all elementsPossibly taken @CCCLL claimed this today. Openstatus: waiting-for-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
spring-projects/spring-data-redis#3461 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
wimdeblauwe/htmx-spring-boot#205 ·
-
[BUG] 增量 SSE 解析器未识别单独 CR 换行，导致事件无法及时交付Possibly taken @king-wwwhhh claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
langchain4j/langchain4j#6669 ·
Maintainers usually reply within 1 day
-
enhancement tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Albertinesilva/backend-engineering-journey-java-springboot#41 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
databricks/zerobus-sdk#910 ·
Maintainers usually reply within 1 day