Add support for Azure Speech Service speech-to-text transcription for voice messages.
Features:
- Azure STT provider for audio transcription
- Support for 100+ languages and dialects
- High accuracy for Chinese, English, Japanese, etc.
- Automatic audio format detection
- Environment variable support: AZURE_SPEECH_API_KEY, AZURE_SPEECH_REGION
Implementation:
- Created Azure media understanding provider
- Audio transcription via Azure Speech REST API
- Endpoint: https://{region}.stt.speech.microsoft.com/speech/recognition/conversation/cognitiveservices/v1
- Headers: Ocp-Apim-Subscription-Key
- Request: Binary audio data (wav, mp3, ogg, etc.)
- Response: JSON with DisplayText transcription
Technical details:
- Uses Azure Speech conversation recognition endpoint
- Supports multiple audio formats (auto-detected from Content-Type)
- Returns DisplayText or NBest alternatives
- Integrated with Moltbot's media understanding pipeline
- Auto-discovery from environment variables
Benefits:
- No CLI dependencies (no whisper installation needed)
- High accuracy multilingual transcription
- Unified Azure billing with GPT and TTS
- Fast response times (~500-1000ms)
- Handles Telegram voice messages automatically
Co-Authored-By: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com>
Add support for Azure-hosted OpenAI-compatible models including OpenAI (GPT-4, GPT-5.2), DeepSeek, and other compatible models.
Implementation:
- Add Azure provider configuration with auto-discovery from environment
- Environment variables: AZURE_ENDPOINT, AZURE_API_KEY, AZURE_DEPLOYMENT, AZURE_API_VERSION
- URL fix middleware to handle Azure's specific URL format
- Tool call ID sanitization for Azure's 40-character limit
- Onboarding wizard support for interactive Azure setup
- Comprehensive tests for configuration and URL handling
- Documentation with setup guide and troubleshooting
Technical details:
- Azure uses different URL structure: {endpoint}/openai/deployments/{deployment}/chat/completions?api-version={version}
- OpenAI SDK constructs URLs incorrectly for Azure, placing query params before path
- URL fix middleware intercepts and corrects malformed URLs transparently
- Supports max_completion_tokens for newer models via compat config
- Tool call IDs automatically truncated to 40 characters for Azure compatibility
Onboard integration:
- Added Azure to auth choice groups (appears after OpenAI)
- Interactive prompts for endpoint, deployment name, API key, and API version
- Auto-discovery from environment variables if already configured
- Supports both manual configuration and environment variable detection
Co-Authored-By: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com>
MiniMax has updated their API. The previous configuration used an
incorrect endpoint (api.minimax.io/anthropic) with anthropic-messages
format, which no longer works.
Changes:
- Update MINIMAX_API_BASE_URL to https://api.minimax.chat/v1
- Change API format from anthropic-messages to openai-completions
- Remove minimax from isAnthropicApi check in transcript-policy
This fixes the issue where MiniMax API calls return no results.
Wraps plugin.actions.listActions() in a try/catch so a single
broken channel plugin cannot crash the entire agent boot sequence.
Errors are logged once per plugin+message (deduped) via
defaultRuntime.error() and the call gracefully returns an empty
array instead of propagating the exception.
Fixes: 'Cannot read properties of undefined (reading listActions)'
after the clawdbot→moltbot rename left some plugin state undefined.
- Change MAX_IMAGE_BYTES from 6MB to 5MB to match Anthropic API limit
- Add isImageSizeError() to detect image size errors from API
- Handle image size errors with user-friendly message instead of retry
- Prevent failover for image size errors (not retriable)
Fixes#2271
Add test cases to verify:
- baseUrl is inherited from provider when model does not specify it
- api is inherited from provider when model does not specify it
- model-level api takes precedence over provider-level api
- both baseUrl and api can be inherited together
Co-Authored-By: Claude (claude-opus-4.5) <noreply@anthropic.com>
When using custom providers with inline model definitions, the baseUrl
and api properties from the provider config were not being passed to
the individual models. This caused requests to be sent to the wrong
endpoint or with the wrong API format.
Changes:
- buildInlineProviderModels now copies baseUrl from provider to models
- buildInlineProviderModels now inherits api from provider if not set on model
- resolveModel fallback path now includes baseUrl from provider config
Co-Authored-By: Claude (claude-opus-4.5) <noreply@anthropic.com>
