Claude Code 2.1.287 large MCP results: Sume's include_results answer

Claude Code 2.1.287, released on October 1, 2026, fixed Claude being told to page large MCP results saved as JSON with Read's offset and limit. For Sume you can avoid the situation: call jobs_wait with include_results: true so each finished job's result comes back in the same answer, and read any ids it names in results_omitted with one batch jobs_result.

The Claude Code line is from its changelog, read on 2026-10-02. The Sume behaviour is from Jobs and results and the hosted tool list in MCP tools and gates. The changelog line does not say when Claude Code saves a result to a file, so I make no claim about thresholds.

What changed in 2.1.287?

The changelog entry says Claude was told to page large MCP results saved as JSON using Read's offset and limit, and that this was fixed. That is a client behaviour, so what you see is a Claude Code feature, not Sume's. What you can control is how large Sume's answers are and how many calls it takes to read a wave of jobs.

How does include_results shrink a wave?

Sume's docs say jobs_wait accepts job_ids, 1 to 20 of them, with wait_for set to all or any. With include_results: true, every id that completed comes back with its jobs_result answer in results[], so a wave needs no separate read. Results that do not fit in one answer are named in results_omitted.job_ids, and the docs say to read those with one batch jobs_result.

In the repo the combined results are bounded to 160 KiB, so the wait answer itself is never the casualty of a large result. That is a repo constant and could change, so rely on results_omitted rather than on the number.

{
  "job_ids": ["job_a", "job_b", "job_c"],
  "wait_for": "all",
  "include_results": true,
  "timeout_seconds": 50
}

What do I do with results_omitted?

Do not wait again on those ids; they completed. Call jobs_result once with job_ids set to the omitted list. The response is a job_result_batch with one entry per id in request order, each with ok plus either value or a typed error, and a failure on one id says nothing about the others. An id still running returns job_not_completed, and partial_failure.failed_job_ids names the ids worth re-reading.

Why not one jobs_result per id?

Each call is another model request that re-reads your whole context, and a big wave multiplies that cost. Sume's own notes show most jobs_result calls read a single id, which is why the batch read and include_results exist. The wait is also bounded: it returns within 55 seconds, default 50, and on wait_slice_expired you retry with the same ids and never resubmit the paid create.

What should I put in my prompt or CLAUDE.md?

Tell the agent the pattern once so it does not improvise. A short rule works: submit the whole wave with one idempotency_key per job, wait with one batch jobs_wait using include_results: true, read results_omitted with one batch jobs_result, and never resubmit a paid create because a wait timed out. If a wait ends in a 524, 522, 523 or 525, Sume's docs call that a transport failure, not a job outcome: re-issue the wait on the same ids or read jobs_status once.

Add max_spend_usd to the paid creates if the wave is large, and run a dry_run=true pass first. The jobs keep running and billing even if Claude Code's session ends, so a cancel needs jobs_cancel, which is a write tool and needs its own idempotency_key.

What does this not cover?

Claude Code decides how to store and show large tool output, and its own cap on MCP output is a separate setting. Sume does not control either. Sume's results carry URLs to media files, not the bytes, so a result is usually far smaller than the clip it points to.