Nearly everything the agent reads or writes consumes tokens:
Standing text: system and project instructions, and the tool definitions.
The conversation: your messages, earlier replies, and any summaries.
What the agent reads: source files, search results, and documentation.
What tools return: command output, error logs, and diffs.
Repeated content can be charged and processed again unless caching applies. Large test logs, generated files and broad searches fill the window fast without adding much value. Ask for focused output, open only the relevant file sections, and filter noisy command results.
Keep standing rules lean, because they appear in many requests. When a task changes direction, start a fresh session instead of carrying unrelated history. Watching tokens saves money, and it also keeps the model's attention on the evidence that matters.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
A test run prints thousands of lines. How do you keep that from flooding the context?Run only the failing tests, filter output down to errors and the first failure, or have a subagent read the log and return a short summary.
Pretty much everything the agent reads or writes costs tokens, not just the messages I type.
Every request carries standing text, meaning the system prompt, the project instructions and the definitions of every tool the agent can use.
Then there's the conversation, so my messages, earlier replies and any summaries, plus everything the agent reads, like source files, search results and docs.
Tool results count too. Command output, error logs and diffs all land in the window, and a full test log or a broad search fills it fast without adding much.
Repeated content gets charged and processed again unless caching applies, so I keep standing rules lean and ask for focused output, like filtered logs or one file section.
When the task changes direction I start a fresh session, because old history costs money and pulls the model's attention away from the evidence that matters.
Weak answers to avoid
Says only the prompts and replies countIt leaves out the standing text and everything tools return. Name the rules files, tool definitions, file reads and command output too.
Treats it as a billing issue onlyCost is only one of the two reasons. Noisy context also pulls the model's attention off the evidence that matters. Say both, then give one way you trim.
Forgets that standing text repeats every requestInstructions and tool definitions go out with each call, so a bloated rules file costs you on every turn. Mention that caching only offsets part of that.
Lists sources but no way to cut themKnowing what fills the window only helps with a fix. Name concrete moves, like filtering logs, opening file sections and starting fresh when the task changes.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
