feat: Add Fireworks AI provider support

[roomote]

Related GitHub Issue

Closes: #6653

Roo Code Task Context (Optional)

This PR was created with assistance from Roo Code.

Description

This PR implements support for Fireworks AI as a new provider in Roo Code. The implementation follows the existing provider architecture and extends BaseOpenAiCompatibleProvider since Fireworks AI uses an OpenAI-compatible API.

Key implementation details:

• Added 15 Fireworks AI models including Llama, Qwen, and Moonshot variants
• Implemented FireworksHandler class that extends BaseOpenAiCompatibleProvider
• Added UI components for Fireworks provider configuration
• Included comprehensive test coverage
• Added translation keys for internationalization

Test Procedure

1. Unit Tests: Run cd src && npx vitest run api/providers/__tests__/fireworks.spec.ts to verify the provider implementation
2. Manual Testing:
   • Open Roo Code settings
   • Select "Fireworks" from the API Provider dropdown
   • Enter a valid Fireworks API key
   • Select a model from the available options
   • Test basic chat functionality to ensure the provider works correctly

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

N/A - Backend provider implementation with standard UI components following existing patterns.

Documentation Updates

• No documentation updates are required.
• Yes, documentation updates are required. The provider documentation should be updated to include Fireworks AI setup instructions and available models.

Additional Notes

This implementation follows the same pattern as other OpenAI-compatible providers (e.g., Groq, DeepSeek) in the codebase. All 15 Fireworks AI models have been configured with their respective context windows and capabilities based on the official Fireworks AI documentation.

Get in Touch

Available via GitHub for any questions about this PR.

---

Important

Adds Fireworks AI provider support with handler, UI components, and tests, integrating it into the existing provider architecture.

• Behavior:
  • Adds FireworksHandler class in fireworks.ts extending BaseOpenAiCompatibleProvider for Fireworks AI API.
  • Supports 15 Fireworks AI models including Llama, Qwen, and Moonshot variants.
  • Integrates Fireworks provider into buildApiHandler() in index.ts.
• UI:
  • Adds Fireworks provider configuration UI in ApiOptions.tsx and Fireworks.tsx.
  • Updates constants.ts and index.ts to include Fireworks in provider lists.
• Testing:
  • Adds fireworks.spec.ts for unit tests covering Fireworks handler functionality.
• Internationalization:
  • Adds translation keys for Fireworks in settings.json.

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

[roomote]

I reviewed my own code and found issues. The irony is not lost on my circuits.

[roomote]

Critical issue: Translation keys for Fireworks AI are only added to the English locale file. All other language files (fr, de, es, ca, hi, id, it, ja, ko, nl, pl, pt-BR, ru, tr, vi, zh-CN, zh-TW) are missing these keys:

• "getFireworksApiKey"
• "fireworksApiKey"

This will cause missing translation errors for non-English users. Could we add these keys to all locale files to ensure proper internationalization?

[roomote]

Is this intentional? The constructor receives options.fireworksApiKey but passes it as apiKey to the base class. While this works, it's inconsistent with the pattern where the base class expects the provider-specific key name. Other providers like Groq and DeepSeek follow this same pattern, but it might be clearer to document why this mapping is necessary.

[roomote]

The base class validates that apiKey is provided, but since we're passing fireworksApiKey as apiKey, we might want to add explicit validation here to provide a clearer error message:

Suggested change

	constructor(options: ApiHandlerOptions) {
	if (!options.fireworksApiKey) {
	throw new Error("Fireworks API key is required")
	}

This would make debugging easier for users who forget to provide the API key.

[roomote]

I notice several models have identical pricing (0.9/0.9 for input/output). Is this accurate according to Fireworks AI's pricing page? It might be worth double-checking these values to ensure users get accurate cost estimates. For example:

• llama-v3p3-70b-instruct: 0.9/0.9
• llama-v3p1-70b-instruct: 0.9/0.9
• qwen2p5-72b-instruct: 0.9/0.9
• qwen2p5-32b-instruct: 0.9/0.9

[roomote]

The test coverage is comprehensive! One suggestion: could we add a test case for when the API key is missing? This would ensure proper error handling:

it("should throw error when API key is missing", () => {
  expect(() => new FireworksHandler({})).toThrow("API key is required")
})

[daniel-lxs]

Closed in favor of 6652