Inline reasoning-tag extraction only ever matches `<think>`, so other reasoning tags leak into the visible answer

[M3gA-Mind]

Summary

Inline reasoning-tag extraction ships its built-in default and is never configured, so it strips <think>…</think> and nothing else. A model that emits <thinking>, <reasoning> or any other tag name has its chain-of-thought pass through as visible answer text.

Found while tracing how reasoning reaches the chat UI (context: #5934).

Verified

No production caller. with_reasoning_tag_extraction is invoked exactly twice in the whole tree, both in the vendored crate's own tests:

vendor/tinyagents/vendor/tinyinference/crates/tinyinference/src/providers/openai/test.rs:589
vendor/tinyagents/vendor/tinyinference/crates/tinyinference/src/providers/openai/test.rs:595

Zero hits under src/. So reasoning_tags_overridden is always false in a real run and the default governs.

What the default does — transport.rs:504-509:

pub(super) fn effective_reasoning_tags(&self) -> Option<&ReasoningTagExtraction> {
    if !self.reasoning_tags_overridden && self.base_url == DEFAULT_BASE_URL {
        return None;
    }
    self.reasoning_tags.as_ref()
}

• base_url == api.openai.com → extraction off.
• every other base URL → extraction on.

And it matches one tag name — reasoning_tags.rs:53:

tag_name: "think".to_string(),

So the effective behaviour everywhere except OpenAI is: extract <think>, pass every other reasoning convention through untouched into content.

Why this matters

Reasoning is separated from the answer by exactly one bit — MessageDelta.reasoning vs MessageDelta.text — decided in the provider adapter. There is no heuristic anywhere downstream: not in the core, not in the renderer. Nothing inspects text to decide whether it is thinking.

That is the right design, and it means this is the only place the distinction can be made for a model that inlines its reasoning. If the tag name does not match here, the chain-of-thought becomes answer text and no UI change can recover it — including #6169, which moved reasoning off the main transcript but only acts on content already marked as reasoning.

What I have NOT established

Whether any model we actually route to emits a non-think tag. I did not run a live capture. The affected population is "OpenAI-compatible endpoints that inline reasoning under a different tag name" — plausibly some Ollama / LM Studio / llama.cpp models and some hosted OpenAI-compatible providers, but I am not claiming a specific one is broken today.

So this is filed as a latent defect with a verified mechanism, not an observed incident. One live capture per configured provider would settle it; that is the natural first step.

Why it is worth attention now

The single-tag default is fine while managed inference goes to a small, known set of upstreams. It becomes less safe as that set widens — a managed route that resolves through an aggregator can reach many more model families than the default was written against, and each one brings its own convention. A leak here is not cosmetic: internal reasoning appearing as the assistant's answer is a content-correctness and potentially a disclosure problem, not a rendering nit.

Fix shapes (in increasing cost)

1. Widen the default tag set — accept think, thinking, reasoning rather than one name. Smallest change, covers the common conventions, no per-provider configuration. Needs care that the streaming-safe partial-tag buffering (potential_start_index) still holds with multiple candidate tags.
2. Configure it per provider where we know the convention, using the seam that already exists and is currently unused.
3. Leave the default and document it — acceptable only if a capture shows nothing we route to inlines anything but <think>.

I would do (1) after doing the capture, and not before — widening a matcher against a hazard nobody has observed is how a stripping bug gets introduced in the other direction.

Related

• Context: Bug: Internal agent thinking/reasoning content leaks into visible chat response #5934 (how this surfaced), feat(chat): show the answer on /chat, move the explanation to the rail #6169 (moved reasoning off the main transcript; does not affect content never marked as reasoning)

[M3gA-Mind]

Capture done — it leaks, and the proposed tag set would have missed it

The issue asked for one live capture per reachable provider before deciding anything. Done, and it changes the fix.

The mechanism is confirmed as filed

with_reasoning_tag_extraction has no production caller (crate_openai.rs:98 and openhuman_backend_model.rs both build the model without it), so effective_reasoning_tags() returns the default for every base URL except api.openai.com, with tag_name: "think". No correction needed there.

What the capture found

exaone-deep:2.4b through Ollama's OpenAI-compatible /v1/chat/completions (2026-09-10, local, OLLAMA_KV_CACHE_TYPE=f16):

• It wraps its entire chain of thought in <thought>…</thought>.
• It sends no side channel at all — non-streaming message keys are ['role','content']; across 2991 streamed deltas the only keys seen are content and role. There is no reasoning / reasoning_content to fall back to.
• One captured response: 5011 bytes of content — 4979 of chain of thought and a 9-byte answer (\boxed{4}). All 5011 are shown to the user today.
• Streamed, the opening tag arrives split across three deltas: <, thought, >.

So this is no longer latent. It is a live leak on a model any user can select through the Ollama provider, and the user sees the model's private deliberation instead of 4.

The correction

Fix shape (1) in the issue proposed think, thinking, reasoning. That set would not have fixed the one real case found — the offender is thought, which is not in it. Worth flagging because the widening looked safe to specify from convention alone, and specifying it from convention alone would have produced a change that passed review and fixed nothing.

The tag set needs thought in it. Merged into the fix: think, thinking, thought, reasoning.

What I could not reach

Only local runtimes were reachable. LM Studio (:1234) and llama.cpp (:8080) were not running; minimax-m3:cloud returned requires a subscription or usage credits. No hosted OpenAI-compatible provider was tested, so the population there is still unmeasured — the issue's concern about aggregator-routed managed models stands and is not settled by this capture.

Checked while there: qwen3 and deepseek-r1 use <think> (already covered). Granite 3.2 is a separate shape — it marks reasoning with plain prose (Here is my thought process:), no tags at all, so no tag matcher of any width will catch it. Not in scope here; say the word if it should be its own issue.

Fix

tinyhumansai/tinyinference#9 — CI green. Widens the default and pins the closing tag to the name that opened the section, so a wider set cannot let one convention terminate another (<thinking>a</think>b stays open until </thinking>). Near-miss prose (<thin , <thought unclosed, a bare <) is released verbatim, tested in both directions.

This issue does not close on that merge

openhuman vendors this crate at vendor/tinyagents/vendor/tinyinference (exactly one copy compiles — Cargo.lock has a single tinyinference entry; the vendor/tinymemory/vendor/tinyinference copy never builds here). Delivery needs two gitlink bumps after the merge:

1. tinyagents bumps vendor/tinyinference
2. openhuman bumps vendor/tinyagents

Leaving this open until the fix actually reaches openhuman.

🤖 Generated with Claude Code

https://claude.ai/code/session_016ipSkHi47nsBmnxX5dC4dA