Skip to content

86: Add default limit for tools completions #87

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

rhys117
Copy link
Contributor

@rhys117 rhys117 commented Apr 1, 2025

Resolves #86

Purpose

Introduces a configurable limit on tool completions to prevent infinite loops and excessive API usage. This feature adds protection against scenarios where AI responses might trigger continuous tool calls.

Implementation Details

  • Added max_tool_llm_calls configuration option (default: 25 calls)
  • Per-chat override capability through existing contexts
  • Implemented ToolCallLimitReachedError when limit is exceeded
  • Added tracking of tool llm calls via number_of_tool_completions counter
  • Can be overridden for unlimited tool completions with nil

Usage Example

# Global configuration
RubyLLM.configure do |config|
  config.max_tool_llm_calls = 10  # Set default limit
end

Testing

  • Added RSpec test cases for OpenAI + Claude + Openrouter
  • Verified both global configuration and per-chat override functionality
  • Confirmed error raised when limit is reached

Documentation

  • Added section in tools.md guide explaining the feature
  • Included examples for both global and per-chat configuration

TODO

  • Add VCR cassettes for testing with additional providers (I do not have API keys for these providers)

@@ -105,6 +107,10 @@ def handle_tool_calls(response, &)
end

def execute_tool(tool_call)
raise ToolCallsLimitReachedError, "Tool calls limit reached: #{@max_tool_calls}" if max_tool_calls_reached?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It might be worth discussing if this should be handled via the chat instead of raising an unhandled error.

@rhys117 rhys117 marked this pull request as draft April 1, 2025 13:54
- Otherwise the chat object could not have 'ask' executed on again due to malformed  messages
@crmne crmne added the enhancement New feature or request label Apr 2, 2025
@rhys117 rhys117 marked this pull request as ready for review April 7, 2025 12:15
@rhys117 rhys117 changed the title 86: Add default limit for tools calls 86: Add default limit for tools completions Apr 7, 2025
Copy link
Owner

@crmne crmne left a comment

Choose a reason for hiding this comment

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

changing the whole interface to chat is a bit heavy handed. this should be a simple config change.

lib/ruby_llm.rb Outdated
Comment on lines 33 to 34
def chat(model: nil, provider: nil)
Chat.new(model: model, provider: provider)
def chat(model: nil, provider: nil, max_tool_completions: config.max_tool_completions)
Chat.new(model: model, provider: provider, max_tool_completions: max_tool_completions)
Copy link
Owner

Choose a reason for hiding this comment

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

changing the whole interface to chat is a bit heavy handed. this should be a simple config change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the feedback @crmne. I've adjusted things so the chat interface isn't modified, and instead, a single instance can use an override from the config using with_max_tool_completions.

Please let me know what you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

@crmne would love an update here ... I'm getting looping tool calls as well, and would like to avoid implementing my own solution.

@rhys117 rhys117 mentioned this pull request May 9, 2025
Copy link
Owner

@crmne crmne 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 your work!

Left you some comments + I'm not a big fan of the naming. max_tool_calls is less wordy. Same thing for all the instances of the name, like the error name and the documentation.

Comment on lines 33 to 35
{ title: Faker::Name.name, score: rand(1000) },
{ title: Faker::Name.name, score: rand(1000) },
{ title: Faker::Name.name, score: rand(1000) }
Copy link
Owner

Choose a reason for hiding this comment

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

I think we can come up with a fake title instead of adding a dependency for these three lines of code.

Comment on lines 106 to 110
def with_max_tool_completions(...)
to_llm.with_max_tool_completions(...)
self
end

Copy link
Owner

Choose a reason for hiding this comment

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

We now have configuration Contexts so we don't need the per-chat max tool completions method.

@@ -11,7 +11,7 @@ module RubyLLM
class Chat # rubocop:disable Metrics/ClassLength
include Enumerable

attr_reader :model, :messages, :tools
attr_reader :model, :messages, :tools, :number_of_tool_completions
Copy link
Owner

Choose a reason for hiding this comment

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

No need to have it as attr_reader.

Comment on lines 67 to 71
def with_max_tool_completions(max_tool_completions)
@max_tool_completions = max_tool_completions
self
end

Copy link
Owner

Choose a reason for hiding this comment

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

We now have configuration Contexts so we don't need the per-chat max tool completions method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👌 Much nicer for overridding

Comment on lines 132 to 136
if max_tool_completions_reached?
raise ToolCallCompletionsLimitReachedError, "Tool completions limit reached: #{@max_tool_completions}"
end

@number_of_tool_completions += 1
Copy link
Owner

Choose a reason for hiding this comment

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

Shouldn't this be at the top of the method? Say max_tool_completions is 0, that would mean that we should process 0 tool completions, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the review @crmne, you're right, this should have been before the max_tool_completions_reached? check. I've amended this now along with your other feedback.

I haven't manually tested the new changes yet, but the test cases are passing for the providers I have keys for.

Please let me know what you think.

Comment on lines +80 to +83
if context.config
@config = context.config
@max_tool_llm_calls = @config.max_tool_llm_calls
end
Copy link
Contributor Author

@rhys117 rhys117 Jun 12, 2025

Choose a reason for hiding this comment

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

Wrapped this in a conditional to ensure that the config was present on the context. This more closely aligns with the assignment in the initialiser (@config = context&.config || RubyLLM.config)|

If I've made a mistake here, please let me know.

@rhys117 rhys117 requested a review from crmne June 12, 2025 12:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Looping Tool Calls
3 participants