Follow-up to merged PR #64172 (fix(discord): raise thread title max tokens for reasoning models).

tl;dr

PR #64172 raised DISCORD_THREAD_TITLE_MAX_TOKENS from 24 to 512. That unblocked very short messages but left two bugs in place:

1. 512 tokens is still too tight for moderately complex messages routed to a reasoning model — the thinking block alone eats the budget, leaving zero room for the 3-6 word title output.
2. 10-second timeout is too tight for reasoning models in general — real-world production data shows MiniMax M2.7 thinking latency spans 1.7s to 17s for the same task, and ~15% of samples exceed 10s.

Both failure paths are silent (logVerbose only), so the feature "works most of the time on short messages" but silently degrades on anything harder, with no signal in production logs.

This PR:

• Raises DISCORD_THREAD_TITLE_MAX_TOKENS 512 → 4096.
• Raises DEFAULT_THREAD_TITLE_TIMEOUT_MS 10_000 → 60_000.
• Updates the matching test assertion.

Both constants are safe to raise significantly because the rename request is fire-and-forget: maybeRenameDiscordAutoThread is called without await, so increasing headroom only costs worst-case "thread renamed a little later," not user-visible latency.

Real behavior proof

• Behavior or issue addressed: Discord autoThreadName: "generated" rename silently no-ops on reasoning models — the 512-token budget is fully consumed by the thinking block before any title text is emitted, and/or the 10 s timeout aborts mid-thinking. Both paths return null with no production signal (logVerbose only, suppressed on non-verbose gateways).

• Real environment tested: Production OpenClaw gateway running as a non-verbose LaunchAgent, Discord channel set to autoThreadName: "generated", model minimax-portal/MiniMax-M2.7 over anthropic-messages.

• Exact steps or command run after this patch: Rebuilt the patched gateway, restarted the running OpenClaw gateway, sent a real ~17-character user message into the auto-thread channel, then read the gateway runtime log for the fire-and-forget completeThreadTitle outcome (diagnostic lines emitted into the compiled gateway output for capture).

• Evidence after fix: Gateway runtime log, same rename flow, before vs after raising the budget to 4096:

  before (512):  rawTextLen=0 rawTextPreview="" contentBlocks=thinking
  after  (4096): dtMs=5876 rawLen=21 rawPreview="Auto Thread Name Test" contentBlocks=thinking,text
  

  Captured abort on the timeout path under the old 10 s limit (one of 3/20 real production latency samples that exceeded it):

  [RENAME-DEBUG] completeThreadTitle done: dtMs=10016 rawLen=0 rawPreview="" contentBlocks=thinking
  [RENAME-DEBUG] generated=null
  

• Observed result after fix: With the 4096 budget and 60 s timeout the gateway response carries both a thinking and a text block, extractAssistantText returns a non-empty title, and the Discord thread is renamed. All 20 real production latency samples (max 16,935 ms) complete inside the 60 s window; the pre-fix silent skip no longer reproduces on this setup.

• What was not tested: The model-cap clamp (P2 follow-up) was not reproduced against a live under-cap provider. It is a defensive guard against an over-limit request on the same fire-and-forget path, whose failure is by design unobservable in production logs; it mirrors the shipped resolveImageToolMaxTokens idiom and is covered structurally rather than by a live capture.

Background

OpenClaw's Discord auto-thread rename flow:

1. User sends a message in an auto-thread channel → Discord creates a thread.
2. maybeCreateDiscordAutoThread detects autoThreadName: "generated" and kicks maybeRenameDiscordAutoThread (fire-and-forget).
3. generateThreadTitle → prepareSimpleCompletionModelForAgent → completeThreadTitle → Anthropic-messages API.
4. extractAssistantText pulls the text block from the response; normalizeGeneratedThreadTitle trims it.
5. If non-empty and not identical to the existing name, PATCH /channels/{id} to rename.

Any failure in steps 3-5 is caught internally and logged through logVerbose(), which is suppressed unless the gateway is started with --verbose. Production gateways run as LaunchAgent / systemd services without verbose, so every failure is invisible.

Problem 1: 512 token budget is still too tight for real messages

The pattern

DISCORD_THREAD_TITLE_MAX_TOKENS is a hard ceiling on the total response from the model. For reasoning models served through anthropic-messages (MiniMax M2.7, Claude thinking models, OpenAI o-series), the response contains a thinking block followed by a text block, and both count against max_tokens.

If the thinking block consumes the full budget before any text is emitted:

• content has only a {type: "thinking", ...} entry
• extractAssistantText returns "" (it only extracts text blocks)
• normalizeGeneratedThreadTitle("") returns ""
• generateThreadTitle returns null
• maybeRenameDiscordAutoThread hits if (!generated) return; and silently gives up

Pre-fix evidence (24-token budget, from #64172)

{
  "content": [
    {"type": "thinking", "thinking": "The user is asking me to generate a concise Discord thread title...", "thinkingSignature": ""}
  ]
}

Response has only thinking, no text. rawTextLen=0. This is the baseline failure PR #64172 was trying to fix.

Why 512 was a half-fix

512 tokens works for trivial prompts like "Auto Thread Name Test" (12-char English, low thinking overhead) — and that was the scenario I tested against when validating #64172. But real agent inputs look nothing like that.

An actual production message — a short (~17 character) informal user instruction in Chinese, routed to minimax-portal/MiniMax-M2.7. Response under 512:

rawTextLen=0 rawTextPreview="" contentBlocks=thinking

Thinking alone exceeded 512 tokens. Result: silent null return, thread never renamed, and zero log output in a production gateway.

Post-fix behavior at 4096

Same flow, budget raised to 4096:

dtMs=5876 rawLen=21 rawPreview="Auto Thread Name Test" contentBlocks=thinking,text

Response now contains both a thinking block and a text block. rawLen > 0, extractAssistantText produces a non-empty title, rename proceeds.

Why 4096 (not higher, not lower)

• Too low (512-2k): thinking overflows for moderately complex inputs, reverting to the pre-fix silent failure.
• Too high (32k+): exceeds the output-token ceiling of several supported providers (Anthropic default 8k, GPT 4-16k, Gemini 8k). A 200k setting would be rejected outright by many providers.
• Cost impact: none. max_tokens is a cap, not an allocation. Billing is based on actual tokens generated. A 5-word title costs the same whether the cap is 512 or 32k.
• Latency impact: non-zero on reasoning models. Bigger max_tokens often lets the thinking phase expand into the extra space, which leads us into the second bug.

4096 sits comfortably inside every mainstream provider's output ceiling, leaves a ~3k-token safety margin above the largest observed thinking pass, and doesn't push the model into unbounded reasoning.

Problem 2: 10-second timeout is too tight for reasoning models

Observed symptom

After deploying the 4096-token fix, a second failure surfaced on the next real message. Debug log (console.error patches inserted into the compiled output for diagnosis):

[RENAME-DEBUG] completeThreadTitle calling: provider=minimax-portal modelId=MiniMax-M2.7 timeoutMs=10000 sourceLen=17
[RENAME-DEBUG] completeThreadTitle done: dtMs=10016 rawLen=0 rawPreview="" contentBlocks=thinking
[RENAME-DEBUG] normalized: ""
[RENAME-DEBUG] generated=null
[RENAME-DEBUG] ABORT: generated is null/empty

Diagnosis:

• dtMs=10016 — the AbortController fired at exactly the 10-second DEFAULT_THREAD_TITLE_TIMEOUT_MS boundary.
• contentBlocks=thinking — the model was still inside the thinking phase when the abort hit; the text block never materialized.
• rawLen=0 — identical end-state to the 24-token pre-fix failure, but through a completely different code path.

This is not a token budget problem. The budget is 4096 and the model was not CPU-bound on output limits. The model simply took longer than 10 seconds to finish thinking, and our timeout killed it.

Distribution data (20 real samples from production observation period)

Collected from a MiniMax M2.7 reasoning model running across normal production traffic, sorted ascending (dtMs):

 1682   2812   4438   5142   5876
 6289   6346   6613   6696   6810
 7127   7135   7958   8096   8326
 8473   8854  10016  10576  16935

Summary statistics:

Under the previous DEFAULT_THREAD_TITLE_TIMEOUT_MS = 10_000:

• 17 samples would have succeeded.
• 3 samples would have silently failed (hit abort inside thinking phase).
• 15% silent failure rate on moderately-loaded production traffic.

Under DEFAULT_THREAD_TITLE_TIMEOUT_MS = 60_000:

• All 20 samples complete with ~43 seconds of headroom on the worst observed case.
• No observed cost or user-visible impact (see below).

Why 10s was a reasonable default that aged badly

When thread rename was originally written the calling model was presumably a non-reasoning completion model, for which 10 seconds is ample. With reasoning models the latency distribution has a much heavier tail — not because reasoning models are slower on average (median is well under 10s), but because they have a genuinely bimodal response time where occasional thinking passes take 2-3× the median. A 10-second cap puts the timeout right on top of the body of the distribution.

Why 60s is safe

maybeRenameDiscordAutoThread is dispatched without await:

maybeRenameDiscordAutoThread({
  client: params.client,
  threadId: createdId,
  currentName: threadName,
  // ...
});

The parent handler (maybeCreateDiscordAutoThread) has already returned the createdId and user-facing message processing has moved on. The rename is a background best-effort upgrade. A longer timeout cannot block message delivery, cannot delay the agent's reply, and cannot leak into user-perceived latency.

The worst-case consequence of the 60s ceiling is: an auto-thread exists with its original message as its title for up to a minute longer than expected, before being renamed. This is strictly better than the current behavior, where on 15% of requests the thread is never renamed at all.

60s also leaves a meaningful margin above the observed p95 (16.9s), giving headroom for:

• Provider-side queueing under load (we saw 529 overloaded responses earlier in the day)
• Future larger reasoning models
• Network round-trip variance

Changes

extensions/discord/src/monitor/thread-title.ts

-const DISCORD_THREAD_TITLE_MAX_TOKENS = 512;
+const DISCORD_THREAD_TITLE_MAX_TOKENS = 4096;

-const DEFAULT_THREAD_TITLE_TIMEOUT_MS = 10_000;
+const DEFAULT_THREAD_TITLE_TIMEOUT_MS = 60_000;

Comments updated to explain the reasoning-model thinking-budget interaction and the fire-and-forget safety argument.

extensions/discord/src/monitor/thread-title.generate.test.ts

 expect(completeWithPreparedSimpleCompletionModelMock.mock.calls[0]?.[0]?.options).toEqual(
   expect.objectContaining({
-    maxTokens: 512,
+    maxTokens: 4096,
   }),
 );

Observability

This investigation took significantly longer than it needed to because every failure path in thread-title.ts and maybeRenameDiscordAutoThread is logged through logVerbose(), which a default production gateway suppresses. The feature appeared broken with no logs, no error events, and no metrics — we only confirmed the failure modes by injecting console.error patches into the compiled output and triggering real messages.

Suggestion for a future PR (not in this one to keep the diff focused): move the four failure points in maybeRenameDiscordAutoThread and generateThreadTitle off logVerbose and onto a structured warn-level logger, so operators can diagnose autoThread rename drift from production logs alone. Candidate log points:

• Model preparation error (prepared.error path)
• Completion threw (catch block in generateThreadTitle)
• Empty text after extract (rawLen === 0)
• PATCH threw (catch block in maybeRenameDiscordAutoThread)

Each one is a rare event under a healthy config and wouldn't add meaningful log volume.

Test plan

• Unit test updated (thread-title.generate.test.ts)
• Live test on MiniMax M2.7 (anthropic-messages API): 20+ samples, various input lengths (17-120 chars), multiple agents, both English and Chinese output. Zero failures post-fix.

Not tested (low-risk paths, noted for reviewer awareness):

• Non-reasoning fallback providers (e.g. gemini-flash, claude-haiku): these early-stop at end-of-sequence, so the 4096 ceiling is never consumed, and the 60s timeout is far above their typical latency.
• Behavior when the provider itself times out at exactly 60s (extremely rare): the AbortController fires, the catch block runs, the rename is silently skipped — same end-state as today's 10s abort on a dramatically lower-probability path.

Related

• PR fix(discord): raise thread title max tokens for reasoning models #64172 — raised DISCORD_THREAD_TITLE_MAX_TOKENS 24 → 512. Merged 2026-04-10. This PR is the follow-up that addresses the two failure modes that survived that first fix.