review agent's review body exceeded the character limit: how to fix

TL;DR

Measure the body before submitting, keep the summary short (verdict plus top findings plus counts), and move detail into inline comments on the relevant lines. The review body is a cover page, not the report; anything long belongs on the lines it describes.

The problem

review agent's review body exceeded the character limit: how to fix

When to use

• The review submit call fails with a character-limit or body-too-long error
• The posted review body is visibly truncated mid-sentence
• The agent writes multi-thousand-word summaries
• Retries keep failing on the same length error

When not to use

• Individual inline comments hit the limit (same technique applies, but the unit is the comment)
• The submit failed for auth or validation reasons unrelated to length
• The body is long but under the limit (trim for readability, not for this fix)

Steps

1. Measure the body length before submitting

Count characters client-side and fail the step early if the body exceeds your budget, leaving headroom under the platform limit of 65535 chars.

BODY_LEN=$(printf '%s' "$REVIEW_BODY" | wc -m)
echo "review body: $BODY_LEN chars"

Expected output: a number. If it is anywhere near the limit, do not attempt the submit; compress first.

2. Compress the summary to verdict plus top findings plus counts

Keep: the verdict, the highest-severity findings (a handful, not all), and aggregate counts by severity. Cut: repeated explanations, full code quotes, and per-file walkthroughs.

Expected output: a summary a human can read in under a minute, well under the limit.

3. Move detail into inline comments

Anything cut from the body becomes an inline comment on the exact lines it describes, where it is more useful anyway. Expected output: the information is preserved, just relocated to where reviewers read it.

4. Split huge reviews when compression is not enough

For very large PRs, submit one review per directory or per severity band instead of one mega-review. Expected output: each review stays comfortably under the limit and reviewers can triage by section.

5. Set a prompt-level budget so the model rarely approaches the limit

Instruct the model to keep the summary under roughly 2000 chars. Expected output: the length problem stops recurring instead of being fixed per-incident.

Tool compatibility

• GitHub review body limit is 65535 chars on both REST and GraphQL submissions, github.com and GHES.
• gh CLI 2.x and raw API calls: the limit applies identically; measure client-side either way.
• Any review agent: the compress-and-relocate pattern is pipeline-agnostic.

Variant phrasings

review submission failed: body too long

Same fix. Step 1 turns it from a submit-time surprise into a pre-submit check.

AI review summary truncated on GitHub

Truncation means the body exceeded the limit at render or submit. Compress per step 2; check whether a retry loop appended duplicate text first.

65535 character limit on pull request review body

That is the hard ceiling. Budget for it explicitly (step 5) rather than discovering it per review.

Why it happens

Models write long summaries because nothing told them to stop, and long reviews feel thorough. The platform limit then rejects the whole submit, so one verbose summary can sink an otherwise good review. Length is a property of the prompt, not of the PR.

Edge cases

• Pending reviews accumulating many comments: the body limit applies to the review body, not the comment count, but huge comment counts deserve splitting too.
• Bodies with long code quotes: link to the lines instead of quoting them; quotes are the fastest way to blow the budget.
• Retry loops appending text: check that a retry did not concatenate two summaries before blaming the model.
• Non-ASCII text: count characters, not bytes; multi-byte chars can surprise byte-based budgets.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCgydNoPeO8d55iln3doVw