Skip to content

Conversation

@Shiva4113
Copy link
Contributor

Related Issue

This Pull Request is related to the issue #111 .

Summary

Added support for using Fireworks as a provider with the Responses API.

Notes from Development

  • During the build process, there are issues with the latest version of fireworks-ai (v0.19.18).
  • When building with any-llm-sdk after running pip install fireworks-ai, a dependency issue arises:
    • reward-kit (v4.1) is incompatible with openai (v1.99.6).
  • As an alternative, attempting to build with pip install any-llm-sdk[fireworks] results in a version of fireworks-ai that is too old to support the new Responses API feature.

Additional Changes

  • Added a Response Wrapper utility to adapt the Fireworks response object to match the OpenAI Response object format.

@Shiva4113 Shiva4113 changed the title Responses APi for Fireworks AI feat(fireworks): Responses API for Fireworks AI Aug 11, 2025
Copy link
Contributor

@njbrake njbrake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the work on this! A few comments and changes needed.

@Shiva4113
Copy link
Contributor Author

Addressed the concerns previously raised, kindly let me know if any more changes are required.

Copy link
Contributor

@njbrake njbrake left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! A few more changes needed.

  1. You'll need to merge in the latest changes from main
  2. Run linting to surface the type errors. If you use uv: uv run pre-commit run --all-files --verbose this will run mypy and ruff on your code and surface a few of the missing typing issues
  3. You need to handle both streaming and non streaming in your return. Your code works fine now for non-streaming, but if it's streaming, you'll need to re-yield each chunk as the any-llm type. I know it seems like a silly thing to do right now, but the idea is to decouple the fireworks output from the any-llm typing to make it flexible if fireworks decides to change their output information. You may actually be able to directly return the response, it's possible that mypy will understand that the Any-LLM and OpenAI responses type are currently the same thing.

Comment on lines 96 to 98
response = Response.model_validate(response.model_dump())

return response
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since currently the Any LLM response type is an alias to the OpenAI type, you may actually be able to make mypy happy by removing the model_validate line.

Suggested change
response = Response.model_validate(response.model_dump())
return response
return response

@Shiva4113 Shiva4113 requested a review from njbrake August 11, 2025 20:33
@Shiva4113
Copy link
Contributor Author

Merged the latest commits from main and ran linting to surface all type errors.
Fixed the errors as well and also committed the requested change regarding model_validate().

Still working on the streaming responses.

Comment on lines 107 to 115
response = client.responses.create(
model=model,
input=input_data,
**kwargs,
)
if not isinstance(response, Response | Stream):
msg = f"Responses API returned an unexpected type: {type(response)}"
raise ValueError(msg)
return response
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'm not entirely sure if mypy would be happy with this or not, but I think technically it might be fine to directly return the output. Not sure if mypy will be ok with that 😅

Suggested change
response = client.responses.create(
model=model,
input=input_data,
**kwargs,
)
if not isinstance(response, Response | Stream):
msg = f"Responses API returned an unexpected type: {type(response)}"
raise ValueError(msg)
return response
return client.responses.create(
model=model,
input=input_data,
**kwargs,
)

Copy link
Contributor Author

@Shiva4113 Shiva4113 Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small issue, sorry for overlooking this earlier.
The returned here includes the part where the LLM thinks and we'll have to process this output in this way response.output[-1].content[0].text.split("</think>")[-1] to get only the relevant response.

Example response:
<think>
LLM thinking content here
</think>

Actual response

Just wanted to confirm with you once whether we can allow this kind of a response(that includes the thought and the actual reply) or return only the reply.

I will make the changes according to your reply

@codecov
Copy link

codecov bot commented Aug 12, 2025

Codecov Report

❌ Patch coverage is 40.00000% with 12 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/any_llm/providers/fireworks/fireworks.py 29.41% 12 Missing ⚠️
Files with missing lines Coverage Δ
src/any_llm/types/responses.py 100.00% <100.00%> (ø)
tests/conftest.py 80.95% <100.00%> (-19.05%) ⬇️
src/any_llm/providers/fireworks/fireworks.py 36.66% <29.41%> (-38.89%) ⬇️

... and 24 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@njbrake
Copy link
Contributor

njbrake commented Aug 12, 2025

@Shiva4113 Thanks for the work on this! I'll make a few pushes to get it over the finish line and then will merge it in 🙏

njbrake and others added 2 commits August 12, 2025 13:48
- Updated fireworks dependency version to >=0.17.16 in pyproject.toml.
- Refined response type checks in FireworksProvider to improve error handling.
- Adjusted reasoning assignment logic to ensure it handles None cases gracefully.
- Updated test configuration for Fireworks provider model mapping.
@njbrake njbrake merged commit f09ddc6 into mozilla-ai:main Aug 12, 2025
8 of 9 checks passed
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.

2 participants