Simplify thinking: remove server-side complexity and transport type

[cpsievert]

Summary

Two-stage simplification of how thinking content flows through the transport protocol, enabled by chatlas/ellmer now emitting well-formed <thinking> tag boundaries during streaming (posit-dev/chatlas#294, tidyverse/ellmer#975).

If the second commit feels too aggressive, the first commit stands alone as a clean improvement.

Commit 1: Replace content_type: "thinking" with block_type field

Separates format (content_type: markdown/html/text) from semantic role (block_type: thinking/content). This is a straightforward improvement — "thinking" was never a content format, it was a semantic signal that happened to be shoehorned into the format field.

• Removes the Python server-side thinking accumulator (_current_stream_thinking) and end-of-stream tag reconstruction
• Server now does a simple isinstance check per chunk and sends block_type: "thinking" — no state, no accumulation
• Client fast path unchanged in behavior, just keyed off block_type instead of content_type

Commit 2: Remove block_type from transport entirely

Makes the server pure pass-through. The client's existing tag parser (processThinkingTags) becomes the single code path for all providers — structured (Claude, OpenAI reasoning) and raw-tag (DeepSeek, QwQ) alike.

• Python: removes _is_content_thinking, BlockType, and the thinking branch in _append_message_stream
• R: contents_shinychat for ContentThinking returns plain text; removes shinychat_thinking class
• JS: removes BlockType and the block_type fast path in the chunk handler

This second commit is potentially more controversial. It trades a guaranteed-correct fast path (type dispatch) for a single unified code path (tag parsing). The tag parser is already battle-tested (it handles DeepSeek/QwQ today and has comprehensive tests), and having one path eliminates "works with provider X but not Y" bugs. But there are tradeoffs:

• Performance: the tag parser runs on every chunk, doing string scans for < even when thinking isn't involved. In practice this is cheap (single indexOf check short-circuits), but it's not zero-cost like a type dispatch.
• Correctness: we now depend on chatlas/ellmer emitting well-formed tags. If a bug upstream produces malformed tags, the client will misparse. With the fast path, the server's type dispatch was immune to tag formatting issues.

Test plan

• All 283 JS tests pass (vitest)
• All 63 Python tests pass (pytest + playwright)
• All 126 R tests pass (testthat)
• TypeScript compiles clean (tsc --noEmit)
• Pyright passes with 0 errors
• Manual test with a thinking-capable model (Claude extended thinking or DeepSeek) to verify thinking UI still renders correctly

[gadenbuie]

The block_type change is a solid improvement.

I'm pretty strongly opposed to any kind of optimization that reduces data fidelity through string parsing. I included client side parsing of <thinking> tags because I've seen it from now years-old models, but at this point even local model services return reasoning as a differentiated data type.

For me "prefer objects over strings" is the new "prefer enums over booleans". I don't mind supporting strings as a fallback, but I'm not comfortable with it being the primary modality.

[gadenbuie]

Thanks for this, Carson. The two-commit separation makes it easy to evaluate each idea separately.

On Commit 1 (block_type field)

My initial reaction was positive — separating "format" from "semantic role" sounds right. But I can't find a case where the two fields vary independently. There's no scenario for block_type: "thinking" + content_type: "html", so my sense is that we can keep this as one field and expand its usage.

I tested this against a change I've been considering: sending tool requests/results as structured data rather than pre-rendered HTML. In that design, the natural endpoint is to use content_type: "tool_result", with any rendering variant (data card vs. custom HTML) as an internal field in the payload. The transport routes on content_type alone. So block_type doesn't add information that content_type doesn't already carry.

My take is that content_type: "thinking" isn't overloading — it's content_type doing what it's always done: telling the client which component handles this block.

On Commit 2 (pure pass-through server)

This one I feel more strongly about declining.

1. Coupling direction. Today shinychat owns the contract: "give me a ContentThinking and I route it." With a pass-through server, correctness depends on how chatlas/ellmer format their text. That this commit requires specific upstream PRs is a symptom — we'd be coupling to an implementation detail rather than a typed interface.

2. Framework independence. On the Python side especially, we want shinychat to work with libraries beyond chatlas. content_type: "thinking" is an explicit protocol any backend can implement. Requiring every library to emit well-formed <thinking> tags asks them to conform to a string convention that only shinychat cares about.

3. The two paths aren't redundant. Type dispatch handles structured providers (Claude, OpenAI reasoning). The tag parser handles raw-tag models (DeepSeek, QwQ). They serve different input classes, and a bug in one doesn't affect users of the other.

What I do like

The motivation behind both commits, reducing server-side state and plumbing, is sound. The Python _current_stream_thinking accumulator and finally-block tag reconstruction is clunky. I'm very open to suggestions about how to simplify that area. I do think it points at us thinking about reasoning tokens differently — I'm personally seeing them as separate content from the assistant message, i.e. something closer to tool calls.

I appreciate the thorough writeup and test coverage. Let me know if you see it differently.

[cpsievert]

Superseded by #211