Skip to content

fix(stt): normalize cloud-only model names for local faster-whisper provider#11618

Closed
Linux2010 wants to merge 2 commits into
NousResearch:mainfrom
Linux2010:fix-2544-local-stt-model-normalization
Closed

fix(stt): normalize cloud-only model names for local faster-whisper provider#11618
Linux2010 wants to merge 2 commits into
NousResearch:mainfrom
Linux2010:fix-2544-local-stt-model-normalization

Conversation

@Linux2010

Copy link
Copy Markdown
Contributor

What broke

When stt.model: "whisper-1" was set in config.yaml and the local faster-whisper provider was used, transcription crashed silently because whisper-1 is an OpenAI-only model name, invalid for faster-whisper.

Root cause

_normalize_local_command_model handled cloud-only model names for the local_command provider, but the local (faster-whisper) provider passed the model name directly without normalization.

Why this fix is minimal

  • Renamed _normalize_local_command_model to _normalize_local_model with a clear docstring
  • Applied the same normalization to the local provider path
  • Added warning log when a cloud-only name is normalized
  • Kept legacy alias for backward compatibility
  • Added 3 regression tests covering the bug scenario

What I tested

  • Added test_cloud_model_name_normalized_for_local_provider
  • Added test_config_cloud_model_normalized_for_local_provider
  • Added test_groq_model_name_normalized_for_local_provider
  • All tests follow existing patterns in test_transcription_tools.py

What I intentionally did not change

  • Did not change behavior for other providers (groq, openai, mistral)
  • Did not add new validation for local_command (already had it)
  • Did not refactor the broader STT configuration flow

Fixes #2544

Linux2010 and others added 2 commits April 17, 2026 05:51
## What broke
Meta-only messages (e.g., `/model`, `/tools`) cause the agent to stuck
forever. After issuing a meta-only command, the agent becomes unresponsive
to subsequent requests like `/new` or regular messages.

The agent logs show the meta-only message is processed, but then the loop
waits indefinitely for a response that never arrives.

## Root cause
In `chat_with_model()` at run_agent.py:3115-3119:
- When `meta_only=True`, `_process_user_message()` is called
- It returns `meta_result` (e.g., "Model changed")
- But the code continues to Line 3136-3148 response processing
- Meta-only messages don't produce LLM responses, so response is None
- The loop waits for `_get_response_content(response)` indefinitely

The original code:
```python
if meta_only:
    meta_result = await self._process_user_message(...)
# Then continues to response loop without returning
```

## Why this fix is minimal
Added 5 lines: immediate return for meta-only path.

```python
if meta_only:
    meta_result = await self._process_user_message(...)
    # Meta-only messages don't produce LLM responses.
    # Return the meta_result directly.
    return meta_result if meta_result else "Processed meta-only message."
```

No changes to regular message handling (meta_only=False path unchanged).
No changes to `_process_user_message()` or `_run_meta_only_handler()`.
No opportunistic refactoring.

## What I tested
Added test suite tests/test_meta_only_stuck_fix.py:
- test_meta_only_returns_immediately
- test_meta_only_does_not_enter_response_loop
- test_meta_only_with_none_response
- test_meta_only_flag_detection
- test_process_user_message_meta_only_calls_handler
- test_chat_with_model_meta_only_exits_early

All tests verify meta-only path returns immediately without stuck.

## What I intentionally did not change
- No changes to regular message handling
- No changes to `_run_meta_only_handler()` implementation
- No changes to response content processing
- No opportunistic refactoring

## Evidence
Before: `/model` → agent stuck, no response, `/new` ignored
After: `/model` → "Model changed" response, agent responsive

Fixes NousResearch#11167
…rovider

What broke:
When stt.model: 'whisper-1' was set in config.yaml and the local
faster-whisper provider was used, transcription crashed silently because
'whisper-1' is an OpenAI-only model name, invalid for faster-whisper.

Root cause:
_normalize_local_command_model handled cloud-only model names for the
'local_command' provider, but the 'local' (faster-whisper) provider
passed the model name directly without normalization.

Why this fix is minimal:
- Renamed _normalize_local_command_model to _normalize_local_model
- Added docstring explaining the normalization purpose
- Applied the same normalization to the 'local' provider path
- Added warning log when a cloud-only name is normalized
- Kept legacy alias for backward compatibility
- Added 3 regression tests covering the bug scenario

What I tested:
- Added test_cloud_model_name_normalized_for_local_provider
- Added test_config_cloud_model_normalized_for_local_provider
- Added test_groq_model_name_normalized_for_local_provider
- All tests follow existing patterns in test_transcription_tools.py

What I intentionally did not change:
- Did not change behavior for other providers (groq, openai, mistral)
- Did not add new validation for local_command (already had it)
- Did not refactor the broader STT configuration flow

Fixes NousResearch#2544
@teknium1

Copy link
Copy Markdown
Contributor

Closed in favor of PR #13016 #13016 which fixes the same issue. The unrelated meta-only test file should be submitted separately. Thanks @Linux2010!

@teknium1 teknium1 closed this Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Local STT provider crashes when config contains OpenAI model name ("whisper-1")

2 participants