fix(routing): use default api_base for firmware provider

[b3nw]

Summary

Tactical fix for users with FIRMWARE_API_KEY_* env vars but no FIRMWARE_API_BASE set.

Problem: LiteLLM doesn't recognize "firmware" as a native provider, so requests for firmware/* models were failing when FIRMWARE_API_BASE wasn't explicitly configured.

Solution: Add firmware-specific fallback in _load_api_bases() to use the default API base (https://app.firmware.ai/api/v1) when not explicitly configured.

Changes

• src/rotator_library/provider_config.py: +10 lines adding firmware default api_base detection

Testing

• ✅ Provider config correctly detects firmware as custom provider
• ✅ Routing converts firmware/* models to OpenAI-compatible with correct api_base
• ✅ End-to-end LiteLLM call to Firmware.ai succeeds

---

Important

Adds default API base for 'firmware' in provider_config.py to ensure requests succeed without explicit configuration.

• Behavior:
  • Adds default API base for 'firmware' in _load_api_bases() in provider_config.py.
  • Ensures requests to 'firmware/*' models succeed without explicit FIRMWARE_API_BASE.
• Logging:
  • Logs usage of default API base for 'firmware'.

^{This description was created by for d9148bb. You can customize this summary. It will automatically update as commits are pushed.}

[mirrobot-agent]

I'm starting my review of the tactical fix for the Firmware.ai provider. I'll verify the default API base detection and ensure it correctly routes through the OpenAI-compatible flow. 🛡️

[mirrobot-agent]

Overall Assessment

This PR provides a solid tactical fix for Firmware.ai users. By providing a default api_base and marking it as a custom provider, the rotator can correctly route requests for firmware/* models even when FIRMWARE_API_BASE is not explicitly set in the environment. This ensures a smoother out-of-the-box experience for users with Firmware API keys.

Architectural Feedback

None. The approach is consistent with how other custom providers are handled, and the implementation correctly leverages the existing convert_for_litellm routing logic.

Key Suggestions

None. The implementation is clean and follows existing project patterns.

Nitpicks and Minor Points

• The hardcoded URL https://app.firmware.ai/api/v1 is correct for Firmware.ai's current API.
• The use of KNOWN_PROVIDERS check ensures that if LiteLLM eventually adds native support, this fallback won't interfere with their implementation (provided they use the same name).

Questions for the Author

None.

This review was generated by an AI assistant.