← Latest papers
🤖 machine learning

TraceLab: Characterizing Coding Agent Workloads for LLM Serving

This paper introduces TraceLab, a comprehensive dataset and analysis of over 4,300 real-world coding-agent sessions, to characterize unique workload patterns like long autonomous loops and diverse tool calls, thereby identifying specific opportunities for optimizing LLM serving systems.

Original authors: Kan Zhu, Mathew Jacob, Chenxi Ma, Yi Pan, Stephanie Wang, Arvind Krishnamurthy, Baris Kasikci

Published 2026-06-30
📖 5 min read🧠 Deep dive

Original authors: Kan Zhu, Mathew Jacob, Chenxi Ma, Yi Pan, Stephanie Wang, Arvind Krishnamurthy, Baris Kasikci

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a super-smart, tireless digital assistant (a "coding agent") that helps you write software. You ask it to fix a bug, and it doesn't just give you an answer; it goes into a room, opens files, runs tests, reads the results, and then comes back to ask you, "Should I try this other thing?" It does this loop over and over again until the job is done.

The paper TraceLab is like a giant, detailed diary of 4,300 of these work sessions. The researchers watched how these assistants actually worked in the real world (not in a test lab) to figure out how to make the computers running them faster and cheaper.

Here is what they found, explained through everyday analogies:

1. The "Long Conversation, Short Answers" Paradox

The Finding: The assistant reads a massive amount of history before it speaks, but when it finally speaks, it says very little.
The Analogy: Imagine a librarian who has to re-read the entire encyclopedia (100,000 pages) just to find one specific fact. Once they find it, they only whisper a single sentence to you.
Why it matters: Most computer systems are built to handle long speeches. But these coding agents are like librarians who read huge books but only whisper short answers. The computer spends 90% of its energy just "re-reading" the history (the context) rather than generating new text.

2. The "Memory Cache" Problem

The Finding: The system tries to save the "history" in a special, fast memory (called a prefix cache) so it doesn't have to re-read the whole book every time. It works 96% of the time, but fails when you take a long break.
The Analogy: Think of the fast memory as a sticky note on your desk. If you keep working, the note stays there. But if you go to lunch, take a nap, or go home for the night, the sticky note falls off (it gets "evicted"). When you come back, the assistant has to re-read the whole book from the library shelf instead of just looking at the sticky note.
The Cost: The paper found that about 13% of the total cost of using these agents comes from accidentally losing that sticky note and having to re-read the book because you took a human-sized break.

3. The "Tool Call" Rollercoaster

The Finding: The assistants use "tools" (like opening a file or running a command) constantly. Most tools are instant, but a few take a very long time, creating a "long tail" of delays.
The Analogy: Imagine ordering food. 90% of the time, you just ask for a glass of water (instant). But sometimes, you ask for a steak to be cooked, which takes 20 minutes. Even though the steak orders are rare, they take up almost all the kitchen's time.
The Insight: The researchers found that while the assistants use dozens of different tools, just three or four of them (like running a command or reading a file) make up 80% of the work. However, the "slow" tools (like waiting for a complex process to finish) are the ones that make the user wait the longest.

4. The "Human Pause" Bottleneck

The Finding: The actual computer work is fast, but the sessions are mostly spent waiting for the human to think, type, or read.
The Analogy: Imagine a race car driver (the AI) who can drive at 200 mph, but they are stuck in a traffic jam caused by a pedestrian (the human) who stops to tie their shoe. The car is ready to go, but it has to sit idle.
The Insight: The computer is often sitting idle, waiting for the human. The paper suggests that if the computer could "keep the seat warm" (keep the memory alive) during these long human pauses, it would save a lot of money and time.

5. The "Tool Switching" Overhead

The Finding: Every time the AI switches from "thinking" to "using a tool" and back, there is a tiny bit of wasted time and energy.
The Analogy: It's like a chef who has to walk to the fridge, grab an ingredient, walk back to the stove, cook it, walk back to the fridge, and repeat. If they could grab three ingredients at once and cook them together, they would be much more efficient.
The Suggestion: The paper suggests that instead of asking the AI to do one tiny thing at a time, we should encourage it to bundle several tool actions together to reduce the "walking back and forth."

Summary of the "TraceLab" Contribution

Before this paper, people tried to understand these coding agents using small, fake tests (like asking the AI to solve a single math problem). But real coding is a long, messy conversation with many steps.

TraceLab is the first time researchers looked at a massive, real-world log of these conversations. They discovered that to make these AI assistants better, we shouldn't just focus on making the AI "smarter." Instead, we need to build better "libraries" (memory systems) that can handle huge books, better "sticky notes" (caches) that don't fall off during lunch breaks, and better "kitchens" (tool systems) that can handle the rare, slow orders without clogging up the whole system.

The researchers released their data and tools so other engineers can use these insights to build faster, cheaper, and more efficient AI coding assistants.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →