The canonical agent-jury workflow (.github/workflows/agent-jury.yml, v1 = 13cc52f9) hardcodes two values on the Rust branch that no caller can influence, and both bite hardest on exactly the PRs the jury matters most for — large Rust diffs.
1. MAX_TOKENS=1000000, uncapped
Line ~264 sets MAX_TOKENS=1000000 whenever a diff has Rust files and >50 lines (4096 otherwise). There is no max_tokens entry under workflow_call.inputs (only runner / model / fast_model / api_url / diff_budget / timeout_minutes) and no env override — AGENT_JURY_MAX_TOKENS has zero hits in the file. A caller cannot adjust it, because the branch condition is diff shape rather than anything a caller passes.
Empirically this works today — the LiteLLM gateway accepts it. cerebral-work/reverie run 32418697307 logged Using model=glm-5.2 max_tokens=1000000 (rust=5 lines=507) and delivered a verdict. So this is a robustness and portability gap, not an active outage. Recording it because it is one gateway-config change away from a 400 on every substantial Rust PR estate-wide, and a now-retired local fork in reverie (cerebral-work/reverie#1630, CER-2015) suspected precisely that failure mode back when jury errors were still undiagnosable.
Ask: cap it to something the configured models actually support, or add a max_tokens input defaulting to current behavior. The HTTP-status branch this workflow already has will surface the gateway's own limit if a cap is ever set wrong, so a conservative default is cheap to iterate on.
2. curl -m 300 may be too short for large Rust reviews
The request uses a 300-second ceiling. On cerebral-work/reverie PR #1688, run 32433003648 logged Using model=glm-5.2 max_tokens=1000000 (rust=9 lines=1221) and then HTTP 000 after ~300 s (00:31:52 → 00:36:53). The log cannot distinguish "gateway unreachable" from "the review genuinely needed more than 5 minutes", but the timing lands exactly on the ceiling, and a 1221-line glm-5.2 review plausibly exceeds it.
If that reading is right, the workflow currently cannot review its largest inputs — and because HTTP 000 is also what an egress failure produces, the two causes are indistinguishable from the log.
Ask: make the curl timeout a workflow_call input (the existing timeout_minutes governs the job, not the request), and/or distinguish curl's own exit code 28 from a transport failure in the error message so the two causes stop looking identical.
Both are single-line changes; grouping them because they are the same surface — the Rust/>50-line branch's fixed knobs.
The canonical agent-jury workflow (
.github/workflows/agent-jury.yml, v1 =13cc52f9) hardcodes two values on the Rust branch that no caller can influence, and both bite hardest on exactly the PRs the jury matters most for — large Rust diffs.1.
MAX_TOKENS=1000000, uncappedLine ~264 sets
MAX_TOKENS=1000000whenever a diff has Rust files and >50 lines (4096 otherwise). There is nomax_tokensentry underworkflow_call.inputs(only runner / model / fast_model / api_url / diff_budget / timeout_minutes) and no env override —AGENT_JURY_MAX_TOKENShas zero hits in the file. A caller cannot adjust it, because the branch condition is diff shape rather than anything a caller passes.Empirically this works today — the LiteLLM gateway accepts it. cerebral-work/reverie run
32418697307loggedUsing model=glm-5.2 max_tokens=1000000 (rust=5 lines=507)and delivered a verdict. So this is a robustness and portability gap, not an active outage. Recording it because it is one gateway-config change away from a 400 on every substantial Rust PR estate-wide, and a now-retired local fork in reverie (cerebral-work/reverie#1630, CER-2015) suspected precisely that failure mode back when jury errors were still undiagnosable.Ask: cap it to something the configured models actually support, or add a
max_tokensinput defaulting to current behavior. The HTTP-status branch this workflow already has will surface the gateway's own limit if a cap is ever set wrong, so a conservative default is cheap to iterate on.2.
curl -m 300may be too short for large Rust reviewsThe request uses a 300-second ceiling. On cerebral-work/reverie PR #1688, run
32433003648loggedUsing model=glm-5.2 max_tokens=1000000 (rust=9 lines=1221)and thenHTTP 000after ~300 s (00:31:52 → 00:36:53). The log cannot distinguish "gateway unreachable" from "the review genuinely needed more than 5 minutes", but the timing lands exactly on the ceiling, and a 1221-line glm-5.2 review plausibly exceeds it.If that reading is right, the workflow currently cannot review its largest inputs — and because
HTTP 000is also what an egress failure produces, the two causes are indistinguishable from the log.Ask: make the curl timeout a
workflow_callinput (the existingtimeout_minutesgoverns the job, not the request), and/or distinguish curl's own exit code 28 from a transport failure in the error message so the two causes stop looking identical.Both are single-line changes; grouping them because they are the same surface — the Rust/>50-line branch's fixed knobs.