Conversation
- Add MODEL_CONTEXT_WINDOWS map with explicit sizes per model - getContextWindowSize() checks map first, falls back to isLongContextModel - Add test coverage for context window size resolution
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
leecoder
changed the title
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent) Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
lamiskin
pushed a commit
to lamiskin/opencode-kiro-auth
that referenced
this pull request
Sep 3, 2026
Instead of hardcoding context sizes, query ListAvailableModels API to get actual tokenLimits.maxInputTokens per model. Cached for 5 minutes per account/region. Falls back to heuristics when unavailable. Implementation from tickernelz PR tickernelz#121
This was referenced Sep 3, 2026
RvVeen
added a commit
to Servoy/opencode-kiro-auth
that referenced
this pull request
Sep 12, 2026
Implements upstream tickernelz#121. Ask GET /ListAvailableModels?origin=AI_EDITOR for each model's tokenLimits.maxInputTokens with the active account's token, and prefer that over the hardcoded table in getModelContextLimit. Never awaited: it only sharpens a token estimate, so no request waits on it. A failed or empty catalog leaves the built-in limits untouched. This matters because what Kiro advertises publicly has not always matched what it serves — upstream tickernelz#128 measured opus-5 plateauing at ~166K against a documented 1M — and the limits are account-specific. Asking the service ends the guessing for whoever is running it. Held for 30 minutes rather than the 5 the upstream PR used: context windows change a few times a year, not a few times an hour. The cache is keyed by region and profile ARN, so a different account refetches at once instead of inheriting limits that are not its own. Note the advertised registry limit is still built at plugin init, before any token exists, so discovery corrects the token estimate immediately and the advertised value only on a later start. Also complete the logger mock in every test file that stubs it. bun's mock.module is global, so a stub missing logApiRequest broke whichever file happened to run after it.
RvVeen
added a commit
to Servoy/opencode-kiro-auth
that referenced
this pull request
Sep 12, 2026
…kernelz#121) Implements upstream tickernelz#121. Ask GET /ListAvailableModels?origin=AI_EDITOR for each model's tokenLimits.maxInputTokens with the active account's token, and prefer that over the hardcoded table in getModelContextLimit. Never awaited: it only sharpens a token estimate, so no request waits on it. A failed or empty catalog leaves the built-in limits untouched. This matters because what Kiro advertises publicly has not always matched what it serves — upstream tickernelz#128 measured opus-5 plateauing at ~166K against a documented 1M — and the limits are account-specific. Asking the service ends the guessing for whoever is running it. Held for 30 minutes rather than the 5 the upstream PR used: context windows change a few times a year, not a few times an hour. The cache is keyed by region and profile ARN, so a different account refetches at once instead of inheriting limits that are not its own. Note the advertised registry limit is still built at plugin init, before any token exists, so discovery corrects the token estimate immediately and the advertised value only on a later start. Also complete the logger mock in every test file that stubs it. bun's mock.module is global, so a stub missing logApiRequest broke whichever file happened to run after it.
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
1 participant
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.
Summary
Discover each account's model context window from Kiro's live model catalog instead of maintaining a hardcoded context-size table.
Changes
src/plugin/models.ts: QueryGET https://q.{region}.amazonaws.com/ListAvailableModels?origin=AI_EDITORwith the selected account's bearer token. Readmodels[].tokenLimits.maxInputTokens, map resolved Kiro model IDs back to plugin aliases, cache results for 5 minutes, and fall back to the existing-1malias heuristic when discovery is unavailable.src/core/request/request-handler.ts: Refresh the catalog after selecting/refreshing the active account and before preparing the request, so response usage estimation uses the active account's actual limits.src/__tests__/models.test.ts: Verify live API limits and alias mapping.Verification
bun run buildpassedbun test src/__tests__/models.test.tspassed (1 pass, 0 fail)ListAvailableModelsreturnstokenLimits.maxInputTokens(including 1M Sonnet 4.6 and account-specific limits for DeepSeek/MiniMax).Note:
bun teststill has unrelated pre-existing failures inbearer-retry.test.tsandsdk-client.test.ts; the focused model test and build pass.