The 183k-Token Mistake I Made Because the Agent Lacked Context

TL;DR

I gave an AI coding agent a small static website task, but I did not set clear limits on document reading, skill use, or testing. The session grew to roughly 183k active-context tokens because the agent processed too much source material, loaded extra guidance, and installed Playwright and Chromium for browser testing.

The lesson is simple: tell the agent what is in scope, which tools it should avoid, and what level of validation is enough. Otherwise, it will use its defaults, and those defaults may be more expensive than the task requires.

---

I made a costly context mistake while building a small static website with an AI coding agent.

Recently, I asked an AI coding agent to turn a document about AI infrastructure into a modern static presentation. I wanted it to explain the options, show the decision guidance clearly, and look good.

By the end of the work, the session context showed roughly 183k tokens. That was far more than I expected for this kind of task.

The final website was not a large production system. It did not have a database, authentication, payments, or a complicated backend. It was a static site built from an existing document.

The mistake was not that the agent did bad work. The mistake was that I did not give it enough boundaries. I explained what I wanted to build, but I did not say how much of the document it should read, which tools it should avoid, or how much testing was enough. The agent filled in those missing details using its defaults.

That is what AI agents do. When the prompt is incomplete, they make reasonable assumptions. Those assumptions can still cost more time and tokens than the task needs.

The task was deliberately limited

The source was an approximately 46-page PDF about AI infrastructure. The work itself was simple:

• read the relevant infrastructure content
• create a modern frontend presentation or static website
• present the decision guidance visually

The site had a few useful parts, but it was still a modest project:

Complexity	What was built
Easy	Static layout, navigation, homepage content, and a comparison page
Medium	An options accordion, decision-wizard scoring, and a GPU/VRAM calculator with synced inputs
Hard / most costly	Processing the source PDF, then installing browser tooling and debugging browser-based verification

The medium-complexity pieces took some effort. That was expected. The problem was that the most expensive part of the session was not building the site. It was reading too much, loading extra instructions, and testing more than the task required.

What the 183k number actually means

Here is the relevant part of the session's /context output, trimmed to the information that matters:

/context

Context Usage
  183.1k / 967k tokens (19%)

Estimated usage by category
  System prompt: 9.1k tokens
  System tools: 22.6k tokens
  Memory files: 4.4k tokens
  Skills: 3.4k tokens
  Messages: 140.5k tokens

This is an active-context snapshot, not a billing record. It does not mean exactly 183,100 tokens were billed. It also does not tell me the exact dollar cost. Coding tools can cache context, and the total usage can differ from what is visible in one session.

Still, it showed a real problem. A small task had collected a very large amount of working context. Every extra file read, tool result, and debugging step made the session heavier.

Where the extra context came from

There was no single bad command. A few small decisions added up.

The full document was treated as the starting point

The PDF was around 46 pages. The site only needed the sections that helped a reader compare AI infrastructure options. It did not need every sizing table, supporting detail, or appendix.

I did not tell the agent which pages mattered. So it read more of the document than the website needed. It was trying not to miss anything. That is understandable, but it was unnecessary for this task.

A heavyweight skill added its own context

The session also loaded a full application or UI-development skill. Skills can be useful. They bring patterns, instructions, and checks that help with larger work.

This was not larger work. It was a small static presentation. The extra skill context was not needed, and it added weight to the session.

Browser verification went beyond the risk

The clearest example was browser testing. The agent installed Playwright and downloaded Chromium to validate the UI in a browser. The check then ran into a development-server HMR websocket issue because it waited for networkidle. That created a second piece of work: debugging the test setup.

Browser testing is useful when the task depends on user interaction, responsive behaviour, or visual detail that must be checked in a browser. This site did not need that level of testing. A successful build and a targeted content or HTTP check would have been enough.

Broader defaults filled in what I did not say

The agent had a general instruction to verify UI changes in a browser. I had not said that Playwright was out of scope. I had not said that it should not download a browser. I had also not said that lightweight validation was enough.

So it followed the broader instruction.

That is the main lesson. AI agents do not leave missing instructions blank. They fill them with defaults, earlier context, and extra caution. The result may be technically correct, but it can still be unnecessary.

The prompt I should have used

I did not need a complicated prompt. I only needed to be clear about the boundaries.

Use only the AI infrastructure sections relevant to selecting an option.
Do not process unrelated pages or appendices unless a required fact is missing.

Build a static presentation/site that communicates the decision guidance.
Do not invoke a full application-development or UI skill.
Do not install Playwright or download a browser.

Perform lightweight validation only: production build, typecheck/lint if available,
and a targeted content or HTTP check. Do not add tools or validation beyond the
requested output without asking first.

This does not tell the agent to skip quality checks. It tells the agent which checks are enough for the job. That is an important difference.

Use a verification tier, not a blanket rule

The right level of testing depends on the change and the risk.

Task risk	Sufficient default verification	Escalate when
Static or low-risk content	Build, typecheck or lint, and a targeted content or HTTP check	The page has important client-side behaviour or a visual requirement that needs a browser
Interactive UI	Targeted browser checks for the changed interaction and viewport	The flow includes authentication, payment, data changes, or critical accessibility work
Stateful, security-sensitive, or production-critical systems	End-to-end tests, integration checks, and human review	The change affects permissions, money, personal data, infrastructure, or a high-risk operation

The goal is not to avoid testing. The goal is to match the test to the risk. A browser test for every small static change is usually not the best use of time or tokens.

A pre-flight checklist for AI work

Before I give a task to an AI coding agent, I now try to answer these questions in the request:

• What exact source material is in scope, and what should be skipped?
• Is the desired result static, interactive, or stateful?
• Which tools are permitted, and which tools are explicitly unnecessary?
• What is the cheapest check that proves the requested result works?
• When should the agent stop and ask before expanding scope?
• Which instructions are stable enough to live in the repository rather than being repeated in chat?

The last point matters most in long-running work. Put stable instructions in the repository. Keep a short handoff note for current work. Do not depend on one large conversation to remember everything. I explain this further in How to Avoid Context Burnout in AI Coding Workflows.

The lesson was not “use less AI”

The lesson was to give the agent better boundaries.

The agent did what I allowed it to do. It read broadly, loaded more guidance, and tested thoroughly. Each choice made sense by itself. Together, they created a much bigger process than the final website needed.

I still want AI agents to be careful. I want the build checked. I want claims to come from the source material. I want risky interactions tested properly. But I now state the testing level and tool limits in the same request as the feature work.

Context engineering is not about writing the shortest possible prompt. It is about making the important decisions before the agent starts. For related examples, see One Line That Saved Me 20,000 Tokens in Claude and How to Reduce AI Coding Tool Costs with Better Prompting and Context Engineering.

My rule now is simple: if the task is small, say what a small and sufficient check looks like. If a skill, a tool, or a browser download is not needed to prove the result, it should not quietly become part of the work.