Skip to content
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

Support tools role in messages in the pipeline #862

Open
jhrozek opened this issue Jan 31, 2025 · 2 comments
Open

Support tools role in messages in the pipeline #862

jhrozek opened this issue Jan 31, 2025 · 2 comments

Comments

@jhrozek
Copy link
Contributor

jhrozek commented Jan 31, 2025

The open interpreter support in PR #820 added handling of role: tool messages scoped to open interpreter. This was the right thing to scope them to the tool as we wanted to get the tool support in, but we should support that message role in general in our pipeline.

more todo items would probably come out when we do the work but for now I think we should do:

  • when messages with that role are processed (e.g. get_last_user_message_block) do we take the tools role into account
  • make sure we don't touch those in pipeline to avoid breaking the tools

We can add a bunch of tests just against the openai/anthropic api to make sure we follow their APIs, no need to tie this to a specific client.

@yrobla
Copy link
Contributor

yrobla commented Jan 31, 2025

It would also be worth investigating how this role is being used in other tools (if that's used at all) and how to better support it

@aponcedeleonch
Copy link
Contributor

We should investigate which clients besides Open Interpreter are using tools to extract code snippets from files. After #945 we are able to detect when Open Interpreter does it and extract the detected code snippets. Potentially we can build something generic for detecting snippets and not Open Interpreter specific.

See original discussion in PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants