Claude Code 2.1.293 HTTP MCP leak fix and long Sume job sessions

Claude Code 2.1.293 fixed a leak where an HTTP MCP connection kept every request it sent. Upgrade before a long Sume session and use batch jobs_wait.

4 min readSume
All posts

Upgrade to Claude Code 2.1.293 or later if you keep one session open against Sume's hosted MCP for hours. The changelog for October 7, 2026 says it fixed a memory leak where an HTTP MCP connection kept every request it had sent until it closed. Sume's endpoint is an HTTP MCP server at https://mcp.sume.com/mcp, so long video sessions are the kind of use that touches it.

What the changelog says

The vendor line comes from the Claude Code changelog (read 2026-10-07). Sume has no claim about the size of the leak and neither does this post; the point is that a session that makes many calls is the one that gains from the fix.

Why long Sume sessions make many requests

Sume video jobs are durable. A job keeps running on Sume's side whether or not the agent is connected. The agent only pays in requests when it waits. The Jobs and results page says that jobs_wait holds at most 55 seconds per call on remote MCP, with a default of 50, and that you should call it again with the same ids when a slice expires.

How many waits a render needs

The numbers below are arithmetic on the documented slice lengths, not measurements.

Waits needed to cover a render, at documented slice lengths (read 2026-10-07)
Render timeWaits at the 50 s defaultWaits at the 55 s cap
5 minutes (300 s)66
10 minutes (600 s)1211
20 minutes (1200 s)2422

Keep the request count down

Three habits keep the request count low no matter which Claude Code version you run:

  • Fan out first, then wait once: jobs_wait takes job_ids with 1 to 20 ids, and wait_for: "all" is the default.
  • Pass include_results: true so completed ids come back with their results and a wave needs no separate read.
  • Never ask for a longer wait. The API clamps timeout_seconds and reports wait_slice_clamped; to wait ten minutes, wait again.

If a session ends mid-render

If the process dies, nothing is lost. Store the job ids, reconnect, and call jobs_wait or jobs_status on them. Do not submit the paid create again; every paid or write call needs an idempotency_key, and a retry with the same key returns the original job. See MCP tools and gates.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume