$ pnpm openclaw infer model run --model anthropic/CLAUDE-OPUS-4-7 --prompt "Just say OK"
Error: No text output returned for provider "anthropic" model "CLAUDE-OPUS-4-7".
 ELIFECYCLE  Command failed with exit code 1.

$ pnpm openclaw infer model run --model anthropic/Claude-Opus-4-7 --prompt "Just say OK"
Error: No text output returned for provider "anthropic" model "Claude-Opus-4-7".
 ELIFECYCLE  Command failed with exit code 1.

$ pnpm openclaw infer model run --model anthropic/CLAUDE-OPUS-4-7 --prompt "Just say OK" --json
Error: No text output returned for provider "anthropic" model "CLAUDE-OPUS-4-7".
 ELIFECYCLE  Command failed with exit code 1.

- Default model: anthropic/claude-opus-4-7 (set via `pnpm openclaw models set anthropic/claude-opus-4-7`).
- Anthropic auth: Claude CLI OAuth (detected by `openclaw doctor`).
- No per-agent overrides; default agent `main`; gateway `mode=local`.
- The bug reproduces under both `--local` (default in this run) and `--gateway` transports — this is upstream of transport selection, in the model-id normalization path.

Affected users/systems/channels:
- Every operator who pastes a model id with mixed case (e.g. copy-paste from docs or chat where headers are title-cased) into `infer model run --model`. Linux directly observed (Ubuntu 24.04 / Node 22.22.2 / pnpm 10.33.0); platform-agnostic code path so macOS/Windows are expected to reproduce.
- New users who don't know the canonical lowercase form of model ids and try natural-feeling capitalizations (`Claude-Opus-4-7`, `CLAUDE-OPUS-4-7`).
- Users hitting this on Anthropic specifically; whether other providers exhibit the same asymmetry depends on each provider plugin's normalization (not directly verified for non-anthropic providers).

Severity:
- Annoying with confusing diagnostics. The "No text output returned" error misattributes a CLI input mistake to a provider/model fault, sending users down the wrong debugging path.
- For non-Claude providers that bill on partial requests: the case-mismatched call may incur tokens depending on whether the provider rejects pre-call or accepts and returns empty (not directly verified for non-anthropic providers).
- Inconsistent with the in-tree pattern. Provider name is case-insensitive; model name is not. Same input field, two case-sensitivity rules.
- Not a security/data-loss bug, no crash.

Frequency:
- Always, deterministic for case-mismatched anthropic model names. 100% reproduction across `Claude-Opus-4-7`, `CLAUDE-OPUS-4-7`, and `Anthropic/CLAUDE-OPUS-4-7`. Independent of model/transport.

Consequence:
- Operators waste time debugging "why doesn't claude work?" when the real issue is case mismatch in the model id.
- Inconsistency erodes operator trust in input parsing — the CLI accepts case-insensitive provider but rejects (downstream, with a misleading error) case-mismatched model.
- The "No text output returned" error string is now overloaded across at least three failure modes: empty prompt (#73185), case-mismatched model (this), and a configured provider returning empty body for valid input (closed #65394, #66506, #65076). Every overload makes the error less useful.
- No grounded evidence of missed messages, failed onboarding, or extra cost.

- Regression status: not classified as a Regression. Last-known-good not directly observed; no bisect performed.

- Likely fix locus: the model-id normalization/lookup path (search for "Unknown model:" in `src/cli/cli-infer/` or wherever the parser lives in this build, plus the model-catalog resolution helper). Two viable approaches:
  1. Match provider behavior — make model lookup case-insensitive, normalize the matched canonical id, and dispatch the canonical id to the provider. Most user-friendly.
  2. Make model lookup case-sensitive AND route case-mismatched ids through the existing "Unknown model" rejection path. Most consistent with literal id semantics. Optionally add a "did you mean: ...?" hint.

- Suggested regression test: a unit test on the model-id resolver that asserts each of `Anthropic/claude-opus-4-7`, `anthropic/CLAUDE-OPUS-4-7`, `anthropic/Claude-Opus-4-7`, `Anthropic/CLAUDE-OPUS-4-7` either (a) resolves to the canonical `anthropic/claude-opus-4-7` and dispatches accordingly, OR (b) is rejected with `Error: Unknown model: <input>`. Pair with an existing-behavior parity test that the canonical lowercase id still works.

- Related findings:
  - #73185 (filed): empty `--prompt` reaches the provider on `--local` transport. Same misleading downstream error string ("No text output returned"), different upstream cause (empty content vs case-mismatched model). Same root-cause class: the CLI doesn't validate/normalize input before dispatching.
  - Closed issues #65394, #66506, #65076: addressed "No text output returned" in valid-input scenarios. The same string remains overloaded across at least three failure modes; this issue makes that overload one mode larger.
  - Related parsing edge case: `--model anthropic/` (provider with trailing slash, no model) currently resolves to the provider's default model and succeeds — undocumented hidden behavior. Could be filed separately if maintainers consider it a UX gap.
  - Related parsing edge case: `--model anthropic` (provider only, no slash) currently fails with `Error: Unknown model: anthropic/anthropic` — implicit `<provider>/<provider>` auto-prefix exposes internal logic in the error message. Could be filed separately.

- Dedupe checked against the openclaw issue corpus on 2026-04-28: no existing open or closed issue matches the case-sensitivity asymmetry pattern specifically. Searched "case sensitive model id", "model id case mismatch", "case insensitive provider model", "uppercase model name infer" — zero direct matches.

- Not exercised in this repro: case-sensitivity behavior for non-anthropic providers (deepseek, openrouter, etc.); behavior under `--gateway` transport (the bug is in the model-id resolver upstream of transport, but not directly verified on gateway path); aliases with case mismatches (e.g. `Opus` vs `opus`).