Using Transcript Analysis to Reduce AI Agent Token Costs

What transcript analysis is, and how it differs from prompt compression

Token costs in agentic workflows don't scale the way most teams assume. The instinct is to multiply model price by usage and call it a forecast, but that math breaks down the moment an agent starts working across multiple turns, because agents re-send their entire conversation history on every step. Cost doesn't add up in this architecture. It compounds. A ten-turn task doesn't cost ten times what a one-turn task costs. It costs something closer to ten times the average turn size, with the history itself growing heavier at every step along the way.

That compounding effect is why teams get surprised by their bills even when they priced everything correctly on paper. Re-sending conversation history eats roughly half to 60% of total token spend in a typical agentic session, since the full transcript gets attached to every call. Tool descriptions add a second, fixed tax: an agent equipped with 30 or more tools tacks on 10,000 to 15,000 tokens to every request before it does anything, just to describe what it can do. File reads pile on more waste when an agent explores an unfamiliar codebase without a retrieval strategy and reads whole files looking for three relevant lines. Verbose model output makes all of it worse, since a wordy reply becomes part of the history re-sent on the next turn, and the one after that.

Cheaper models don't fix any of this; expecting them to is a mistake. Blended API pricing has fallen sharply across the industry over the past year, yet enterprises still report AI costs running past their original projections more often than not. Falling unit prices don't touch structural waste. If the architecture re-sends bloated history and over-described tool lists on every step, a cheaper model just makes the same waste cheaper per token, not smaller in volume. Fixing that means reading what the agent actually did, not adjusting what you pay for it to keep doing it.

Transcript analysis, sometimes called trajectory analysis, means reading an agent's full execution log, the sequential record of its reasoning steps, tool calls, and responses, to find where the tokens actually went. It's a diagnostic practice, and confusing it with prompt compression, which is a runtime fix, misses the point of both. Compression shrinks what gets sent right now. Transcript analysis is a post-hoc audit that tells you what to fix in the harness itself: tool descriptions, memory setup, and retry logic need attention so the next hundred runs don't repeat the same waste. One shrinks a message. The other changes the system that generates the message, and of the two, only the second one stops the problem from coming back.

The unit of analysis matters as much as the method, and most teams pick the wrong one. Under frameworks for aligning cost with utility, the trajectory is the natural unit for efficiency analysis. Costs accumulate turn by turn, but utility is best assessed at the level of the whole task rather than any individual call. Judging efficiency call by call misses cases where individually cheap calls collectively belong to a trajectory that burns much of its budget on dead ends. What you're looking at in a transcript is an ordered sequence of events, model calls, tool invocations, observations, each contributing to the overall cost of the run. Reading that sequence in order is what separates transcript analysis from eyeballing a token count at the end of a run.

What transcripts reveal when you read them systematically

Reading enough transcripts turns up the same failure patterns, and they're often invisible from the outside because the agent still gets the task done eventually. The waste hides behind a passing test suite.

One common pattern is repeated failed attempts that appear as clusters of tool calls with near-identical failure signatures, the agent cycling through variations before something clicks. A second pattern is unnecessary revision of work that's already sufficient, spending tokens to revisit something that did not need changing.

A third pattern is subtler, and arguably the most wasteful once you spot it. A third pattern involves the agent producing extended reasoning or narration instead of acting directly, so tokens go toward describing a plan rather than executing it. A fourth pattern appears as redundant verification, where the agent duplicates checks that the harness or prior steps have already completed.

None of these patterns appear in a token count summary. They only surface when someone reads the sequence of steps in order and notices the shape of the waste, which is the whole case for doing this by hand instead of trusting a dashboard.

The research foundation: what systematic trajectory studies have established

The applied case comes from AgentDiet, which applies trajectory compression to coding agents at inference time. The results: input token reduction of 39.9% to 59.7%, and final computational cost reduction of 21.1% to 35.9%, with agent performance held steady. The mechanism is compression informed by reading the trajectory first and cutting what the reading shows is safe to cut. It is not blind truncation, and it is not capping history at some arbitrary number of turns and hoping nothing important falls off the end.

Bai et al. contribute the first systematic study of token consumption patterns in agentic coding, analyzing trajectories from eight frontier LLMs on SWE-bench Verified. Part of that study asks whether models can predict their own token costs before running a task. They largely can't, and that failure matters: a model that can't estimate its own spend in advance has no internal mechanism to regulate that spend during execution. It just runs until it stops.

A separate paper, "Can your AI agent be cheaper? Investigating the effects of task specifications on token spend in agentic coding tasks," finds that for some tasks, token spend improves substantially just from writing a better task specification. Waste, in other words, can be shaped before the agent takes its first action, at the level of how the task gets described to it.

A framework for aligning cost with utility ties these threads into five stages: cost profiling, utility attribution, misalignment diagnosis, targeted adaptation, and evaluation. Utility attribution is the analytical counterpart to cost profiling, tracing which steps produced value against which steps simply burned tokens. The framework also introduces counterfactual replay, drawing on Causal Agent Replay, as a method for identifying which specific steps in a trajectory actually mattered to the outcome and which were just along for the ride.

How harness design shapes token spend before agent code runs

The harness is the scaffolding an agent operates inside: which tools it can see, how those tools get described, what extra context rides along with each observation, and how all of that gets assembled into the final prompt. None of it is neutral. Treating harness choice as an afterthought is the single most underrated decision in agent cost management, and teams that skip straight to model selection are optimizing the wrong variable. Recent work reports accuracy gaps of up to roughly sixfold across different harnesses. Harness design is a major factor in both performance and cost, arguably a bigger lever than which model you pick.

Tool inventory is the clearest example. The system prompt describes every tool available to an agent, regardless of whether that tool gets called in a given run. Crossing the 30-tool mark means that description alone can add 10,000 to 15,000 tokens to every request, a fixed cost paid on every single turn regardless of the task in front of it.

Persistence semantics create a subtler, easier-to-miss cost. When the runtime's persistence mode doesn't match what the model was trained on, the result is either an 80% rate of missing-variable errors or up to 3.5× token overhead as the agent compensates for the mismatch. Persistence is a semantic the model learned during training, and getting it wrong costs tokens in one direction or correctness in the other. There's no third option where the mismatch goes unnoticed and unpriced.

Running transcript analysis in practice

The audit object is the trajectory, not any single prompt. Pull the full execution log for a representative sample of runs, and look for patterns that repeat across runs rather than fixating on any one run as the interesting case.

Steps with high token cost but no observable change in state are the clearest waste candidates: tokens spent producing nothing that moved the task forward. Repeated tool calls with identical or near-identical inputs point to retry loops the harness should be cutting off earlier than it currently does. How many memory entries get injected per call, and what fraction of those are actually relevant to the task at hand, deserves a direct check rather than an assumption that the retrieval logic is doing its job. Tool call frequency by name shows which tools appear in every run regardless of task type, marking them as candidates either for removal or for conditional exposure instead of blanket inclusion.

Comparing across harnesses used to mean writing a custom parser for each one, tooling debt that keeps teams from running this analysis. A trajectory library that normalizes native session transcripts from 15 or more harnesses, including Claude Code, Codex, Cursor, and OpenCode, makes it possible to compare runs across different agent environments on equal footing, without rebuilding a parser every time the team switches tools.

Agent memory doesn't have to be built from scratch either, which solves a cold-start problem most teams don't realize they have. Some tooling takes a similarly lightweight approach, indexing session traces already on disk and making them retrievable without building a new pipeline. Transcript reuse, in other words, can run on artifacts that already exist on the filesystem.

The reduction toolkit that transcript findings unlock

None of the tools below work without the diagnosis behind them, and that ordering isn't optional. Applied blind, compression can cut something the agent needed just as easily as something it didn't. Applied after transcript analysis has shown where the actual waste sits, the same tool turns into a targeted fix instead of a gamble.

Context compression is the first lever, and it works best applied at the checkpoints transcript analysis identifies rather than on a fixed schedule. Headroom offers a drop-in compression layer for tool outputs, files, and conversation history, cutting 60 to 95% of tokens while keeping the compression reversible. Claude Code's /compact command summarizes and replaces conversation history with a condensed version to free up context window space, and it earns its keep when the transcript has already shown where a session's complexity genuinely peaked. Running a fast, cheap model over verbose tool outputs to compress them semantically typically cuts 70 to 90% of tokens from those outputs. AgentDiet's trajectory compression, the 39.9% to 59.7% input token reduction cited earlier, still stands as the clearest benchmark for what compression informed by actually reading the trajectory can achieve.

Memory architecture is the second lever, and transcripts matter here because they show which stored memory entries never get used. Moving from naive full-context injection to retrieval-based memory cuts per-call injection from 594 tokens down to around 166 tokens on a 24-entry store, roughly a fourfold drop just from retrieving what's relevant instead of injecting everything indiscriminately.

Output compression is the third lever, and it's the one teams underrate most, aimed at the verbose replies that transcripts show inflating every downstream step once they enter the history. The Caveman skill for Claude Code rewrites verbose agent responses into terse output and reports a 65% average reduction in output tokens. Since that output becomes part of what gets re-sent on the next turn, cutting it there has a multiplying effect forward through the rest of the session, not a one-time saving confined to the turn where it happens. Of the three levers, this is the one teams skip most often, and the one the transcript makes hardest to ignore once you've actually read it.