Token waste is context bloat

People run out of Grok Bot usage and blame the model. That is usually the wrong diagnosis.

Morgan Linton (@morganlinton) is running twelve Grok Bots and wrote the cleanest field note we have seen on why the meter moves so fast.
Thread: https://x.com/morganlinton/status/2094413837290369028

His line, kept exact:

Token waste on Grok Bots is almost never the model. It's context bloat.

A mega bot that tracks every sport you play, polls every Slack channel, and scrapes sites with screenshots will reload a pile of leftover context on every turn. You pay for that pile even when the question is small.

Split the job

Counter-intuitive, and the first fix: you need more bots, not one smarter blob.

Split work into the smallest job that still makes sense. Morgan's example: not an exercise tracker. A Running Coach. It only tracks running. When you message it, it does not drag last week's paddle session into the room.

One job. One chat. One memory. That is how you stop paying for work the bot is not doing.

Write the job in the profile

Do not let the bot interview you for twenty turns. That is the same mistake as a vague spec in agentic coding. You spend tokens answering questions you could have written down in five minutes.

Name the job. Write what it does, what it does not do, and what it should dispatch. Then talk to it at a high level. Keep the main thread short so the bot stays available.

Dispatch the heavy work

A ten-minute job does not belong in the chat you still want to use.

For bigger work, send a self-contained brief to a background worker. Repo work goes to a cloud agent. Those run in parallel and report back. You keep talking.

You do not click make a worker. You write the bot so it dispatches instead of stuffing the whole job into its own context.

Cloud agents already have the code. Do not clone the repo and grep it again from the chat. That doubles the work and the tokens.

Connectors, not screenshots

If the bot is gathering data, it should use a connector. Screenshots are for showing the bot something. They are not how the bot should read a site page by page.

Put that in the profile. Avoid screenshot scraping at all costs. It burns usage for a worse answer.

Teach it once

If you find yourself telling the bot the same procedure a second time, that procedure is a skill. Write it down. Point at it. Do not re-teach it in chat.

Routines are the cost center

A routine runs without you asking. If you let the bot pick how often, you can empty a day's usage on nothing.

Audit every unattended loop.

• Prefer an event listener over polling. Fire when a Slack mention happens or a ticket changes. Do not ask every hour if anything happened.
• Scope tight. One Slack channel. One repo. One pull request. Listening on everything is polling with extra steps.
• Run as rarely as the job allows. Daily is the default. Hourly only if you can name the reason.
• Keep routine prompts short. Point at a skill. Tell the bot to stay quiet when there is nothing to share. A bot that says no updates still spends tokens.

Use a routine only when it can act, and only to fetch what it needs. Otherwise keep quiet.

Specialist plus dispatcher

Context is not infinite. As a chat grows, the bot will forget earlier detail. It is not getting dumber. The window is just full.

The pattern that scales is a dispatcher that routes, plus specialists that each hold one job. That is the same shop rule as one project, one channel. The main bot does not carry every desk's memory.

Copy-paste profile rules

Paste this into the bot profile after you have named the job in one sentence. Edit the job line. Do not paste secrets.

Job: <ONE SENTENCE>. Do only this job. Do not carry context from other jobs.

Keep this chat short and high level. If a task will take more than a couple of minutes or needs a repo, dispatch a self-contained brief to a background worker or cloud agent and report back. Do not do heavy work in this thread.

Cloud agents already have the code. Do not clone or grep a repo this chat already connected.

Use connectors for data. Never gather site data by taking screenshots page by page. Screenshots are only for showing me something.

If I teach a procedure twice, turn it into a skill and point at the skill next time. Do not re-interview me for a spec I already wrote.

Routines: prefer event listeners over polling. Scope to one channel, one repo, or one ticket. Default cadence is daily. Stay silent when there is nothing to act on. Do not send no updates.

Do not invent extra jobs, extra routines, or extra monitors.

A first week that will not empty the meter

• List the mega bot's jobs on paper. Split each job onto its own bot. Write the job in the profile. Delete the blob.
• Turn any second-time instruction into a skill. Point the profile at it.
• Kill hourly routines you cannot defend. Switch the rest to an event or to once a day.
• Scope every listener to one channel, one repo, or one queue.
• Replace one screenshot scrape with a connector. If there is no connector, fetch less, not more pages.
• Send one fat task as a brief to a worker. Keep the main chat free.

Why this belongs here

A setup is not a longer prompt. It is a smaller job, a written profile, a dispatch rule, and a quiet routine.

Morgan's thread is operating instructions. Split the bot. Write the job. Dispatch the heavy work. Listen instead of poll. Stay quiet when nothing changed.

Original thread: https://x.com/morganlinton/status/2094413837290369028