Hello! I’ve been using Traycer Desktop today, and so far, the experience has been great. However, I’m running into a massive issue with token usage skyrocketing after just a couple of prompts, and I wanted to flag this for investigation since I experienced similar behaviour in other orchestrators before like Nimbalyst. The Issue (GUI AGENTS ONLY): I am working on a heavy task (implementing custom auth) using GUI agents with a master agent setup. While my first 5h session went smoothly, my session afterwards were burning through limits almost instantly: First Spike: In a chat, I sent just 3 prompts (a ticket breakdown and a minor refinement), and my session usage instantly flew up to 45%. (I was kind of okay with it since it was a new session, but still too much!) Second Spike: Shortly after, I sent another minor prompt. I didnt instruct it to do much, but usage jumped from 45% to 88%. The Crash: I spent 10–15 minutes reviewing artifacts manually. Then I prompted to crosscheck a section of an artifact , and the model thought for 2–3 paragraphs, then tried to use MCP to spawn an agent but thats when my session usage completely maxed out (12%). The agent didn't even manage to spawn. When the context hit 100%, I hovered over it and noticed the cache read was at 500k. All my artifacts were maybe at 1000 words combined at this point, which i dont think is a lot ? This is all claude code max 5x running on Opus with similar work ethic when I was using raw claude code Feedback / Observations: I feel like GUI agents have different behaviour than terminal.. perhaps less properly utilizing ´´or maintaining the cache, causing the token drain to compound aggressively. Or perhaps in GUI mode, the claude code chat drops fast and it has to resend everything since its a new "session"? Idk.. I know other orchestrators (like Nimbalyst) have run into similar issues where token usage flies up insanely fast, their community had quite good feedback (check their discord)

Sorro, thanks for the detailed report. We will look into it what is going on.

Thanks!

Same issue here! Tokens are burning down fast even using claude, openai or openrouter models. @ancient-helmet-25923 If u have some news, pls tell me

I suspect its because the chats get killed fast and need to resume, or that all chats get resent, idk... In terminal sometimes I've seen it says "do you want to continue session, or summary".. I suspect in GUI mode, the chats get killed fast, and when it resumes it chooses the first option which eats tokens.

Make sense... maybe in GUI mode the chats just continue the session sending the full context again, idk

Yeah for example, it had finished its response on something, it said it will wait for a background process, but in reality it didn't. Then I simply responded "Has it finished?" -> 5% session usage tokens used. ??

Sorro, you mentioned that you were using a multi agent setup. The agents have tools to read each other's transcript. Right now the tool fetches the entire message history of the target agent. The transcripts can be long and can eat up a lot of tokens. You mentioned that the usage went up by 6% for opus, even though the heavy-lifting was done by a separate codex session. Can you confirm whether the opus session tried reading the transcript through

traycer_a2a/traycer_get_transcript

. Maybe that explains the huge bumps you are seeing? Meanwhile, we will patch the tool so the responses are paged, instead of being dumped in full.

Tried looking through the chat, could not find that... And I think I know why. When I said the usage went up, it went up INSTANTLY, before the codex has even started its critique, so it would make sense that it would go up if it read the transcript after, but this was before the codex had even started. The latest issue I had as I just mentioned was that the usage went up instantly when I sent a simple prompt which was the similar behaviour I experienced. (no sub agents or agent communication)

We have been collecting stats and data on our internal usage. We do have a lead on transcript RPCs potentially causing context bloat especially when changing models and we are actively fixing that We have not observed large bumps on consecutive prompts. Getting some stats from your sessions would be super helpful. @rapid-van-6755, can share the next steps

Ok interesting... The spikes has happened even without changing models though. Are you guys using GUI agents internally? Does it maybe have anything to do with it? Maybe a bug where new session on some prompts in GUI mode? I am going to try to use terminal agents moving forward to see if that makes any difference.

We are using GUI agents. Will let you know once the fixes land in main

Claude Code

We are using everything…

Not sure if this would classify under similar bug. But has seen this happen sometimes where the parent agent says that it's agent has ended its turn without replying but from the gui of what I can see, the sub agent was processing normally. https://cdn.discordapp.com/attachments/1520164395127410689/1521493499973865482/9ecf374c9c6f672a3e58e1896bb06b8e.png?ex=6a4508be&is=6a43b73e&hm=ea6b88f6421983ca9be02d94f033c4563ea889cadf243d389fc513ea18904bdf&

Sorro, if you are available we can get on a call. It would be really helpful to get some stats from your machine.

I would love to, however I am at work (using traycer for work as well) and am unavailable to hop on a call right now.

Okay, I can share a couple of scripts to get the token usage and cache usage stats for claude code scripts.

Sounds good.

This is separate and we are already tracking it. Will be fixed soon

Hi Sorro, could you please run the above script and share the output it produces The script compares Claude usage from raw Claude CLI sessions vs Claude SDK /launched sessions. Internally, we have not seen any usage discrepancy between usage data for Claude through the CLI and Claude through Traycer, but this will help us verify against your local transcripts. The script will also write detailed jsonl files for accounting. The output paths for those files will be printed in stdout. Please share the stdout and the generated files. https://cdn.discordapp.com/attachments/1520164395127410689/1521516803485073448/cc_usage_summary.py?ex=6a451e72&is=6a43ccf2&hm=1cde408989b8805505eca249c5b8b441d5aa3a989064ddbb46dbe57d3a637d2a&

Will try to run the script soon!

Thanks Sorro. How are you measuring the 6% bump on every message submit?

Checking claude code usage right before & after sending a message

We did roll out a few improvements over the days. However, if you could help us with token usage data for claude code, that would allow us to compare any differences observed. Please run the above script and provide us the two log files it generates. https://cdn.discordapp.com/attachments/1520164395127410689/1527017573948850396/cc_usage_summary.py?ex=6a592170&is=6a57cff0&hm=28fa6776404bf47236b33737261b054a9e523f8c646f0d158277b01b201d4e00&

Will it show usage from 2 weeks ago backward ?

Yes it would

maybe the same here .. https://discord.com/channels/1230383226376163328/1230383226376163331/1527346683539886330

My main issue is with GUI agents, TUI agents seems to be alot better. I've tried GUI agents again today and hit session usage twice (I almost never hit it with TUI agents). Sent the report over to Amitesh, hopefully they can find the issue.

We have made a couple of improvements for Claude in the 1.1.7 release. We were killing the claude cli process for the gui session and invoking the resume API from claude sdk for the next turn. However that endpoint starts a fresh claude cli process and injects some metadata related to the git status + a last few commits near the end of the system prompt. If the last turn made some changes or made a commit, this caused this status/ commit info to change, the prefix changed and almost the entire the token amount had to be re-cached for the new turn. We have added a grace period so that supporting claude processes are not killed instantly, so this cache disruption doesn't happen. However we are still tuning the parameters.

Okay, interesting. Thanks for the update!

Is this issue fixed now?