anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Manually added models seem to count twice the ctx usage of ones added via opencode auth #2348

New Issue
Closed
opened 2026-02-16 17:35:15 -05:00 by yindo · 8 comments
yindo commented 2026-02-16 17:35:15 -05:00
Owner
Copy Link
Copy Source

Originally created by @ghost on GitHub (Oct 29, 2025).

Description

I manually added models from my provider, as they have a new model that isn't on models.dev yet

I have setup context window sizes etc correctly

But the same request uses literally double the registered context in the top right corner on the same model on manually added ones in the opencode.json vs logging in with opencode auth on the cli

OpenCode version

0.28

Steps to reproduce

Manually add models you can auth into, run the same request

Screenshot and/or share link

No response

Operating System

arch btw

Terminal

ghostty btw

Originally created by @ghost on GitHub (Oct 29, 2025). ### Description I manually added models from my provider, as they have a new model that isn't on models.dev yet I have setup context window sizes etc correctly But the same request uses literally double the registered context in the top right corner on the same model on manually added ones in the opencode.json vs logging in with opencode auth on the cli ### OpenCode version 0.28 ### Steps to reproduce Manually add models you can auth into, run the same request ### Screenshot and/or share link _No response_ ### Operating System arch btw ### Terminal ghostty btw
yindo added the bug label 2026-02-16 17:35:15 -05:00
yindo closed this issue 2026-02-16 17:35:15 -05:00
yindo commented 2026-02-16 17:35:15 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 29, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #3322: Reports discrepancies in token usage calculation between web and TUI interfaces, where different calculation methods result in significantly different token counts being displayed

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Oct 29, 2025): This issue might be a duplicate of existing issues. Please check: - #3322: Reports discrepancies in token usage calculation between web and TUI interfaces, where different calculation methods result in significantly different token counts being displayed Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:35:15 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Oct 29, 2025):

I doubled the context limit to 400k and i have a glm4.6 still replying even though the counter is over 200k

@ghost commented on GitHub (Oct 29, 2025): I doubled the context limit to 400k and i have a glm4.6 still replying even though the counter is over 200k
yindo commented 2026-02-16 17:35:15 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 29, 2025):

I bet it is double counting cached tokens, can u send an example? /share maybe?

@rekram1-node commented on GitHub (Oct 29, 2025): I bet it is double counting cached tokens, can u send an example? /share maybe?
yindo commented 2026-02-16 17:35:15 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Oct 29, 2025):

i have /share disabled, I'll try to whip you up some examples in a mo, i'll be back to you within 30 mins

@ghost commented on GitHub (Oct 29, 2025): i have /share disabled, I'll try to whip you up some examples in a mo, i'll be back to you within 30 mins
yindo commented 2026-02-16 17:35:15 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Oct 29, 2025):

Image

heres a screenshot of a glm 4.6 (200k ctx) able to reply after 200k tokens in the counter (i forced it to 400k ctx to experiment)
message 1 contained an mcp call that opened a huge memory json on purpose which sent it to "199k" and it was still able to reply after that

normally it counts it much lower than that

i do need to double check this isn't somehow provider side though, I'm still trying to pick through it

@ghost commented on GitHub (Oct 29, 2025): <img width="2903" height="1533" alt="Image" src="https://github.com/user-attachments/assets/ab200d39-bb53-48e5-a443-9cc84aa31109" /> heres a screenshot of a glm 4.6 (200k ctx) able to reply after 200k tokens in the counter (i forced it to 400k ctx to experiment) message 1 contained an mcp call that opened a huge memory json on purpose which sent it to "199k" and it was still able to reply after that normally it counts it much lower than that i do need to double check this isn't somehow provider side though, I'm still trying to pick through it
yindo commented 2026-02-16 17:35:16 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Oct 29, 2025):

i'll get back to you, i think the provider has updated and is misreporting cached tokens, I'm just looking through raw responses parsing it, i just assumed the token counting was local but that's mb

@ghost commented on GitHub (Oct 29, 2025): i'll get back to you, i think the provider has updated and is misreporting cached tokens, I'm just looking through raw responses parsing it, i just assumed the token counting was local but that's mb
yindo commented 2026-02-16 17:35:16 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Oct 30, 2025):

might have looked like a weird example but i can't share code i'm working on that tips the context and crapping out json into a memory mcp was the quickest/easiest way I could figure of getting the ctx over 200k to test my hacky fix where I just manually forced the context to 400k

probably close this issue, I think it's really provider side, just hadn't spent enough time studying streaming outputs cause i wanna use these tools not build them, but i see a divergence in the way they're reporting data now

hopefully dax got a good laugh

@ghost commented on GitHub (Oct 30, 2025): might have looked like a weird example but i can't share code i'm working on that tips the context and crapping out json into a memory mcp was the quickest/easiest way I could figure of getting the ctx over 200k to test my hacky fix where I just manually forced the context to 400k probably close this issue, I think it's really provider side, just hadn't spent enough time studying streaming outputs cause i wanna use these tools not build them, but i see a divergence in the way they're reporting data now hopefully dax got a good laugh
yindo commented 2026-02-16 17:35:16 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 30, 2025):

Haha sounds good thanks

@rekram1-node commented on GitHub (Oct 30, 2025): Haha sounds good thanks
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2348
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?