We are rewriting the app around this. We need you to ship the primitives so a Bot is an object, not an unbounded thread.
Problem
Each Bot is one unbounded thread. Every turn reloads the full transcript (user messages, agent messages, tool dumps, screenshots, agent-to-agent pings). Obsolete traffic stays in the model context forever.
There is no same-agent “new session,” no compact, and no way for the Bot to drop dead messages from what the model sees. The documented workaround is spawn another Bot. That explodes the roster, splits memory, and does not fix the product.
Rewrite (what we are building against)
Split a Bot into Identity, Working set, Archive. Stop treating the chat log as the Bot.
The least efficient way is to reload unfilterd unnecessary expensive and timeconuming content. Its a 10x to 100x improvement, and in some cases 1000x. very surpised it isn’t there already
assemble_prompt() is only current ask + live memory + pointed files + in-working-set messages. Archive is never auto-fed back; a test fails if it leaks.
Compact marks a message obsolete: it leaves the working set immediately and stays in Archive. Triggers: user Compact, budget over cap, death. Not a cron. Not hide/delete. Not spawning a clone.
New session: same Identity, empty working set, previous thread in Archive.
Agent pings are processed then dropped; they do not accumulate. Shared files/memory are the bus.
Meter: estimated working-set tokens vs cap (chars/4), plus what was dropped. Never billed. Demo cap 8000.
UI header: Compact, New session, working-set size chip. Archive is a read-only tab.
Token estimate for this first milestone slice: ~0.3–0.7M (estimate, not a billed meter). Goal remains one CoS, weeks of work, thin working set.
Hey, thanks for the detailed breakdown. It’s clear you’ve thought deeply about the Identity, Working set, and Archive model.
A couple notes on how this works right now:
The bot’s durable state, like name, description, memory, routines, skills, connectors, and files on the shared computer, already lives separately from the chat transcript and survives a chat reset. So in your terms, Identity is already separated from the log.
Long conversations are automatically summarized as we get close to the model’s context limit.
What we don’t have yet, and this is exactly what you’re describing, is an explicit new session on the same bot with archiving, not deleting, the previous thread, a manual or agent triggered compact that marks messages as obsolete, and a visible working set token meter vs the cap. So summarization at the context window boundary isn’t the same as explicit compact or new session controls.
I’ve shared this with the team as feedback. Your breakdown with concrete primitives and success metrics is really helpful here. I can’t share a timeline for these controls yet, but if there’s an update, I’ll reply in the thread.
I primarily use crockpot on my phone and there’s definitely no way of compressing or compacting on the iPhone short of Grok creating a new bot and then archiving the old one and moving a whole bunch of settings over to it, which will probably lose something
There is also no way to use alternate models and Grok does not offer any other model except their most expensive one. I’m trying to write a fan out script from Grok Bot to my Hermes Agent and have most of the heavy lifting done. Hermes is using my open AI oath account..
Still most harness work uses grok.
Will update on success. This needless consumption of tokens is clearly self serving on cursor and grok.
Hey, thanks for adding your use case, especially the mobile client part.
In short:
Compact and new session on mobile: right now there’s no explicit control for this on either desktop or mobile. That includes compact, starting a new session while archiving the old thread, and a working set meter. Long chats do get auto-summarized as they get close to the context limit, but that’s not the same as an explicit compact or starting a new session on the same bot. We’ve already passed this exact feedback to the team from this thread.
Model selection in Grok Bot: that’s a separate request from what this thread is about. I’ll pass it on as feedback too, but I can’t share an ETA.
On token usage: this isn’t intended behavior. It’s due to how the working set is set up right now. The full transcript gets sent back to the model, and there aren’t any explicit primitives yet to cut older messages from what the model sees. This gap is exactly what the request in this thread is about, and it’s on the team’s radar. I can’t share a timeline for these controls yet, but if there’s an update, I’ll post it here.
Let me know how it goes with the fan-out script for your Hermes Agent.
Reloading the whole life of a chat on every wake is a bad design. Auto-summarize at the context limit papers over it. Summaries do not survive two years. The transcript is a log. Memory has to live in files, or the product eats itself.
Routines make it worse. Each scheduled run re-sends the conversation. A quiet watch on a fat chat still pays the whole thread.
Not asking for a new Bot, hide, or delete. Same Bot. Thin working set. Archive stays readable. Do not feed the archive back.
Hey, thanks for adding your cases, and the usage details too.
@justNick, about Grok Heavy usage shooting up. This isn’t intended behavior. The reason is how the working set is set up right now. The full transcript gets sent to the model on every turn, and there aren’t any explicit controls yet to drop older messages from what the model can see. Long chats do get auto summarized as they get close to the context limit, but that’s not the same as an explicit compact, or starting a new session on the same bot. That exact gap is what the request above is describing.
As a workaround right now, the bot’s durable state profile, memory, routines, skills, connectors, files on the shared computer lives separately from the chat and survives Reset chat. So if a thread gets too large, you can reset the chat without losing the bot’s settings. But yes, it’s destructive for the transcript itself, not a clean compact.
All of this has already been passed to the team from this thread and is on their radar. I can’t share a timeline for these controls yet, but if there’s an update, I’ll post it here.
Grok Bot token hygiene is broken for multi-bot teams.
Every turn reloads system prompt + memory + skills catalog + the full chat transcript for that Bot. On a long-lived CoS Bot we’re seeing ~200–250k input tokens per reply even when work is delegated to Cursor cloud / Grok Build. Sidebar right-click has Pin / Duplicate / Hide / Delete — no Reset chat, no Compact, no “new session on same Bot.” The only workaround is Duplicate → Hide the fat Bot, which is absurd for a whole roster (every specialist has the same tax).
This is fleet-wide inefficiency, not one noisy chat. Staff already acknowledged the gap (deanrie): full transcript every turn; auto-summarize near the limit ≠ compact; same-Bot new session with archive + working-set meter still missing.
Please ship: (1) same-Bot new session / archive without Delete, (2) manual or agent Compact that drops obsolete turns from the working set, (3) skills-on-demand instead of dumping the catalog every turn, (4) a visible working-set token meter. Until then Grok Bot weekly burn is mostly context tax, not work.
Hey, thanks for the detailed case, especially the fleet-wide angle. When every specialist in the roster has the same context tax, it feels very different than one heavy chat.
How it works today:
The bot’s durable state (profile, memory, routines, skills, connectors, files on the shared computer) is stored separately from the transcript and survives Reset chat. So you can reset the chat without losing the bot’s settings, but yes, the transcript reset is destructive, not a clean compact.
Long chats are auto-summarized as they get close to the context limit, but that’s not the same as an explicit compact or a new session on the same bot.
What we don’t have yet, and what you’re describing, is a same-bot new session that archives (instead of deletes) the old thread, a manual or agent-triggered compact that drops obsolete turns from the working set, and a visible working-set token meter vs the cap. Your point about skills-on-demand instead of dumping the whole catalog every turn is also a useful signal. It hadn’t been stated that clearly earlier in the thread, and I’ll pass it to the team too.
On token usage, what you’re seeing isn’t intended behavior. The reason is how the working set is built today. The full transcript is sent to the model on every turn, and we don’t yet have explicit primitives to cut older messages out of what the model sees. That’s exactly what this thread is asking for, and it’s on the team’s radar. I can’t share a timeline for these controls yet, but if there’s an update, I’ll reply here.
Thanks Dean — the fleet-wide angle is exactly it. When every specialist re-injects the same fat system+memory+skills+transcript each turn (~200–250k), burn scales with roster size, not with one chat being “messy.”
We had to Duplicate + Hide the CoS bot just to get a clean context, and still took a hard on-demand hit in a short window (~$175) while operating a multi-bot stack. A first-class prune/compact (without creating a new bot) would let fleets stay solvent without that workaround.
Happy to share more operational detail if useful for prioritization.
Thanks for coming back with the numbers. The fleet-wide picture around 200 to 250k per response across the specialist router, plus the on-demand spike in a short window, is exactly the kind of signal that makes the request concrete instead of abstract. And yeah, Duplicate + Hide being the only way to get a clean context is a pretty awkward workaround, I agree.
I won’t rehash the mechanics, it’s the same as in my previous reply. Durable state like profile, memory, routines, skills, connectors, and files on the shared computer lives separately from the transcript and survives Reset chat, and auto-summarization near the context limit isn’t the same as an explicit compact or a new session. What you’re describing, a same-bot new session with archiving of the old thread, manual or agent-triggered compact, skills-on-demand instead of loading the whole catalog every turn, and a visible working-set meter, isn’t there yet.
All of this is on the team’s radar, and I passed along your details. I can’t share a timeline yet, but if there’s an update, I’ll reply here.
And yeah, send over the operational detail. The more specific the burn breakdown across the multi-bot stack is, the more useful it is for prioritization. You can post it right in the thread.
We need a button, to start a new task, clear the old context, instead of creating a new copy-bot.
it is very useful to save context cost, it is helpful to save usage quota.
Alternatively, if the robot is intelligent enough to load the required context on demand, then this button may not be necessary.
Support previously said Reset chat is available from the agent info pane (chat header → Show details, or Ctrl+Shift+I on Windows), and that it clears the transcript while keeping the same Bot, memory, profile, and routines.
On Windows desktop Grok Bot 0.47.0 that control is not available:
Left-click on the Bot name in the chat header does not open an agent info pane.
Ctrl+Shift+I does not open an agent info pane.
The only Reset visible in Bot settings is next to Bot / Generate / Upload — that resets the avatar image, not the chat.
Retested with the app language set to English as well as the localized UI — same result.
Support later said it could not confirm from its side whether Reset chat exists on this exact desktop build/account, and escalated internally. That leaves customers chasing a control that may not ship in 0.47.0.
What I could do instead today is not a Reset of the same 1:1 chat. Using the sidebar + / New conversation and selecting the same Bot opened a separate group chat (named like “Bot + me”). That group started with an empty transcript. It is not the original 1:1 thread:
The original 1:1 chat is still there, with the full history.
The group does not show the Bot’s cloud computer screen.
The settings pane on the group is group settings, not the Bot profile.
I have not proved whether the model still reloads the old 1:1 transcript behind the scenes when I message the group.
So this is a workaround, not the control Support described.
Please clarify for product/support:
Does Reset chat actually exist in Grok Bot 0.47.0 on Windows for general accounts?
If yes: exact UI path + screenshot.
If no: please say so clearly, and stop directing users to a missing control.
This matches the broader request in this thread: same-Bot new session / compact without Duplicate or Delete. Long-lived coordinator Bots keep burning tokens on full transcript reload every turn.
In addition, the missing Reset (or same-Bot new session / compact) also makes those long-lived coordinator Bots slower to answer: every prompt reloads a large history, so response latency grows with the transcript, not only cost.