The error message is the most honestbill you will get for your AI tooling

Cheap, instant AI made me a sloppy engineer, and it took one Sunday with a slow one to see it. If your team pays a flat monthly rate for an AI coding tool, you have probably never seen what that tool sends before your first word arrives. I had not either. Here is how I found out, what it cost, and the two things you can do this week to see your own number.

I planned to say hello to a model on my own laptop

On Sunday morning, 2026-09-13, I installed Qwen3.8-27B in LM Studio on my MacBook Pro. It is a 15 GB model on a machine with 36 GB of RAM. I wired it into OpenCode, an open-source coding assistant that can point at a local model, and typed "hi".

I got an error: the prompt was larger than the context window.

Not my prompt. The tool's. OpenCode had loaded roughly 1,500 skills and the tool definitions for 16 MCP servers ahead of my two letters, because that is what I had installed over the past months and never removed. OpenCode discovers skills from six folders, including the ones other tools on my machine also read, so a year of "sure, install that" had quietly compounded into one very large system prompt. The model can hold 262,144 tokens. My Mac could only afford 61,696 of them, and a known LM Studio bug in its Apple-silicon runtime kept the context there no matter what I set.

What the slow afternoon did and did not prove

So I stripped everything. No skills, no MCPs. Then "hey" took more than five minutes and the tool timed out before the model finished. The log showed the model was still reading the prompt: ingestion crawled from 4 percent to 73 percent, OpenCode gave up at 11:34:13, and LM Studio finished three seconds later, talking to nobody.

I want to be careful about what that proves, because it was not the skills anymore. The model shipped with thinking on and reasoning effort at its highest setting. A 15 GB model plus its working memory had my 36 GB machine swapping. And once it finally built me a to-do app, every follow-up came back as "hey, what's up?", and a new session looped on git status for two hours. OpenCode's own session counter put that loop at 7 million input tokens.

Those are three separate problems and I have fixed one of them. By evening a greeting worked. It still took minutes.

I am spelling that out because the tempting version of this story blames the whole afternoon on bloat, and it would be wrong. The bloat cost me exactly one error message. Everything after that was a default reasoning setting, a memory ceiling, and a tool-calling bug. If you run a local model and it is slow, check those three before you blame your prompt.

The bill for my baggage was the first error message, not the stopwatch

I knew a coding harness sends a system prompt. I had never once counted it.

On a cloud model with a million tokens of context, the cost of carrying 1,500 skills I do not use never shows up anywhere I look. The harness caches the system prompt so it is not re-read on every turn, and the plan is flat rate, so no line item ever arrives. A 27B model on a laptop refused to start until I put them down. None of that was a decision. It was what happens when nothing pushes back.

For a business this is the whole point. The AI tools your team uses are designed to make context feel free. That is a good product decision and a bad accounting one. When a cost is invisible, it grows until something with a hard limit refuses it. On my laptop that was a 61,696-token window. On your team it will be the day you move a workflow to a cheaper model, a stricter vendor, or a machine you control for data reasons, and discover the workflow never fit in the first place.

Two ways to see your own baggage this week

First, if your team uses Claude Code, type /context in a session. It shows how many tokens your system prompt, tool definitions, skill descriptions and memory files take before you say a word, broken out by category. Two notes so you read it correctly. Current versions load only skill descriptions and defer most tool schemas, so your number will be much smaller than my OpenCode disaster. And the number is a cost you are paying whether or not a bill shows it, because it is context the model has to hold instead of your code.

Second, do what I did and point your coding tool at a model on your own machine for an afternoon. You do not need it to work well. You need it to refuse. A slow model with a hard context limit is the most honest bill you will ever get for what your tooling is sending on your behalf.

What I am doing differently

I am keeping both. The local model stays until I get it working, and the cloud models get a more careful driver. Only the skills I call. Eyes on the context meter. Patience when a model is slow, because I now know what it is chewing through.

For the record, the tally on my machine after the cleanup: 138 skills in the folder my main tool reads, and 22 MCP servers configured, most of which I do not use. That second number is the next thing I trim.

What did a slow tool teach you that a fast one had been hiding?