Summary
In a 24-hour OpenCode session routed through this plugin (kiro provider, model claude-opus-5, 806 step-finishes, zero 4xx errors), every single API call reported input_tokens ≤ 166,512 even though the local conversation grew to ~498K tokens by session end. Growth was asymptotic: ~100K at 39% of steps, ~130K at 65%, ~150K at 83%, ~160K at 93%, and a final plateau of 166,512 at step 805/806. The model only ever saw the most recent ~166K of the conversation — a silent sliding window, not a rejection.
This matters because Kiro's public blog advertises Claude Opus 5 with a full 1M context window (2.2x credit multiplier) and this plugin's model-registry mirrors that as limit.context: 1000000. OpenCode therefore believes it has ~834K headroom of free space and never auto-compacts. On long sessions the model is effectively amnesic beyond the recent ~166K tail while the UI context bar reads ~16%, which looks healthy.
Evidence
From one 24h / 806-step-finish OpenCode session on kiro / claude-opus-5, 2026-09-02 09:48 → 2026-09-03 10:08 UTC:
| Metric |
Value |
API-reported input_tokens ceiling across all 806 requests |
166,512 (no 4xx, no warnings) |
cache_read_input_tokens on every request |
0 |
| Crossed 100K at |
39% of steps (≈ step 314) |
| Crossed 130K at |
65% of steps (≈ step 524) |
| Crossed 150K at |
83% of steps (≈ step 669) |
| Crossed 160K at |
93% of steps (≈ step 750) |
| Reached 166,512 at |
step 805 / 806 (hard plateau) |
Model switch to a different provider at 10:09: first request input_tokens |
498,086 (= full local conversation history) |
Delta after the switch (498,086 vs ≤166,512) confirms the local conversation had grown to ~498K while opus-5 was being served only the trailing ~166K window.
Where it comes from
Plugin arithmetic (v2.0.0, commit 08f06b4):
inputTokens = round(contextWindow × contextUsagePercentage / 100) − outputTokens
src/plugin/streaming/stream-transformer.ts:301-305
getContextWindowSize returns 200,000 unless the model name contains -1m (src/plugin/models.ts:11-13), and LONG_CONTEXT_MODELS is keyed off the -1m suffix (src/constants.ts:101). claude-opus-5 has no -1m variant in the plugin, and Kiro does not expose a separate long-context alias for Opus 5 (per upstream PR #116).
The reported ceiling fits 200K exactly: 166,512 ≈ 200,000 × 0.833, so the backend's contextUsagePercentage is consistent with a ~200K-class window, not 1M. The plugin's reported 166K is therefore a faithful fraction of 200K; the misleading part is the advertised limit.context: 1000000 that OpenCode reads from the model-registry, which prevents auto-compaction and makes the ~84% utilization look like "lots of headroom."
Why catalog discovery (PR #121) may not fix this
If Kiro's catalog reports 1_000_000 for claude-opus-5 (matching the public blog claim), then catalog-based discovery would confirm the 1M headroom while the CodeWhisperer/Q layer continues to serve a ~200K window. The silent truncation would continue undetected.
Suggested checks before trusting a catalog-derived 1M for opus-5:
- Cross-check the catalog value against observed
contextUsagePercentage behavior on a long session — if the plateau divides back to ~200K, the catalog claim is wrong or the long-context path is gated.
- Until Kiro confirms 1M is actually served end-to-end, pin
claude-opus-5 to contextWindow: 200000 so clients can compact appropriately (mirroring Bedrock's 1M beta requirement, see #16486).
- If a long-context path does exist, surface it as a separate model id or beta flag so users opt in knowingly — same shape as AWS Bedrock's
context-1m-2025-08-07 beta.
Comparable reports
- anomalyco/opencode#45168 — same failure pattern on another provider: input pinned at exactly
196,608 = 262,144 − 65,536, cache_read=0 on every subsequent request, silent cost blowup.
- anomalyco/opencode#12452 and #12507 — Bedrock Claude: 1M context requires the
context-1m-2025-08-07 beta; catalog says 1M but API enforces 200K.
- anomalyco/opencode#16486 — 1M beta flag broke specifically on AWS Bedrock.
Request
- Confirm whether the CodeWhisperer / Q layer currently serves
claude-opus-5 on a ~200K-class window, or whether a 1M path exists behind an opt-in mechanism (separate model id / beta flag / header).
- If 200K is the current reality, reflect that in the advertised
limit.context so OpenCode auto-compacts on long sessions; or, if a 1M path genuinely exists, document how to unlock it (model alias, beta flag, upstream config) so users aren't silently running with a tail-only ~166K.
Evidence gathered from local session telemetry (OpenCode SQLite step-finish data) + plugin source inspection (v2.0.0, commit 08f06b4). Happy to share more detail on request.
Summary
In a 24-hour OpenCode session routed through this plugin (
kiroprovider, modelclaude-opus-5, 806 step-finishes, zero 4xx errors), every single API call reportedinput_tokens ≤ 166,512even though the local conversation grew to ~498K tokens by session end. Growth was asymptotic: ~100K at 39% of steps, ~130K at 65%, ~150K at 83%, ~160K at 93%, and a final plateau of 166,512 at step 805/806. The model only ever saw the most recent ~166K of the conversation — a silent sliding window, not a rejection.This matters because Kiro's public blog advertises Claude Opus 5 with a full 1M context window (2.2x credit multiplier) and this plugin's model-registry mirrors that as
limit.context: 1000000. OpenCode therefore believes it has ~834K headroom of free space and never auto-compacts. On long sessions the model is effectively amnesic beyond the recent ~166K tail while the UI context bar reads ~16%, which looks healthy.Evidence
From one 24h / 806-step-finish OpenCode session on
kiro / claude-opus-5, 2026-09-02 09:48 → 2026-09-03 10:08 UTC:input_tokensceiling across all 806 requestscache_read_input_tokenson every requestinput_tokensDelta after the switch (498,086 vs ≤166,512) confirms the local conversation had grown to ~498K while opus-5 was being served only the trailing ~166K window.
Where it comes from
Plugin arithmetic (v2.0.0, commit
08f06b4):getContextWindowSizereturns 200,000 unless the model name contains-1m(src/plugin/models.ts:11-13), andLONG_CONTEXT_MODELSis keyed off the-1msuffix (src/constants.ts:101).claude-opus-5has no-1mvariant in the plugin, and Kiro does not expose a separate long-context alias for Opus 5 (per upstream PR #116).The reported ceiling fits 200K exactly:
166,512 ≈ 200,000 × 0.833, so the backend'scontextUsagePercentageis consistent with a ~200K-class window, not 1M. The plugin's reported 166K is therefore a faithful fraction of 200K; the misleading part is the advertisedlimit.context: 1000000that OpenCode reads from the model-registry, which prevents auto-compaction and makes the ~84% utilization look like "lots of headroom."Why catalog discovery (PR #121) may not fix this
If Kiro's catalog reports
1_000_000forclaude-opus-5(matching the public blog claim), then catalog-based discovery would confirm the 1M headroom while the CodeWhisperer/Q layer continues to serve a ~200K window. The silent truncation would continue undetected.Suggested checks before trusting a catalog-derived 1M for opus-5:
contextUsagePercentagebehavior on a long session — if the plateau divides back to ~200K, the catalog claim is wrong or the long-context path is gated.claude-opus-5tocontextWindow: 200000so clients can compact appropriately (mirroring Bedrock's 1M beta requirement, see #16486).context-1m-2025-08-07beta.Comparable reports
196,608 = 262,144 − 65,536,cache_read=0on every subsequent request, silent cost blowup.context-1m-2025-08-07beta; catalog says 1M but API enforces 200K.Request
claude-opus-5on a ~200K-class window, or whether a 1M path exists behind an opt-in mechanism (separate model id / beta flag / header).limit.contextso OpenCode auto-compacts on long sessions; or, if a 1M path genuinely exists, document how to unlock it (model alias, beta flag, upstream config) so users aren't silently running with a tail-only ~166K.Evidence gathered from local session telemetry (OpenCode SQLite step-finish data) + plugin source inspection (v2.0.0, commit
08f06b4). Happy to share more detail on request.