You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GPT-5.5 visible token count does not drop mid-session like GPT-5.4 and reaches hard compaction sooner #25202
The issue is that the visible token count behavior appears different between gpt-5.4 and gpt-5.5 in long sessions.
With gpt-5.4, the visible token count can sometimes drop mid-session before I manually compact, for example something like:
~200k -> ~100k
That lets the session continue longer before I need to compact.
With gpt-5.5, the visible token count mostly just keeps increasing until it hits hard compaction around ~275k tokens.
So the practical UX difference is:
gpt-5.4: visible count sometimes reduces mid-session and I can keep going longer
gpt-5.5: visible count mostly rises continuously until hard compaction, which makes me compact more often
Expected behavior
I would expect gpt-5.5 to behave similarly to gpt-5.4 in long sessions, either by:
applying the same visible pruning / packing behavior, or
at least making the token accounting behavior consistent enough that it does not appear to reach hard compaction significantly sooner for similar work
Actual behavior
gpt-5.5 appears not to get the same visible mid-session token-count drops that gpt-5.4 gets.
Instead, the visible count mostly climbs until hard compaction around ~275k.
Notes
Same machine / same OpenCode install
Observed on v1.14.30
I noticed v1.14.25 mentions GPT-5.5 with OpenAI OAuth now uses the correct context limits to avoid compaction issues, but I still see this behavior on v1.14.30
Local logs suggest GPT-5.5 compaction does exist, so this report is specifically about the lack of visible mid-session count reductions / pruning behavior compared with GPT-5.4
Repro outline
Start a fresh long-running session with gpt-5.4
Let the visible token count grow substantially
Observe that the count can sometimes drop mid-session before manual compaction
Start a similar long-running session with gpt-5.5 on the same install
Observe that the visible token count mostly rises continuously until hard compaction near ~275k
Question
Is this expected model-specific accounting / pruning behavior, or is there still a gpt-5.5-specific regression in how token usage, pruning, or pre-compaction packing is handled / displayed?
If you have confirmed those fixes did not resolve the issue on v1.14.30 (as noted in your report), this may be a regression or a related but distinct problem. Please reference those issues in your report so maintainers have the full context.
GPT 5.5 **SMALLER** context limits are not respected #24751 is not exactly my case because I am not reporting custom config overrides, but the 400k context / 272k input behavior described there lines up very closely with the practical limit I still observe
On v1.14.30 I still see the following behavior:
gpt-5.4: the visible token count can drop mid-session before manual compaction, which lets the session continue longer
gpt-5.5: the visible token count mostly rises continuously and then hard-compacts around ~275k
So from my side this still reproduces on the latest public release and seems more consistent with a remaining / regressed gpt-5.5 context-limit or pruning/accounting difference than with a purely expected model behavior difference.
Hey team .. sorry to be boring but is this issue deeper than tightening token counts?
Several versions of OpenCode have been released and we are still compacting at 65-68% context.
The reason I bring this up here is because if you had logic to do some sort of pruning which is what this issue is talking about .. then maybe it never runs because the context level is miscalculated.
Activity
github-actions commentedon May 1, 2026
This issue might be a duplicate of (or related to) existing issues. Please check:
If you have confirmed those fixes did not resolve the issue on v1.14.30 (as noted in your report), this may be a regression or a related but distinct problem. Please reference those issues in your report so maintainers have the full context.
ksav1370 commentedon May 1, 2026
Thanks, I checked both linked issues.
400k context / 272k inputbehavior described there lines up very closely with the practical limit I still observeOn
v1.14.30I still see the following behavior:gpt-5.4: the visible token count can drop mid-session before manual compaction, which lets the session continue longergpt-5.5: the visible token count mostly rises continuously and then hard-compacts around~275kSo from my side this still reproduces on the latest public release and seems more consistent with a remaining / regressed
gpt-5.5context-limit or pruning/accounting difference than with a purely expected model behavior difference.thaoula commentedon May 3, 2026
Just to add still seeing OpenCode misrepresenting the context size .. compaction is happening between 250-275k and percentage of context is 68%.
thaoula commentedon May 6, 2026
Hey team .. sorry to be boring but is this issue deeper than tightening token counts?
Several versions of OpenCode have been released and we are still compacting at 65-68% context.
The reason I bring this up here is because if you had logic to do some sort of pruning which is what this issue is talking about .. then maybe it never runs because the context level is miscalculated.
We are using OAuth connection and not API access.
rekram1-node commentedon May 10, 2026
We dont have pruning enabled by default, also gpt-5.5 through oauth has a restricted context window of 400k
github-actions commentedon Jul 10, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.