GitHub Copilot: 87% of LLM Calls Are Now Agent-Initiated

87% of the LLM calls behind GitHub Copilot's coding agent are not typed by a human. The agent is talking to itself.

That's the headline finding from a Microsoft research paper analyzing one week of production traffic in June 2026 — and it's a genuinely rare thing in AI coverage right now: a real usage number from inside one of the largest Copilot deployments in the world, not a benchmark score or a demo video. Most of what circulates about "AI agents" is either a lab benchmark or a vendor claim. This is telemetry from 3.2 million actual users.

The paper is Agentic Coding in the Wild: Characterizing GitHub Copilot Traces at Production Scale (arXiv 2608.00101), by Microsoft-affiliated researchers Banruo Liu, Haoran Qiu, Íñigo Goiri, Rodrigo Fonseca, Ricardo Bianchini, and Esha Choukse. It's worth reading in full if you build LLM infrastructure — but for anyone tracking the broader agent-vs-chatbot transition, the headline number matters on its own: at Microsoft's developer-tool scale, agentic, multi-step LLM usage isn't a minority pattern anymore. It's 87% of the traffic.

That complicates a thesis explainx.ai laid out earlier this month in why AI agents haven't gone mainstream — or rather, it sharpens it. Agents may not have gone mainstream with consumers. They've clearly gone mainstream somewhere else first.

TL;DR

What "Copilot agents" means here (and what it doesn't)

"Copilot" is one of the most overloaded brand names in software right now, and the ambiguity matters for reading this correctly. Microsoft ships at least three distinct products under that name: Microsoft 365 Copilot (chat and drafting inside Word, Excel, Outlook, Teams), Copilot Studio (a low-code agent builder for business workflows), and GitHub Copilot (the coding assistant, including its autonomous coding agent). This paper is about the third one — specifically GitHub Copilot's agent mode, the part that reads files, runs terminal commands, and edits code across a repo with minimal human intervention per step.

That distinction isn't pedantic. GitHub Copilot's coding agent is a fundamentally different workload from a chat assistant drafting an email: it operates in a loop, reading and writing real files and executing real commands, which is exactly the kind of task where multi-step, tool-using agent behavior is the natural shape of the work — not an optional feature layered on top. explainx.ai's earlier coverage of Nadella's ROIC Intelligence app showed the same GitHub Copilot code tools (/drill-me, autopilot, /rubber-duck) building governed enterprise assets from a single prompt — this paper is the infrastructure-level view of what happens under the hood when millions of developers run that same loop simultaneously.

What the 87% figure actually measures

The paper analyzed anonymized telemetry — no prompts, code, or user identities — from GitHub Copilot's production systems across one week in June 2026, limited to US regions. The scale is large enough to be a legitimate industry data point rather than a cherry-picked sample:

Inside that dataset, the researchers found 87% of LLM calls are agent-initiated — meaning a human sent one message, and the agent then autonomously chained further LLM calls to explore the codebase, run commands, and apply edits before returning control. The median turn contains 4.5 LLM calls and 4 tool calls, with a mean of 6.6 LLM calls per turn — and the paper notes a strict near-1:1 coupling between LLM calls and tool invocations: almost every model output triggers a tool action, and almost every tool result feeds back into the next model call.

That's the core shift the paper is documenting: for GitHub Copilot's coding agent, the dominant unit of work isn't a single request-response exchange. It's a self-extending chain of steps that the agent runs on its own initiative, with the human present at the start and end of a turn but largely absent from the middle.

Why the token math looks nothing like chat

The paper's other headline number is a stark asymmetry in how those LLM calls are shaped. The median call processes about 68,000 prompt tokens but generates only 247 completion tokens — a roughly 275:1 input-to-output ratio. Compare that to a typical single-turn chatbot exchange, where a short question produces a proportionally longer answer, and the shape of the workload looks almost inverted.

That imbalance comes from the agentic loop itself: every step re-reads large amounts of code, file content, and prior tool output as context, then produces a comparatively tiny action — a single edit, a single command, a short reasoning step. Six distinct turn archetypes emerged from the data, and they map cleanly onto what any developer using an agentic coding tool would recognize:

• Deep-loop read (30.5% of turns) — exploration-heavy file retrieval
• LLM-only (20.2%) — pure reasoning, no tool calls
• Multi-cycle edit (19%) — read-modify-build loops
• Multi-cycle other (13.2%) — read-dominant turns with minimal changes
• Deep-loop with failures (9.1%) — retry loops that amplify compute up to 4x
• Deep-loop run (8.1%) — terminal-heavy execution

The top three individual tools — get_file (35% of tool calls), run_command_in_terminal (17%), and replace_string_in_file (9.8%) — account for over 60% of all tool invocations, which tracks with a coding agent spending most of its autonomous time reading and editing rather than doing anything exotic.

Why this breaks assumptions built into LLM-serving infrastructure

The paper isn't primarily written as an adoption story — it's an infrastructure paper, arguing that serving systems designed for stateless, short chat requests are the wrong architecture for agentic coding traffic. A few of its findings explain why:

• Cache behavior is fragile across turn boundaries. Prefix cache hit rates climb from 45% on a turn's first call to 92-94% by the third or fourth call within that turn — but crossing a turn boundary with the same model drops the hit rate by 26 percentage points, and switching models collapses it to just 8%, effectively a full cache reset.
• Session length is wildly skewed. The median session runs 4.2 minutes with 15 LLM calls across three turns, but the mean reaches 62.6 minutes — a nearly 15x spread showing that long-running outlier sessions dominate total resource consumption.
• User behavior varies by 50x in token intensity. Five behavioral archetypes emerged — "Readers" (41.7% of users, 203K tokens/turn), "Coders" (30.4%, 417K tokens/turn), "Terminal users" (11%, 213K tokens/turn), "Deep-loop users" (9.2%, 1.1M tokens/turn doing large refactors), and "Chat-only users" (7.6%, 23K tokens/turn) — meaning a serving system tuned for the median user badly under-serves the heaviest 9%.
• Context compaction is destructive. It hits 7.8% of sessions, drops 72.8% of prompt tokens on average, and destroys 66.1% of cache hit rate in the process — the paper argues for prefix-preserving compaction that keeps cache continuity intact.

The researchers' recommendation is blunt: "serving systems must treat an LLM call and its tool invocation as an inter-dependent pair, not two independent requests." That's a structural claim about infrastructure, but it's also a proxy for a bigger point — at production scale, GitHub Copilot's traffic simply doesn't behave like the chat workloads most LLM-serving systems were built around.

Does this mean agents have gone mainstream after all?

This is where the finding connects back to a live debate explainx.ai has been tracking. In why AI agents haven't gone mainstream, the argument was that enterprise agent benchmarks keep climbing while ordinary consumers still mostly treat AI as a smarter search box or writing assistant — that the interface, trust, and daily-habit pieces necessary for a consumer breakout haven't landed yet. This paper doesn't contradict that. It complicates it in a useful way.

The 87% figure is real evidence that agentic, multi-step LLM usage is already dominant — but only inside a specific surface: professional software development, where the users are technical, the task (write and modify code) is naturally suited to tool-calling loops, and the product (an IDE-integrated coding agent) was purpose-built for exactly this pattern from the start. That's a very different context from a consumer opening a chat app to ask a question. The chatbot-vs-agent distinction explainx.ai's beginner's guide draws — a chatbot answers once, an agent runs a loop of plan, act, observe, adapt — is exactly the split this data makes visible at scale: GitHub Copilot's agent mode lives almost entirely on the "loop" side of that line, while most consumer AI usage still lives on the "answer once" side.

So the honest synthesis is: agents are mainstream, but concentrated — not evenly distributed. Developer tools and enterprise-integrated workflows got there first, for reasons specific to that surface (technical users, tool-native tasks, high tolerance for setup and iteration). Consumer chat apps haven't, for reasons specific to that surface (the interface, trust, and habit-formation gaps the earlier post covers in detail). Both things are true at once, and this paper is the clearest single data point yet for the first half.

What this implies for teams building AI products

If you're deciding where to invest agentic engineering effort in 2026, this data point is a useful signal, not a guarantee it'll repeat in your domain:

• Demand for agentic behavior concentrates where the task is already loop-shaped. Coding, data pipelines, and multi-step research are naturally agentic; a customer-facing chat widget usually isn't, unless you deliberately restructure the task to need it.
• Infrastructure built for chat doesn't transfer for free. The paper's cache-fragility and token-asymmetry findings are a warning for anyone assuming their existing LLM-serving stack scales cleanly into agentic workloads — session-aware scheduling and model pinning aren't optional extras once tool-calling loops dominate traffic.
• The gap between developer-tool adoption and consumer adoption is a market opportunity, not a contradiction. The same agent capability layer ecosystem that lets coding agents read files and run commands is still missing an equivalent for most consumer tasks — that's the unsolved half of the puzzle, not evidence agents failed.
• Comparable large-scale production data exists elsewhere too. Anthropic's own auto-mode rollout data — Adobe, Nuro, Gusto, and Garner Health running agentic Claude Code sessions at real production scale — is a similar signal from a competing coding agent, reinforcing that this isn't a one-vendor anomaly.

For a market comparison of the coding-agent space this data comes from, see explainx.ai's Claude Code vs. Cursor vs. GitHub Copilot breakdown, and GitHub Copilot's own multi-platform agent SDK coverage for what Microsoft has been building on top of this same agent surface.

The bottom line

Microsoft's own production data says 87% of GitHub Copilot's LLM calls are now fired by the agent, not the human — a real usage number from 761 million production calls, not a benchmark or a demo. It's specific to GitHub Copilot's coding agent, not Microsoft 365 Copilot or Copilot Studio, and it says nothing directly about consumer AI usage patterns. But as a data point about where agentic AI actually lives in production right now, it's about as strong as evidence gets: not "agents will be huge," but "agents are already the majority of traffic," measured, published, and reproducible from the paper itself.

Related reading

• Why AI Agents Haven't Gone Mainstream (Yet) — the consumer-adoption gap this data point complicates
• What Are AI Agents? A Plain-English Beginner's Guide — the chatbot-vs-agent distinction this data makes visible at scale
• Satya Nadella's ROIC Intelligence App: Copilot Skills, Fabric — GitHub Copilot's agent tools building real enterprise assets
• Claude Code Auto Mode Becomes Default for Pro, Max, Team — a comparable large-scale agent-deployment data point from a rival coding agent
• Claude Code vs. Cursor vs. GitHub Copilot — how this agent surface compares across vendors
• GitHub Copilot SDK: Multi-Platform Agents — what Microsoft is building on top of this same coding-agent surface
• Agent Reach: Give Your Agent Eyes on the Internet — the capability-layer gap still missing for most non-coding agent tasks
• Microsoft, Kimi K3, and Copilot Azure Cost Savings — Microsoft's broader Copilot infrastructure cost pressure this scale of traffic creates

Official source: Agentic Coding in the Wild: Characterizing GitHub Copilot Traces at Production Scale (arXiv 2608.00101)

This post is based on the arXiv paper "Agentic Coding in the Wild" (2608.00101), the primary source Microsoft researchers published for this data. Figures reflect one week of GitHub Copilot production telemetry from June 2026 as reported in the paper; the paper does not cover Microsoft 365 Copilot or Copilot Studio, and no separate Microsoft blog post or conference talk with additional figures was found alongside it as of this post's publication date. Numbers are accurate as published in the paper and may be revised in later paper versions.