Problem
Provider errors are normalized into a canonical single-line form (built by format_llm_error, machine-parseable via parse_llm_error in raven/providers/base.py:116 and :145), and the CLI one-shot path renders them as a friendly diagnosis plus a Fix hint with a nonzero exit. Other surfaces did not get the same treatment:
- Channels and the TUI deliver the raw canonical line, e.g.
Error calling LLM (auth@openrouter): AuthenticationError: ... User not found. This is better than the old raw exception dump, but has no category-appropriate hint and no Fix line.
- Missing-credential remedies travel to the TUI as a raw remedy string that tells the user to run terminal commands, which is awkward inside the TUI.
- Groq transcription with no API key only logs "Groq API key not configured for transcription" and silently returns an empty transcript, so the user just sees the agent ignore their voice message with no hint about where to configure the key.
Evidence
parse_llm_error is consumed only by raven/cli/agent_commands.py:76; no channel or TUI rendering path uses it.- raven/cli/tui_commands.py:528 and raven/tui_rpc/methods/config.py:345 forward the remedy text verbatim into RPC error data.
- raven/providers/transcription.py:31 warns and returns "" with no fix guidance.
- Auth error rendering deliberately avoids naming a specific HTTP status (401 vs 403 cannot be distinguished from the exception across providers), so the line currently says the provider rejected the credentials without a status.
Suggested direction
- Reuse
parse_llm_error in the channel outlet and TUI rendering so every surface gets the same category-based diagnosis plus a surface-appropriate hint (channels can point at gateway/provider config; the TUI can point at its own config screen instead of terminal commands).
- Give the transcription no-key warning the same one-line fix hint the chat path has.
- If showing the real HTTP status is ever wanted: a sketched design exists where
format_llm_error extracts the status from the live exception into the canonical header ((<category>[@<provider>][ <status>])), parse_llm_error returns it as an extra field, and the render layer chooses between the real value and a neutral word. That keeps the status truthful end to end instead of hardcoding one in the renderer.
Problem
Provider errors are normalized into a canonical single-line form (built by
format_llm_error, machine-parseable viaparse_llm_errorin raven/providers/base.py:116 and :145), and the CLI one-shot path renders them as a friendly diagnosis plus a Fix hint with a nonzero exit. Other surfaces did not get the same treatment:Error calling LLM (auth@openrouter): AuthenticationError: ... User not found.This is better than the old raw exception dump, but has no category-appropriate hint and no Fix line.Evidence
parse_llm_erroris consumed only by raven/cli/agent_commands.py:76; no channel or TUI rendering path uses it.Suggested direction
parse_llm_errorin the channel outlet and TUI rendering so every surface gets the same category-based diagnosis plus a surface-appropriate hint (channels can point at gateway/provider config; the TUI can point at its own config screen instead of terminal commands).format_llm_errorextracts the status from the live exception into the canonical header ((<category>[@<provider>][ <status>])),parse_llm_errorreturns it as an extra field, and the render layer chooses between the real value and a neutral word. That keeps the status truthful end to end instead of hardcoding one in the renderer.