* Support UX for parallel subagents
Similar to thinking ux
* Show prompt when expanded as well
* Add ellipsis
* Fix unit test
* Get subagents working with tool streaming changes
* Fixes
* Just keep this the same, close enough
This is a rethinking of the initial API proposed in `languageModelToolSupportsModel.d.ts`.
1. This switches to `models?: LanguageModelChatSelector[];` to control enablement.
definitely open to switching this out, but I think a synchronously-analyzable
expression is important to retain the data flows in core without too many races.
2. The extension is able to define a tool at runtime via registerToolDefinition. This
should let us have entirely service-driven tools from model providers without
requiring a static definition for each one. We can also have model-specific
variants of tools without a ton of package.json work for each variant of the tool
(as initially proposed using `when` clauses)
This then propagates that down into the tools service. Currently I have this as just
compiling to a `when` expression once it reaches the main thread. Then, for the tools
service, it takes an IContextKeyService in cases where tools should be enumerated,
and the chat input sets the model keys in its scoped context key service. This allows
the tools to be filtered correctly in the tool picker.
I initially thought about allowing multiple definitions be registered for the same tool
name/id for model-specific variants of tools but I realized that gets really gnarly and
we already have a `toolReferenceName` that multiple tools can register into.
Todo for tomorrow morning:
- Tools don't make it to the ChatRequest yet, or something, still need to investigate
- Need to make sure tools in prompts/models all work. For a first pass I think we can
let prompts/modes reference all tools by toolReferenceName.
- Validate that multiple tools actually can safely share a reference name (and do
some priority ordering?)
- General further validation
- Some unit tests
When I fixed the uris used to identify sessions, it revealed this bug for non-local session.
The main part of this change is avoiding the call to `LocalChatSessionUri.forSession` in mainThreadChatAgent. This call can't be used for non-local chat sessions
The subagents tool part of this change unfortunately makes it a lot larger
For #269213
This adds a new eslint rule for `as any` and `<any>({... })`. We'd like to remove almost all of these, however right now the first goal is to prevent them in new code. That's why with this first PR I simply add `eslint-disable` comments for all breaks
Trying to get this change in soon after branching off for release to hopefully minimize disruption during debt week work
For MCP I can already kind of get this from the tool name, but for
extension tools we previously had no way to know which extension
provided the tool.
This PR adds a `LanguageModelToolInformation.source` containing details
about where the tool came from. I also use this to include the MCP
server instructions which is needed for #250017.
cc @aeschli @roblourens
<!-- Thank you for submitting a Pull Request. Please:
* Read our Pull Request guidelines:
https://github.com/microsoft/vscode/wiki/How-to-Contribute#pull-requests
* Associate an issue with the Pull Request.
* Ensure that the code is up-to-date with the `main` branch.
* Include a description of the proposed changes and how to test them.
-->
This adds a `toolProgress` proposed API that allows extensions to report
progress keyed on the `toolInvocationToken`. Internally, when given to a
tool, this now includes the call ID of the tool.
We can use that both from extensions and internally to report progress
for tools, and I hooked this up for MCP servers. Currently only the text
is updated.
Involved some changes in the progress service internally:
- Previously `viewId` was a naked string, I wrapped it in an object to
make it more identifiable.
- The progress service is in `workbench/services` and directly calls
into other services to effect progress. In leui of going for a full
'contribution' model, I made a small `ILanguageModelToolProgressService`
that it writes state into and that can be read back out. The state
(an observable) is kept as long as progress is ongoing or this is
is an observer.
* Clean up internal edit file tool, take a proper URI from the extension
Move more work back to the extension
For microsoft/vscode-copilot#15348
* Remove this
* Pass model to tools
When tools make requests, they should use the right model. So we
- save the model id on the request
- look it up when the tool is invoked
- resolve it to a LanguageModelChat in the EH
* Fix build
Matt Bierner
Rob Lourens
Connor Peet
Martin Aeschlimann
Logan Ramos
bhavyaus
Connor Peet
Daniel Imms
Benjamin Pasero
Don Jayamanne
Joyce Er
Johannes
Sandeep Somavarapu
Your Name
Tyler James Leonhardt