4 ms·

Hi! Valid challenge, I am probably misremembering. We were playing with various 'one-interface to all providers' solutions and I might have mixed up RubyLLM the

Hi! Valid challenge, I am probably misremembering. We were playing with various 'one-interface to all providers' solutions and I might have mixed up RubyLLM there. Sorry for that. I will have a deep dive into which things I felt we needed to adapt per provider. I didn't mean to imply that you have to solve all of our wants of course. One thing we did do was monkey-patch the spot where tool_calls are performed by RubyLLM. We had our own mechanism for that and were able to skip RubyLLM's and still extract the tool calls and run them through our own tool harness. That all worked beautifully. I don't know if that type of stuff is something you want PRs on or that you want to keep steering towards the route that does everything within RubyLLM classes. Happy to contribute some of that.

earcar 3mo ago
Interesting! What were you guys trying to achieve by running them in your own tool harness?
- mosselman 3mo ago
  We had already implemented tool_calls in our own database and have a system that executes them and creates our conversation array, etc. So we wanted to leverage the providers that RubyLLM supports without having to change the tool execution in our platform.
mosselman 3mo ago
Update since the side thread blew up. There is some difference in how OpenAI and Anthropic handle 'max_tokens'. The OpenAI way raises errors in Anthropic for example. I will look at confirming this a bit more in depth once we've taken our RubyLLM based adapter in production and see if I can make some contribution. Thanks for all the work! It is incredibly impressive and I never meant any disrespect.