diff --git a/.github/workflows/groom.yml b/.github/workflows/groom.yml
index a956994..455146e 100644
--- a/.github/workflows/groom.yml
+++ b/.github/workflows/groom.yml
@@ -342,9 +342,43 @@ on:
           this many lines, it is NOT opened as a giant PR — it is filed as a
           `groom` issue for a human instead, so nothing balloons unreviewed.
           Ignored unless `builder` is true.
+
+
+          The default is deliberately BELOW the org's 1000-line human PR cap
+          (`pr-size.yml` `max_lines`), and copying that number here would loosen
+          this more than it looks. Two reasons. (1) Different counting basis:
+          `pr-size.yml` counts *non-generated* changed lines — it strips
+          lockfiles and generated output first, and offers an `oversized-ok`
+          bypass label — whereas this counts changed lines straight off
+          `git diff --cached --numstat`, with no content-based exclusions. Note
+          that this basis is not a byte budget: `numstat` reports `-` for binary
+          files (counted as 0 here), and a line is a line however long, so one
+          minified line clears any ceiling. It bounds review effort in the
+          reviewable case, not patch size in the worst case — another reason not
+          to spend the headroom the human cap allows. (2) Different risk: the
+          human cap is advisory on a diff
+          whose author chose the scope and can defend it in review; this is a
+          hard refusal on a diff with no author to interrogate, where the
+          failure mode is a reviewer approving 900 plausible-looking
+          machine-written lines because nothing in it looks wrong. The machine
+          does not get the same benefit of the doubt, on purpose.
+
+
+          Raised 400 → 600 on 2026-08-02 (BE-6161) on measured evidence: across
+          both builder repos, 49 `groom` issues produced 7 bails and exactly ONE
+          patch-too-large (403 lines, three over) — 400 was not systematically
+          tight, it caught one boundary case, so 600 buys headroom for that
+          shape without a large jump. This default is the reviewed knob: it is a
+          `_LOCKED_KEY` in `.github/groom/config.py`, so the un-reviewed layer —
+          a repo's `GROOM_CONFIG` Actions variable, editable with repo write and
+          leaving no diff — cannot raise it. It can still be raised per-repo the
+          reviewed way, by a `with: pr_size_limit:` in that repo's caller (the
+          builder job reads `inputs.pr_size_limit` directly), which is a commit
+          on a branch someone has to approve. So auditing a repo's effective
+          ceiling means reading its caller, not assuming this default.
         type: number
         required: false
-        default: 400
+        default: 600
     secrets:
       ANTHROPIC_API_KEY:
         description: Anthropic API key the finder + verifier agents bill through.
@@ -1811,7 +1845,7 @@ jobs:
         run: |
           set -euo pipefail
           mkdir -p /tmp/out
-          # `type: number` can arrive as a fractional string (e.g. 400.0) that the
+          # `type: number` can arrive as a fractional string (e.g. 600.0) that the
           # integer-only `-gt` test below would abort on under `set -euo pipefail`,
           # skipping the patch upload. Floor it to an int first (mirrors the file
           # job's MAX_FINDINGS handling).