[BUG] Thinking block summaries truncated mid-sentence (showThinkingSummaries: true)

Confirming with independent measurements — different platform, different auth path, different CC versions, same bug. Our data may help narrow it down:

Setup: long-running headless -p session (--input-format/--output-format stream-json --include-partial-messages, resumed via --resume), subscription OAuth, claude-opus-4-6 (summarized thinking display), Linux VPS. So this reproduces on the subscription + stream-json path too, not just API + showThinkingSummaries.

Version independence — we measured truncation rate (thinking blocks ending without terminal punctuation, >50 chars, same session/machine) across three pinned CC versions over 3 days:

| CC version | thinking blocks | truncated | rate |
|---|---|---|---|
| 2.1.222 | 235 | 12 | ~5% |
| 2.1.223 | 208 | 14 | ~7% |
| 2.1.224 | 5 | 1 | (small sample) |

Combined with OP's 2.1.177, that's four client versions with identical behavior.

Billed but not delivered: in a sample incident (2026-08-07T12:19:50Z), usage.output_tokens: 469 while delivered content was 277 chars of thinking (cut mid-sentence on a dash) + 87 chars of complete text — far more tokens billed than delivered for CJK content. Across a larger sample, visibly-truncated messages bill ~2.57x tokens per visible character vs ~1.83x for normal ones. The thinking is generated (and billed) in full; a portion of the summary stream is silently dropped.

No error signal: stop_reason: end_turn, zero system/api_retry events anywhere near the incidents. The truncated summary is what gets persisted to the session .jsonl, so it's not a rendering issue.

Time-clustered, not version-clustered: several hours of heavy use on Aug 6 (CET evening) had zero incidents; midday Aug 7 produced repeated truncations within minutes, across two different pinned versions. Consistent with OP's "regression around Aug 5" — this looks server-side (summarizer stream termination), and should be confirmable fleet-wide by checking summarizer-stream terminations against billed thinking tokens, without any client logs.

The text blocks of the same messages arrive complete in every incident we recorded — only the summarized thinking stream is affected.

Follow-up with a stronger signal: truncation probability scales with input context size.

Same setup as my comment above. Bucketing every thinking block (>50 chars, 2 days, same session) by input_tokens + cache_read_input_tokens of its request:

| input context | thinking blocks | truncated | rate |
|---|---|---|---|
| < 40k tokens | 26 | 1 | ~4% |
| 40k–80k | 145 | 11 | ~8% |
| 80k–120k | 88 | 15 | ~17% |

In our most recent stretch at ~105–110k context, 4 of the last 6 thinking blocks were truncated — which is what escalated this from "annoying" to "constant" for the user. This also explains the burst pattern in my earlier comment: incidents cluster late in a context window and reset after compaction/new session.

So the summarizer stream seems to get cut with sharply increasing probability as the parent request's context grows. Hopefully that narrows the search (timeout or budget on the summarizer that's a function of parent context size?).

Confirming this, with follow-up evidence from Aug 10–11 that may help distinguish server-side behavior from client rendering.

I scanned local main-session JSONLs from 2026-08-01 through 2026-08-11T09:41Z, excluding subagents, decoding signed-block markers to exclude narration, and deduplicating by exact block signature. The abrupt non-terminal endings rose from 6/723 blocks on Aug 1–3 to 159/1,611 on Aug 4–9. I also have structurally unambiguous cases such as a summary announcing three numbered items and ending after item 1, with a normal stop_reason: tool_use and a complete text/tool path.

Starting 2026-08-10T19:20:16Z, the API began returning Unicode … endings. By the cutoff I had 102 unique signed thinking blocks ending in … (98 tool_use, 4 end_turn, none max_tokens).

Most importantly, I ran the retained Claude Code 2.1.198 binary today with no tools, --no-session-persistence, --output-format stream-json, and --include-partial-messages. The final thinking event was a distinct {"type":"thinking_delta","thinking":"…"} delta, followed by a correct final answer and a successful result. So the ellipsis is not being appended by the current 2.1.226 renderer or by session persistence; it is arriving from the summarized-thinking service path.

The new ellipsis also does not look purely context-threshold-driven: on Aug 11, all 67/67 Opus 5 summaries over 50 chars ended in …, across roughly 42k–252k input context. For the earlier naked-cut phase, using full input context (input_tokens + cache_read_input_tokens + cache_creation_input_tokens), I see only a modest within-session association (about OR 1.15 per additional 40k), not a monotonic 4% → 8% → 17% gradient. Context may amplify the bug, but the Aug 4 onset/rollout is the dominant change.

The text/tool output of the same messages remains complete. This looks like an API-side summarized-thinking generation/stream-termination issue, followed by a newer server-side ellipsis presentation behavior.

Confirming on macOS with additional data that narrows down where the truncation happens.

Environment

• Claude Code 2.1.223
• macOS 26.5, arm64, desktop app
• Model: Opus 5

Observation: 100% truncation rate, not intermittent

Every thinking block in a single session ends with U+2026 (…). Not most — all of them.

thinking blocks: 15
lengths: 545, 674, 1034, 1204, 679, 1618, 790, 446, 1218, 810, 141, 283, 411, 1276, 717
ending in U+2026: 15 / 15
set of final characters: {'…'}

Length is not the trigger. One block is 141 characters and still ends in …; another is 1618 and ends the same way. This is consistent with the original report's "not length-dependent" finding, but here there is no intact case at all.

Truncation happens before persistence, not at render time.

The session JSONL on disk already contains the ellipsis. This rules out the UI/display layer — the content is never written in full.

Repro (adjust the path to any recent session file):

import json, os

p = os.path.expanduser("~/.claude/projects/<project>/<session-id>.jsonl")
lens, ends = [], []
with open(p, encoding="utf-8") as f:
    for line in f:
        try:
            o = json.loads(line)
        except Exception:
            continue
        c = (o.get("message") or {}).get("content")
        if isinstance(c, list):
            for b in c:
                if isinstance(b, dict) and b.get("type") == "thinking":
                    t = b.get("thinking") or ""
                    lens.append(len(t))
                    ends.append(t[-1:])

print("blocks:", len(lens), lens)
print("ending in U+2026:", sum(1 for e in ends if e == "…"), "/", len(ends))
print("final chars:", set(ends))

Possibly more severe than originally described.

The original report notes that long blocks (1800+ tokens) sometimes pass through intact. On 2.1.223 I have not observed a single intact block across an entire session — the rate is 15/15.

A note on user-visible impact.

Because the trailing … is indistinguishable from the model deliberately trailing off, users reading the thinking panel cannot tell truncation from normal output. In my case this went unnoticed for several days and was initially attributed to a flaky network connection. A distinct marker (or a "truncated" indicator) would make this far easier to spot and report.

Confirming on another independent stack, with a clean onset baseline and
before/after data on the Aug 10 … switch.

Environment: claude-agent-sdk 0.2.129 (Python) spawning Claude Code CLI
2.1.221, subscription OAuth, claude-opus-4-6, --thinking-display
summarized, macOS arm64. The client stack has been unchanged since Aug 4,
so every number below comes from an identical client across the onset.

Onset baseline: Jul 28 – Aug 5, ~750 stored thinking blocks
(ThinkingBlock.thinking as delivered by the SDK), zero abrupt endings.
Aug 6 onward, 2.5–13% per day. Detection heuristic: stripped block text not
ending in sentence-final punctuation; measured baseline false-positive ~0.4%.

| Date (2026) | blocks | abrupt mid-word/mid-sentence end | ending in U+2026 … |
|---|---|---|---|
| Aug 1 – 9 | 511 | 9 (all on/after Aug 6) | 0 |
| Aug 10 | 81 | 4 | 9 |
| Aug 11 (partial day) | 83 | 0 | 53 |

This corroborates the Aug 10 switch reported above: zero …-endings across
nine days and 511 blocks, then 9 on Aug 10 and 53/83 (64%) on Aug 11 — while
the abrupt mid-word variant simultaneously dropped to zero. Same early
termination, now surfaced explicitly with … instead of a hard cut,
at a much higher rate.

Also ruled out client-side: --thinking-display offers no escape path
(summarized/omitted only; omitted is signature-only), and the onset
postdates our last client change, so no CLI rollback is relevant.

In the mid-word era (Aug 6–10) truncated lengths were scattered 136–1864
chars against an unaffected median of 576 (p90 1317) — not a length cap.

Happy to provide request IDs or per-day counts if useful.

Follow-up from my comment above, one structural finding on the … marker
that I don't think anyone has stated yet: most … truncations sit at a
sentence boundary, which means the marker is revealing truncation that was
previously invisible — every punctuation-based rate in this thread (including
mine) is an underestimate of the pre-Aug-10 reality.

Same stack as my previous comment. Of the 63 …-terminated thinking blocks
we have from Aug 10–11:

| text immediately before the … | blocks |
|---|---|
| complete sentence (ends in terminal punctuation) | 48 (76%) |
| mid-sentence | 15 (24%) |

Implications:

• A truncation that lands on a sentence boundary is undetectable by the

"doesn't end in terminal punctuation" heuristic. If ~3/4 of cuts are
boundary cuts, the Aug 6–9 rates measured by that heuristic (2.5–13%/day
here) capture only the mid-sentence minority — the true early-termination
rate was plausibly several times higher all along.

• So the Aug 10 change likely didn't raise the rate so much as label it:

the jump to ~64% of blocks ending in … is consistent with truncation that
was already happening quietly at sentence boundaries becoming visible.

• Mostly-clean sentence-boundary stops are also consistent with

@fishisfish0614's context-size correlation: this looks like a budgeted
early stop on the summarizer (tighter under larger contexts), with the
Aug 6–10 mid-word cases as its rough edge, rather than a stream failure.

Also seeing the same …-termination in Claude Code interactive sessions on
claude-fable-5 (subscription, same date window), consistent with the
cross-model reports above.

A follow-up to my earlier comment, with a longer baseline than I had then. Sharing in case the onset data helps narrow this down.

Dataset: 42 days of local session JSONLs (2026-07-01 → 08-12), ~2,000 files, 103,933 thinking blocks, subagents excluded via isSidechain. Blocks are classified on the stored thinking text: ends in … → ellipsis; ends in terminal punctuation → intact; neither → mid-sentence cut. Empty blocks are excluded from the denominator. Times are UTC+8.

1. Onset, against a ~40k-block clean baseline

| Date | non-empty blocks | … | intact | mid-cut | truncation |
|---|---|---|---|---|---|
| Jul 29 | 2,121 | 0 | 2,121 | 0 | 0.0% |
| Jul 30 | 9,857 | 0 | 9,857 | 0 | 0.0% |
| Jul 31 | 2,676 | 0 | 2,675 | 1 | 0.0% |
| Aug 02 | 3,530 | 0 | 3,529 | 1 | 0.0% |
| Aug 04 | 14,451 | 0 | 14,451 | 0 | 0.0% |
| Aug 05 | 4,796 | 0 | 4,794 | 2 | 0.0% |
| Aug 06 | 2,140 | 0 | 2,132 | 8 | 0.4% |
| Aug 07 | 1,052 | 0 | 879 | 173 | 16.4% |
| Aug 08 | 1,256 | 0 | 969 | 287 | 22.9% |
| Aug 09 | 3,190 | 0 | 2,501 | 689 | 21.6% |
| Aug 10 | 840 | 0 | 628 | 212 | 25.2% |
| Aug 11 | 1,061 | 1,046 | 13 | 2 | 98.8% |

Jul 29 – Aug 06 is ~40,000 blocks at essentially zero, so the Aug 7 onset is unambiguous. Note the … column: the marker did not exist at all in this dataset before Aug 11 — the Aug 7–10 period is entirely mid-sentence cuts.

2. The … switch is cross-model and simultaneous

Same data, split by model, Aug 7 onward:

| model | Aug 07 | Aug 08 | Aug 09 | Aug 10 | Aug 11 |
|---|---|---|---|---|---|
| opus-5 | n=717, …=0 | n=542, …=0 | n=3124, …=0 | n=840, …=0 | n=1041, …=1030 |
| fable-5 | n=335, …=0 | n=714, …=0 | n=60, …=0 | — | n=20, …=16 |

Zero … across ~6,400 blocks and four days on two different models, then both flip on the same day. The first ellipsis-terminated block here is 2026-08-11T03:41:19Z; the preceding block in the same session, ~1.5h earlier, ended intact.

Since this happens simultaneously on two different models with no client change on my side, it looks server-side rather than client- or model-specific. This is consistent with @C4ng's reading that the underlying early stop was already present and Aug 10–11 changed how it is surfaced.

(Caveat: my Aug 11 sessions were almost entirely high-effort, so this shows the switch is cross-model, not cross-effort.)

3. Ellipsis placement

Of 1,054 …-terminated blocks: 84.8% immediately follow terminal punctuation (sentence boundary), 15.2% mid-sentence.

This lines up with @C4ng's 76% on a larger sample, and it has an important consequence for every measurement in this thread, including my own table above: a truncation landing on a sentence boundary is invisible to punctuation-based detection. If ~85% of cuts are boundary cuts, then the Aug 7–10 rates above (16–25%) capture only the mid-sentence minority, and the true early-termination rate in that window was likely several times higher. The pre-Aug-7 "0.0%" days should be read as "no detectable truncation", not "no truncation".

4. The onset holds within a fixed effort level

My reasoning-effort setting changed during this window, so the raw daily table above could in principle be confounded. It isn't — holding effort fixed at low:

| Date | low-effort blocks | truncation |
|---|---|---|
| Aug 04 | 14,451 | 0.0% |
| Aug 05 | 4,765 | 0.0% |
| Aug 06 | 1,682 | 0.0% |
| Aug 07 | 396 | 17.2% |
| Aug 08 | 1,181 | 23.0% |
| Aug 09 | 180 | 50.0% |

~20,900 low-effort blocks at 0.0% on Aug 4–6, then 17–23% on Aug 7–8 within the same setting. High effort over the same days runs 23.4% / 20.0% — comparable, not higher. So the onset is not a function of effort, and effort does not appear to affect the truncation rate.

One limitation I can't resolve with my own data: by Aug 11 essentially all my sessions were high-effort (1,060 high vs 1 low block that day), so I cannot tell whether the … labelling is scoped to a particular effort path. Anyone running mixed effort levels on Aug 11+ could settle that quickly.

5. Reproduction

import json, glob, os
ELL, TERM = "…", set("。！？!?.」』”’）)；;：:")
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    for line in open(path, encoding="utf-8", errors="replace"):
        if '"thinking"' not in line: continue
        try: o = json.loads(line)
        except Exception: continue
        if o.get("isSidechain"): continue
        msg = o.get("message") or {}
        for b in (msg.get("content") or []):
            if isinstance(b, dict) and b.get("type") == "thinking":
                t = (b.get("thinking") or "").rstrip()
                if not t: continue
                kind = "ellipsis" if t[-1] == ELL else ("intact" if t[-1] in TERM else "midcut")
                print(o.get("timestamp"), o.get("effort"), msg.get("model"), len(t), kind)

On the earlier context-size correlation: I wasn't able to reproduce it once the date was held fixed, but my session mix varies a lot day to day and I don't think my data is clean enough to argue against it — noting it only so the negative result is on record.

Happy to provide per-day, per-model or per-effort raw counts if any of this is useful.