fix(fireworks_ai): add kimi-k3 pricing so tool_choice is not rejected locally

[ayaangazali]

Relevant issues

Fixes #35382

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Screenshots / Proof of Fix

Kimi K3 on Fireworks had no entry in the model cost map, so supports_tool_choice() returned False and FireworksAIConfig.get_supported_openai_params left tool_choice out of the supported list. Callers got a local UnsupportedParamsError before the request ever left LiteLLM, even though Fireworks accepts the parameter and returns tool calls, which the reporter confirmed by forcing it through with allowed_openai_params.

Proxy config used for both runs, pointed at an unreachable base so the outgoing request body is what gets inspected rather than a completion:

model_list:
  - model_name: kimi-k3
    litellm_params:
      model: fireworks_ai/accounts/fireworks/models/kimi-k3
      api_key: dummy-fireworks-key
      api_base: http://127.0.0.1:9/inference/v1

Both runs use LITELLM_LOCAL_MODEL_COST_MAP=True so the proxy reads this repo's map rather than the published one.

curl -s -X POST http://127.0.0.1:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-proof-1234' -H 'Content-Type: application/json' \
  -d '{"model":"kimi-k3","messages":[{"role":"user","content":"weather in SF?"}],
       "tools":[{"type":"function","function":{"name":"get_weather","description":"Get weather",
         "parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],
       "tool_choice":"auto"}'

Before, on base 7c56317edf, the call is rejected locally and never reaches Fireworks:

litellm.UnsupportedParamsError: fireworks_ai does not support parameters: ['tool_choice'],
for model=accounts/fireworks/models/kimi-k3.

After, with this PR, validation passes and tool_choice is forwarded. The request now gets as far as the network, and the only error is the deliberately unreachable base:

POST Request Sent from LiteLLM:
-d '{'model': 'accounts/fireworks/models/kimi-k3', 'messages': [...],
     'tools': [{'type': 'function', 'function': {'name': 'get_weather', ...}}],
     'tool_choice': 'auto'}'

litellm.InternalServerError: Fireworks_aiException - Cannot connect to host 127.0.0.1:9

As a control, the same request without tool_choice already reached the network on the base commit, which places the failure squarely in the capability gate rather than anywhere downstream.

Type

🐛 Bug Fix

Changes

Adds fireworks_ai/accounts/fireworks/models/kimi-k3 and the short fireworks_ai/kimi-k3 alias to model_prices_and_context_window.json and its backup mirror, following the existing Kimi entries which carry both key forms. Pricing is $3.00 per million input, $0.30 per million cached input and $15.00 per million output, taken from the Fireworks serverless pricing page; the 1M context window, function calling and image input come from the model page. Those input and output figures also match Moonshot's own published K3 pricing. supports_tool_choice is set to true, which is what actually unblocks the reported error.

A parametrized regression test covers both key forms, asserting the pricing fields and that tool_choice appears in the supported params; it fails on the base commit for both.

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

---

Disclosure: I'm fairly new to this codebase and used Claude Code to trace the capability gate and run the before and after proxy captures. I checked the pricing against the Fireworks pages myself and confirmed the repro before and after; happy to correct anything that looks off.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

The PR registers both Fireworks Kimi K3 model-name forms in the canonical and bundled backup model-cost maps, enabling local tool_choice capability detection and adding pricing, context-window, and multimodal metadata.

• Adds matching full-path and short-alias Kimi K3 entries to both pricing maps.
• Adds a local-only parametrized regression test covering pricing lookup and the Fireworks tool_choice capability gate.

Confidence Score: 5/5

The PR appears safe to merge, with the canonical and backup metadata synchronized and both supported model-name forms covered by a focused regression test.

The added entries resolve through the existing Fireworks capability lookup, expose tool_choice for both aliases, and use the established local model-cost loading path without introducing a reachable regression.

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Adds consistent canonical pricing, context, and capability metadata for both Fireworks Kimi K3 identifiers.
litellm/model_prices_and_context_window_backup.json	Mirrors the canonical Kimi K3 entries in the package-local fallback map used by local model-cost loading.
tests/test_litellm/llms/fireworks_ai/chat/test_fireworks_ai_chat_transformation.py	Adds a network-free regression test that exercises both identifiers through the real supported-parameter capability gate.

_{Reviews (1): Last reviewed commit: "fix(fireworks_ai): add kimi-k3 pricing s..." | Re-trigger Greptile}

[ayaangazali]

Checked the osv-scan job log and this one is inherited from the base branch, not introduced here.

The job scans lockfiles only, invoked as osv-scanner -L uv.lock -L ui/litellm-dashboard/package-lock.json. This PR changes model_prices_and_context_window.json, its backup mirror, and one test file, so it touches neither lockfile and cannot add or remove a dependency finding.

The 30 findings are led by gitpython 3.1.50, which is pinned in the base branch's own uv.lock at line 2317 of litellm_oss_daily_2026_07_20, alongside pyasn1 0.6.3 and the package-lock.json entries. Bumping those is a dependency-maintenance change that belongs in its own PR rather than folded into a model-pricing fix.

I have not pushed anything for this check. The other jobs were still queued when the watcher fired; happy to revisit if any of those come back red.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ayaangazali]

Following up on my note that the queued jobs were still running. misc / Run tests has now finished and it is red, but for the same base-branch reason as osv-scan rather than anything in this diff.

It fails on exactly two tests in tests/test_litellm/interactions/test_openapi_compliance.py, test_status_enum_values and test_content_schema_uses_discriminator, with 3021 passing alongside them. Both were fixed upstream after litellm_oss_daily_2026_07_20 was cut, in fcd2360 (#34135) and ae74b06 (#35161), and both fail the same way on the sibling PRs that share this base. This PR only adds two model-map entries and a Fireworks test, so it does not touch the interactions spec.

That leaves osv-scan and those two compliance tests as the only reds, all three inherited from the base. Greptile came back 5/5 and I have ticked that checklist item.

[ayaangazali]

To settle the osv-scan red: it is pre-existing and not introduced here.

osv-scan fails on unmodified main as well. The most recent run on main, https://github.com/BerriAI/litellm/actions/runs/30286853243 from 2026-07-27, failed on gitpython 3.1.54 in uv.lock. The job only ever scans lockfiles, invoked as osv-scanner -L uv.lock -L ui/litellm-dashboard/package-lock.json, and this PR changes no uv.lock and no package-lock.json, so it cannot add or remove a dependency finding. The specific pins it flags here come from the base branch lockfile.

I am leaving it alone rather than bumping dependencies from an unrelated PR.

The misc / Run tests red is separate and also not from this diff: it fails on exactly two tests in tests/test_litellm/interactions/test_openapi_compliance.py, test_status_enum_values and test_content_schema_uses_discriminator, with 3021 others passing. Both were fixed upstream after this PR's base branch was cut, in fcd2360 (#34135) and ae74b06 (#35161).

[ayaangazali]

Rebased and retargeted onto litellm_internal_staging. This was previously based on a litellm_oss_daily_* branch, and I had missed that CLAUDE.md now names litellm_internal_staging as the base for external contributions too; no new daily branch has been cut since 2026_07_20, which explains the stale base.

That also clears both red checks, since staging already carries the compliance-test fixes and the lockfile bump that osv-scan was flagging. The failures were never from this diff.

For context, this adds Fireworks Kimi K3 to the model map so tool_choice is no longer rejected locally with UnsupportedParamsError. Tests pass on the new base and the scope is unchanged. Happy to adjust anything or split it differently if that helps.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing ayaangazali:litellm_fireworks_kimi_k3_pricing (f8290fb) with litellm_internal_staging (54fb717)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (0659738) during the generation of this report, so 54fb717 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩