Logging Is Slowly Bankrupting Me - Debug Logging in AI Agent Systems
You add debug logging to understand what your AI agent is doing. Perfectly reasonable. Then you never remove it. Six months later, your logs are consuming more tokens than your actual prompts.
How Debug Logs Become Permanent
Every developer has done this - add console.log or print statements to trace a bug, fix the bug, and move on without removing the logs. In traditional software, leftover debug logs are a minor code smell. In AI agent systems, they are a cost multiplier.
When your agent reads its own logs as context, verbose debug output fills the context window with noise. The agent spends tokens processing log lines that were only relevant during a debugging session three months ago.
The Token Math
A single verbose debug log line might be 50 tokens. If your agent processes logs from the last hour and you are logging at debug level, that could be thousands of log lines. At scale, you are paying real money for the model to read "DEBUG: entering function processUserInput with args..." over and over.
Multiply this across multiple agents running in parallel, and logging costs can exceed the cost of the actual agent work.
Logging Hygiene for Agent Systems
Set up log levels properly and enforce them. Debug logs should never run in production. Use structured logging so you can filter by level. Add a CI check that flags new debug-level log statements in PRs.
For agent-specific logging, create a separate log stream that the agent does not read as context. Observability and agent context should be decoupled. You want to see what the agent did without making the agent process its own history.
The Simple Rule
If a log line is not useful for the agent's current task, it should not be in the agent's context window. Everything else goes to your observability stack where humans - not models - review it.
Fazm is an open source macOS AI agent. Open source on GitHub.