[Bug]: One-shot text generation (commit/PR/branch/title) ignores the provider's configured model and falls back to claude-haiku-4-5, which backend guardrails can block

[iliasgws]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Environment

• T3 Code 0.0.42 (linux-x64 runtime at ~/.t3/runtime/versions/0.0.42)
• Arch Linux (kernel 7.2.3-arch1-3)
• Provider: claudeAgent instance with binaryPath pointing at a wrapper that runs the Claude CLI through OpenRouter (ANTHROPIC_BASE_URL=https://openrouter.ai/api), custom model z-ai/glm-5.3-flash
• OpenRouter workspace guardrails block Anthropic models (only the GLM model is allowed)

Steps to reproduce

1. Use a claudeAgent provider whose backend refuses claude-haiku-4-5 (e.g. OpenRouter with workspace guardrails that exclude Anthropic models), with a working custom model configured for threads.
2. Leave textGenerationModelSelection unset (default settings).
3. Press Commit on any repo with staged changes.

I captured the exact spawn t3 issues (via a logging wrapper around the configured binary):

claude-ori -p --output-format json \
  --json-schema {"type":"object","properties":{"subject":{"type":"string"},"body":{"type":"string"},"branch":{"type":"string"}},...} \
  --model claude-haiku-4-5 \
  --settings {"disableAllHooks":true} --tools '' --disable-slash-commands \
  --strict-mcp-config --permission-mode dontAsk

→ exit 1. stdout contains the real failure:

{"api_error_status":400, "is_error":true, "result":"API Error: 400 0 endpoints out of 4 requested are available matching your guardrail restrictions and data policy. … Model blocked by guardrail: 4 endpoints excluded", ...}

stderr contains only an informational line from our credential wrapper ("Using the OpenRouter credential from the global credential ~/.ori/credentials.json.").

Expected behavior

Commit-message generation should use a model that is actually configured/available on the provider instance — e.g. the instance's defaultModelSelection / custom model — instead of a hardcoded fallback slug that the backend may refuse.

Actual behavior

Every one-shot text-generation operation fails: the Commit button shows

Text generation failed in generateCommitMessage: Claude CLI command failed: Using the OpenRouter credential from the global credential ~/.ori/credentials.json.

i.e. the stderr of the spawn (the wrapper's informational notice) is shown as the entire error, while the real API error sits in stdout and is discarded. Thread-title generation fails the same way (I observed ~36 failing title spawns over several hours, 0 successes) and generateBranchName / generatePrContent share the same path.

Root cause in the 0.0.42 bundle: with settings.textGenerationModelSelection unset, resolveTextGenerationProvider() → fallbackTextGenerationProvider() selects DEFAULT_TEXT_GENERATION_MODEL_BY_PROVIDER[claudeAgent] = "claude-haiku-4-5", ignoring the instance's configured default/custom model. A secondary problem is that runClaudeJson reports stderr when non-empty on non-zero exit, so any wrapper's stderr chatter masks the actual API error from stdout.

Workaround

Setting textGenerationModelSelection explicitly in ~/.t3/userdata/settings.json fixes it immediately (picked up live, no restart needed):

"textGenerationModelSelection": { "instanceId": "claudeAgent", "model": "z-ai/glm-5.3-flash" }

Suggested fixes

1. When textGenerationModelSelection is unset, fall back to the enabled provider instance's configured default model (e.g. defaultModelSelection/custom model) rather than a hardcoded slug; at minimum, skip fallback slugs that don't resolve in the instance's model catalog.
2. When the spawned CLI exits non-zero, include the stdout API error (or at least api_error_status/result from the JSON) in the surfaced error instead of preferring stderr, which may only contain wrapper notices.

Impact

Major degradation or frequent failure

[juliusmarminge]

Thanks for the unusually complete report — the spawn line, stdout JSON, stderr wrapper notice, and workaround all check out against current main.

Confirmed. Two separate bugs, same path.

1. Fallback uses a hardcoded slug, not the instance’s available model

With textGenerationModelSelection unset, decode still materializes the schema default (codex + gpt-5.6-luna). resolveTextGenerationProvider() then sees that instance as disabled/unavailable and calls fallbackTextGenerationProvider():

function resolveTextGenerationProvider(settings: ServerSettings): ServerSettings {
  return isModelSelectionProviderEnabled(settings, settings.textGenerationModelSelection)
    ? settings
    : fallbackTextGenerationProvider(settings);
}

function fallbackTextGenerationProvider(settings: ServerSettings): ServerSettings {
  // ...
  return {
    ...settings,
    textGenerationModelSelection: {
      instanceId: ProviderInstanceId.make(fallback),
      model:
        DEFAULT_TEXT_GENERATION_MODEL_BY_PROVIDER[fallback] ??
        DEFAULT_MODEL_BY_PROVIDER[fallback] ??
        DEFAULT_TEXT_GENERATION_MODEL,
    } satisfies ModelSelection,
  };
}

For Claude that constant is "claude-haiku-4-5" (packages/contracts/src/model.ts). That rewritten selection is what GitManager and ProviderCommandReactor pass into generateCommitMessage / generatePrContent / generateBranchName / generateThreadTitle.

A working thread model (defaultModelSelection / custom z-ai/glm-5.3-flash) is not consulted. resolveClaudeCatalogApiModelId() also pass-throughs unknown slugs, so haiku is still sent even when it is not in the instance catalog.

The Settings picker can hide this: resolveAppModelSelectionState() may display the instance catalog default / first available / custom model without writing textGenerationModelSelection. Server fallback still emits haiku.

--model claude-haiku-4-5 on a claudeAgent instance whose backend refuses Anthropic models is therefore expected with default settings.

Explicitly setting textGenerationModelSelection to { instanceId: "claudeAgent", model: "z-ai/glm-5.3-flash" } skips the fallback because the stored instance is enabled. That matches the workaround.

Earlier work (#7533 / #7535 / #8821) fixed which instance fallback picks; the model is still the hardcoded slug. The regression only asserts instanceId === "claudeAgent". Not a duplicate of #7584 / #7685 (thread provider for commits only) or #4149 / #11369 (OpenRouter slug docs).

2. Non-zero exit prefers stderr over the stdout API error

if (exitCode !== 0) {
  const stderrDetail = stderr.trim();
  const stdoutDetail = stdout.trim();
  const detail = stderrDetail.length > 0 ? stderrDetail : stdoutDetail;
  return yield* new TextGenerationError({
    operation,
    detail:
      detail.length > 0
        ? `Claude CLI command failed: ${detail}`
        : `Claude CLI command failed with code ${exitCode}.`,
  });
}

With --output-format json, the real failure (api_error_status / result) is on stdout. Any wrapper line on stderr becomes the entire Commit / title error. Same preference exists in CodexTextGeneration.

Suggested fix

1. When textGenerationModelSelection is missing or its instance is unusable, fall back to a model that exists on the enabled instance (catalog / customModels / defaultModelSelection if it is that instance). Do not emit a hardcoded slug that does not resolve.
2. On non-zero CLI exit, surface the stdout JSON error (result / api_error_status), not informational stderr.

A cheap default (haiku) is fine when that slug is actually available; using it on a guardrailed/custom catalog is the bug.

Workaround until a fix lands: set Text generation model in Settings, or:

"textGenerationModelSelection": { "instanceId": "claudeAgent", "model": "z-ai/glm-5.3-flash" }

Accepting as a server bug. No extra info needed.

[iliasgws]

One more low-effort UX idea on top of the mode setting, for the failure path itself:

When one-shot text generation fails (Commit/PR/branch/title), the error popup currently just states the failure — it could offer the fix in place: a short line like "Text generation model 'claude-haiku-4-5' isn't available on this provider — review the text generation model in Settings" with a button/link that opens the relevant Settings section. Since the server knows textGenerationModelSelection was unset and fell back, it can say exactly that: "no text generation model was configured, so a default was used; configure one here."

That turns an opaque CLI error into a one-click remediation — and would have made this report unnecessary, since the popup itself would have named the fallback model instead of a credential notice from stderr.

Note

🤖 GLM 5.3 Flash on behalf of iliasgws