feat: add RubyLLM provider passthrough#66
Open
aakashb95 wants to merge 1 commit into
Open
Conversation
✅ Deploy Preview for ruby-ai-agents ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
aakashb95
changed the title
rcoenen
added a commit
to konversio-org/konversio
that referenced
this pull request
May 19, 2026
…gistration The previous commit (d54fdd6) registered admin-chosen slot models in RubyLLM's per-process in-memory `Models` registry at boot. That works for the booting process but doesn't propagate when the admin later changes the model in Super Admin — Sidekiq workers keep the stale registry until restart. Solving cross-process invalidation correctly (generation counter + middleware, or Redis pub/sub) adds hot-path overhead per job for a "once in a blue moon" admin event. Online research turned up the right answer: this is a missing-feature in the agents SDK, not something we should patch around. The Agents SDK calls `RubyLLM::Chat.new(model: agent.model)` with no `provider:` or `assume_model_exists:`, which forces a registry lookup that fails for Scaleway / Nebius / Ollama / Azure-deployment IDs. RubyLLM has documented `assume_model_exists: true` as the idiom for custom IDs; chatwoot/ai-agents PR #66 ("feat: add RubyLLM provider passthrough", chatwoot/ai-agents#66) is open and threads the kwargs through Agents::Agent / Agents::Runner. This commit vendors that fix as a small `Module.prepend` on `RubyLLM::Chat#initialize` (`config/initializers/ai_agents_provider_passthrough.rb`). When a caller (the SDK) passes only `model:`, we default `provider: :openai, assume_model_exists: true` so the registry check is skipped. The HTTP call still goes to the configured `openai_api_base` (Scaleway etc.) — no silent provider fallback, fail-hard semantics unchanged. Delete the initializer once ai-agents > 0.9.1 with PR #66 is in Gemfile.lock. Removes the obsolete `Llm::Config.register_slot_models!` machinery added in d54fdd6. The boot-time `Llm::Config.initialize!` still runs from `config/initializers/llm_config.rb` to configure RubyLLM's global api_key / api_base. Hot path: zero overhead — every Sidekiq worker handles model changes transparently because nothing in the chat-construction path consults the per-process registry anymore. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rcoenen
added a commit
to konversio-org/konversio
that referenced
this pull request
May 19, 2026
…gistration The previous commit (be7cc82) registered admin-chosen slot models in RubyLLM's per-process in-memory `Models` registry at boot. That works for the booting process but doesn't propagate when the admin later changes the model in Super Admin — Sidekiq workers keep the stale registry until restart. Solving cross-process invalidation correctly (generation counter + middleware, or Redis pub/sub) adds hot-path overhead per job for a "once in a blue moon" admin event. Online research turned up the right answer: this is a missing-feature in the agents SDK, not something we should patch around. The Agents SDK calls `RubyLLM::Chat.new(model: agent.model)` with no `provider:` or `assume_model_exists:`, which forces a registry lookup that fails for Scaleway / Nebius / Ollama / Azure-deployment IDs. RubyLLM has documented `assume_model_exists: true` as the idiom for custom IDs; chatwoot/ai-agents PR #66 ("feat: add RubyLLM provider passthrough", chatwoot/ai-agents#66) is open and threads the kwargs through Agents::Agent / Agents::Runner. This commit vendors that fix as a small `Module.prepend` on `RubyLLM::Chat#initialize` (`config/initializers/ai_agents_provider_passthrough.rb`). When a caller (the SDK) passes only `model:`, we default `provider: :openai, assume_model_exists: true` so the registry check is skipped. The HTTP call still goes to the configured `openai_api_base` (Scaleway etc.) — no silent provider fallback, fail-hard semantics unchanged. Delete the initializer once ai-agents > 0.9.1 with PR #66 is in Gemfile.lock. Removes the obsolete `Llm::Config.register_slot_models!` machinery added in be7cc82. The boot-time `Llm::Config.initialize!` still runs from `config/initializers/llm_config.rb` to configure RubyLLM's global api_key / api_base. Hot path: zero overhead — every Sidekiq worker handles model changes transparently because nothing in the chat-construction path consults the per-process registry anymore. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
rcoenen
added a commit
to konversio-org/konversio
that referenced
this pull request
May 20, 2026
…gistration The previous commit (d164eba) registered admin-chosen slot models in RubyLLM's per-process in-memory `Models` registry at boot. That works for the booting process but doesn't propagate when the admin later changes the model in Super Admin — Sidekiq workers keep the stale registry until restart. Solving cross-process invalidation correctly (generation counter + middleware, or Redis pub/sub) adds hot-path overhead per job for a "once in a blue moon" admin event. Online research turned up the right answer: this is a missing-feature in the agents SDK, not something we should patch around. The Agents SDK calls `RubyLLM::Chat.new(model: agent.model)` with no `provider:` or `assume_model_exists:`, which forces a registry lookup that fails for Scaleway / Nebius / Ollama / Azure-deployment IDs. RubyLLM has documented `assume_model_exists: true` as the idiom for custom IDs; chatwoot/ai-agents PR #66 ("feat: add RubyLLM provider passthrough", chatwoot/ai-agents#66) is open and threads the kwargs through Agents::Agent / Agents::Runner. This commit vendors that fix as a small `Module.prepend` on `RubyLLM::Chat#initialize` (`config/initializers/ai_agents_provider_passthrough.rb`). When a caller (the SDK) passes only `model:`, we default `provider: :openai, assume_model_exists: true` so the registry check is skipped. The HTTP call still goes to the configured `openai_api_base` (Scaleway etc.) — no silent provider fallback, fail-hard semantics unchanged. Delete the initializer once ai-agents > 0.9.1 with PR #66 is in Gemfile.lock. Removes the obsolete `Llm::Config.register_slot_models!` machinery added in d164eba. The boot-time `Llm::Config.initialize!` still runs from `config/initializers/llm_config.rb` to configure RubyLLM's global api_key / api_base. Hot path: zero overhead — every Sidekiq worker handles model changes transparently because nothing in the chat-construction path consults the per-process registry anymore. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Member
|
@codex please review |
|
Codex Review: Didn't find any major issues. Nice work! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RubyLLM needs a mandatory
providerargument when weassume_model_exists.This is particularly useful for ollama/litellm setups.Also supported azure since RubyLLM already supports it