Support options on completion calls

[parruda]

This is a draft for allowing passing API parameters in chat completions.

[danielfriis]

Needed this too 🙏

[parruda]

Does that make sense @crmne? If it does I can write some tests and move the PR to Ready

[parruda]

@adenta I saw your comment on the other PR, so do you think this method is good? Just waiting for confirmation from folks more familiar with the gem before I put any more work on it (tests, etc)

[MadBomber]

@crmne
Need this to address a building trend in providers attempt to distinguish their products without major impact to endpoint API compatibility. For example: https://docs.x.ai/docs/guides/live-search#data-sources-and-parameters

[danielfriis]

@crmne What do you think of this?

Would love to see it merged (after conflict resolution ofc), since it would allow for any option with the underlying API.

[crmne]

Thanks for the PR! I can see the real need here - providers keep adding unique features and we can't wrap every single one.

I like the direction, but let's fix the merge order:

render_payload(...).merge(options) is dangerous because user options could override critical RubyLLM parameters like model, messages, stream, etc.

Simple fix: Change it to options.merge(render_payload(...)) instead. This way user options go in first, then RubyLLM's required parameters take precedence.

For tests: I want to see this tested for each provider - verify that custom options work without breaking normal chat functionality across OpenAI, Anthropic, Gemini, etc.

Make that change and add provider tests, then this is good to merge! 🚀