[vscode-lm] Add missing model families and correct stale context limits - #19
Open
simurg79 wants to merge 2 commits into
Open
[vscode-lm] Add missing model families and correct stale context limits#19simurg79 wants to merge 2 commits into
simurg79 wants to merge 2 commits into
Conversation
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
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.
What is the problem?
The built-in table of VS Code Language Model models had drifted from what the API actually offers. Several model families available through the VS Code LM provider were missing entirely, and some context-window figures for models that were listed had gone stale, so the extension reasoned about budgets that no longer matched reality.
How does this PR solve the problem?
It adds the missing model families and refreshes the stale context budgets in the shared model metadata, then updates the type, provider, and hook tests that assert against that table. The new figures come from a probe run against the live VS Code LM API rather than from vendor marketing pages, so the table reflects what the extension will actually be granted at runtime.
Where the probe could only establish a lower bound rather than an exact ceiling, the conservative lower bound was used instead of guessing upward. That is a deliberate trade-off: under-reporting a budget is safe, while over-reporting causes request failures. A small number of figures remain unverified and are documented as such rather than being silently presented as measured.
The extension version is also bumped from 3.53.5 to 3.53.6 so this model-table change ships under its own version. Only the extension manifest carries the version; every other consumer derives it, so no lockfile, package, or changelog updates were needed.
Companion documentation and probe evidence: https://github.com/simurg79/roo-vault/pull/648
How did you test the PR?
packages/typesfull suite: 85 passing.packages/buildsuite, all passing with no failures.packages/typespackage build plus type-checks across 3 packages, and ESLint: passing.The broader settings suite result is: 32 passing, 235 failing, 6 skipped. Only one representative Vertex failure group (4 passing, 1 failing) was re-run on the base commit and reproduced there; that specific failure is therefore pre-existing. The remaining failures were not established as pre-existing — no evidence supports generalising from that single sample. This PR does not claim a green full suite.
Deferred Items
Non-blocking review findings tracked separately; none change behaviour in this PR.
Agent notes
src/package.jsonversion bump.cd5596ccad7d143074deb04a7eea1b83deefc910; head5bcaa0df37cf6baf1c4a49f8e9469b3b75c53e3d(was832d92eae55070dbc39d771d984d3f309111b1b4).5bcaa0df37cf6baf1c4a49f8e9469b3b75c53e3dtouches only the manifest; 3.53.5 → 3.53.6. Sole version consumer, others derive.simurg79/Roo-Codeby explicit user approval; upstreamRooCodeInc/Roo-Codeis NOT the target.