Cut coding agent token use with better tool output

AI coding agents consume tokens even before writing a single line of code. The majority of costs come from the information the agent processes during its operations. While teams often focus on aspects like model choice, prompt length, and request limits, a less obvious factor lies in how agent interfaces with developer tools – specifically, the format of data returned to the model. This consideration can significantly impact token usage.

When a tool returns a lengthy list of records in a verbose format, the agent must repeatedly pay for the same data structure elements, which often includes redundant data such as field names, quotation marks, and structural syntax. While this data is valuable, a substantial amount of the representation is unnecessary. For workflows involving AI agents, the output format choice is a critical engineering decision, not just an aesthetic one.

Consider an issue list containing various attributes such as identifier, severity, component, line number, status, and estimated remediation effort. In conventional JSON format, each record includes these labels, resulting in repetitive information that an agent does not need for every record. Repetitive field names consume context that could be better utilized for more relevant data.

Token-Oriented Object Notation (TOON) addresses this issue by providing a schema-like header for uniform arrays, then sending each record as a separate row. This approach keeps field names only once while retaining values, resulting in a lossless encoding of the JSON data model for uniform data structures. This encoding design helps predict model behavior and reduces unnecessary context for the model.

To evaluate the impact of format choices on actual workflows, teams should measure real tool outputs and model inputs rather than relying on synthetic benchmarks. One practical approach involves capturing representative responses, running them through relevant tokenization tools, and comparing the results with default settings. For instance, using the Sonar CLI to return issue lists in JSON or TOON format can show substantial savings in character count, with TOON offering up to 49% fewer characters compared to pretty-printed JSON and 33% fewer than minified JSON for 25-issue comparisons.

The choice of output format should be based on the consumer and the data's structure. Use JSON for simple terminal scanning, standard JSON for script or deeply nested payloads, and TOON when an LLM is processing many records with the same fields. This approach ensures that the agent receives a cheaper context without compromising the decision-making quality.