Add Fireworks AI as an inference provider - #28983
alex-fireworks wants to merge 1 commit into
Conversation
New provider plugin: - plugins/model-providers/fireworks/ registers Fireworks AI via the standard ProviderProfile plugin system (auto-wired into auth, config, models, doctor, and transport layers). Supported models: - accounts/fireworks/routers/kimi-k2p6-turbo - accounts/fireworks/models/glm-5p1 - accounts/fireworks/models/minimax-m2p5 Also adds unit tests, a live smoke test, and env.example documentation.
teknium1
left a comment
There was a problem hiding this comment.
Thanks for adding the Fireworks provider plugin. I would keep this open for consolidation with the other Fireworks PRs, but this branch needs updates before it is a clean salvage onto current main.
Problems
tests/providers/test_plugin_discovery.py:56reintroduces a hardcoded provider count. Current main now asserts the invariant against plugin directories attests/providers/test_plugin_discovery.py:47-66, matching the AGENTS.md guidance against change-detector tests.plugins/model-providers/fireworks/__init__.py:12declaresfireworks-ai/fwaliases, but CLI/TUI provider normalization uses the separate static alias map inhermes_cli/providers.py:240-360; this PR only asserts the aliases exist on the profile, not thathermes_cli.providersresolves them.tests/run_agent/test_fireworks_live.py:27-30creates an OpenAI SDK client directly, so it does not verify Hermes auth/config/runtime/model-picker wiring despite the PR claiming those paths are auto-wired.
Suggested changes
- Port the discovery test to current main's invariant style and keep only a Fireworks spot-check.
- Add CLI/TUI-facing resolver coverage for
fireworks,fireworks-ai, andfw, or wire ProviderProfile aliases into that resolver. - Make the live smoke test exercise the Hermes runtime/provider path, not only the upstream OpenAI-compatible endpoint.
This is an automated hermes-sweeper review.
|
|
||
|
|
||
| fireworks = ProviderProfile( | ||
| name="fireworks", |
There was a problem hiding this comment.
These aliases are only asserted on the ProviderProfile. Current CLI/TUI provider normalization uses the separate static alias map in hermes_cli/providers.py, so please add resolver wiring or a regression test proving fireworks-ai and fw work through the user-facing provider path.
| profiles = list_providers() | ||
| names = sorted(p.name for p in profiles) | ||
| assert len(names) == 34, f"Expected 34 profiles, got {len(names)}: {names}" | ||
| assert len(names) == 35, f"Expected 35 profiles, got {len(names)}: {names}" |
There was a problem hiding this comment.
Please avoid bumping a hardcoded provider count. Current main changed this test to assert the invariant against the plugin directory count because provider totals are expected to change.
| from openai import OpenAI | ||
|
|
||
| return OpenAI(api_key=FIREWORKS_KEY, base_url=LIVE_BASE_URL) | ||
|
|
There was a problem hiding this comment.
This returns a raw OpenAI SDK client, so the live test bypasses Hermes credential resolution, runtime provider setup, and model inventory wiring. A Hermes-path smoke test would better cover the integration this PR is adding.
|
Fireworks AI support landed via PR #62593. This contribution was part of the Fireworks provider cluster credited in the salvage PR; thank you for the implementation and review work. |
Summary
ProviderProfileplugin systemaccounts/fireworks/routers/kimi-k2p6-turbo,accounts/fireworks/models/glm-5p1, andaccounts/fireworks/models/minimax-m2p5Files added
plugins/model-providers/fireworks/__init__.pyplugins/model-providers/fireworks/plugin.yamltests/plugins/model_providers/test_fireworks_profile.pytests/run_agent/test_fireworks_live.pyFiles modified
.env.example— documentsFIREWORKS_API_KEYandFIREWORKS_BASE_URLtests/providers/test_plugin_discovery.py— bumps provider count 34→35Test plan
pytest tests/plugins/model_providers/test_fireworks_profile.py)pytest tests/providers/test_plugin_discovery.py)FIREWORKS_API_KEYset (pytest tests/run_agent/test_fireworks_live.py)