The Challenge
If your team uses AI coding agents, you might be overlooking a hidden cost: the data formats your tools output. When you send Sonar CLI results to an LLM for code analysis, you're paying for every character, not just the agent's responses. This includes all security findings, stack traces, and metadata fields.
The issue isn't the number of problems but how they're packaged. Pretty-printed JSON is great for human debugging, but when you feed 25 security findings into Claude or GPT-4, all that extra formatting adds up. Your token meter runs as the agent parses formatting meant for human readability.
Token costs depend on both what coding agents read and how development tools package that information. If you're running security scans in CI/CD and sending results through AI for triage or remediation, you're compounding inefficiency with each pipeline run.
The Environment and Constraints
The Sonar CLI team needed to maintain full data fidelity. Security findings include nested structures like issue location, severity metadata, rule identifiers, and code snippets. Stripping fields to save tokens would lose the context an AI agent needs for useful recommendations.
They also couldn't disrupt existing integrations. Teams already parse Sonar output in various formats, so any optimization had to be additive, not a breaking change that forces migration.
The goal was clear: reduce token consumption without sacrificing decision-making quality. The agent still needs to know which file, line, and rule triggered the alert, along with severity context and enough surrounding code to suggest fixes.
The Approach Taken
The team developed Token-Oriented Object Notation (TOON), a format tailored for LLM consumption rather than human reading. TOON optimizes for token efficiency while preserving semantic completeness.
TOON removes structural overhead. While JSON repeats field names for every object in an array, TOON uses positional notation. It minimizes delimiters, assuming the consumer (an LLM) needs a parseable structure, not visual hierarchy.
This implementation didn't require rewriting Sonar's analysis engine. They added TOON as an output format option alongside existing JSON and XML outputs. Teams can choose TOON when routing to AI agents while keeping human-readable formats for direct inspection.
Results and Metrics
In a 25-issue comparison, TOON used 49% fewer characters than pretty-printed JSON and 33% fewer than minified JSON. This isn't a marginal optimization. If you're processing 100 security scans per day through an AI agent at $0.01 per 1,000 tokens, you can achieve significant monthly savings that scale with your CI/CD volume.
The reduction compounds with round-trip conversations. If your agent asks clarifying questions about a finding, the entire context is resent with each exchange. A 33% reduction in baseline payload means 33% less cost per turn in a multi-turn analysis.
Importantly, the format maintained full semantic content. The agent still received issue type, location, severity, and code context. The team didn't achieve efficiency by dropping data; they achieved it by removing redundant structure.
What They Would Do Differently
The Sonar team's approach focused on a single tool's output. If you're building similar optimizations, consider standardizing across your toolchain. Security scanners, linters, and test frameworks all produce structured output that gets piped to AI agents. A shared format reduces the integration burden.
You'd also want telemetry from the start. Track token consumption per format in production before rolling out changes. Measure not just character count but actual token usage, since tokenization varies by model. What saves 33% in characters might save 28% or 37% in tokens depending on the LLM's tokenizer.
Consider the full lifecycle. TOON optimizes for consumption, but if your workflow includes storing results for later retrieval, you need to balance token efficiency against query performance. A format optimized for streaming might perform poorly for random access.
Takeaways for Your Team
Start by auditing what your tools output and where that output goes. If you're routing security scan results, dependency reports, or log analysis through AI agents, you're paying for format overhead. Run a character count comparison between your current format and a minified version. That gap represents your optimization headroom.
Measure token costs, not just API costs. Your cloud bill shows you're spending $X on AI services, but it doesn't show you that 40% of those tokens are whitespace and repeated field names. Instrument your agent calls to capture input token counts by source.
Don't optimize prematurely, but don't ignore the problem until it's expensive. If you're in the proof-of-concept phase with AI coding agents, use whatever format your tools provide. Once you're running hundreds of scans per day through AI triage, format efficiency becomes a line item worth addressing.
Test decision quality, not just cost. The point of using AI agents is better outcomes, whether that's faster triage, more accurate severity assessment, or suggested fixes. If your optimized format degrades the agent's recommendations, you've traded dollars for value. Run A/B tests with sample findings in both formats and compare the agent's output quality.
Consider format as part of your tool selection criteria. When you're evaluating security scanners or analysis tools, ask whether they support token-efficient output formats. A tool that saves you 30 minutes of manual review but costs twice as much in token overhead might not be the win it appears.
The broader principle: AI coding agents don't just change how you write code. They change how you should think about data interchange formats. Optimizing for human readability made sense when humans were the primary consumers. When machines parse your output thousands of times per day, efficiency becomes a first-class concern.
