Claude Code Usage Data: What 400,000 Sessions Reveal

I have written a lot of confident sentences about how to use Claude Code, all of them drawn from my own sessions. My own sessions are a sample of one, and the thing about a sample of one is that it agrees with you. So when Anthropic published an analysis of roughly 400,000 real sessions from about 235,000 people, I read it looking for the places it disagreed with me.

It disagreed in two places, and both changed what I do daily. This post pulls out the numbers that are actually actionable — the work-mode split, the decision asymmetry, how expertise changes the shape of a session rather than just its outcome, and what a year of drift in the data says about where this is going. Every figure below comes from that study.

What the dataset is, and what it cannot tell you

The study covers around 400,000 Claude Code sessions from about 235,000 people between October 2025 and April 2026, alongside the observation that the share of GitHub projects with coding-agent activity has more than doubled since late 2025 and that Claude Code users now average around twenty hours a week with the tool. That last figure is the one that reframes the rest: this is not occasional assistance, it is where a substantial part of the week goes.

It is worth being clear about the limits before quoting any of it. This is observational data about what people did, not a controlled comparison against working without the tool, so nothing here measures productivity in the economic sense. Success is judged from the session itself. What it does measure well is shape — what people ask for, how much the agent does per request, and how those things differ between people who are new to it and people who are not.

Most sessions are not writing new code

The single most common mental correction the data made for me was this: writing new code is a minority activity. About 56 percent of sessions consist of writing, fixing, or testing and orchestrating code — but writing is only 25 points of that, fixing 26, and testing and orchestration just 5. The rest of the distribution is the part people underestimate.

Where the sessions actually go:

The decision split is the finding that should change your habits

People make about 70 percent of the planning decisions and only about 20 percent of the execution decisions. That is not a complaint about autonomy — it is a description of where your attention is leveraged. Each prompt sets off a chain of around ten actions on average, and sometimes over a hundred, across a session that typically runs about four such turns.

# The number that reframes everything else in the study:
#
#   1 prompt  ->  ~10 actions by Claude, on average
#                 (sometimes over 100)
#
#   A typical session is about FOUR such turns.
#
# So a four-turn session is roughly forty tool calls you did
# not individually approve. That is why the planning decision
# is the one worth your attention: you make ~70% of those,
# and only ~20% of the execution decisions.

Read that arithmetic honestly and the conclusion is uncomfortable but useful: in an ordinary session you are personally deciding a small minority of what actually happens. Every minute spent sharpening the plan is therefore worth many minutes spent reviewing execution after the fact, which is exactly why plan mode and a written plan keep showing up in every serious workflow guide. You are not being asked to slow down for its own sake. You are being asked to spend your decisions where you still have most of them.

Expertise changes the shape of a session, not just the outcome

I expected experienced users to run tighter, shorter sessions. The opposite is true. Sessions from novices produce around five Claude actions and roughly 600 words of output; expert sessions produce twelve actions and around 3,200 words. Experts are not asking for less, they are asking for more and getting further with it.

# Session shape by expertise (verified-success sessions):
#
#   novice   :  5 actions,   ~600 words of output
#   expert   : 12 actions, ~3,200 words of output
#
# Verified success rate:
#   novice          : 15%   (partial success 77%)
#   intermediate /
#   expert          : 28-33% (partial success 91-92%)
#
# Abandonment:
#   novice   : 19% of sessions
#   expert   : 5-7%
#
# Experts do not get shorter sessions out of the tool.
# They get LONGER ones that finish.

The work moved from fixing to building over seven months

Between October 2025 and April 2026 the composition shifted in a consistent direction, and the direction says more than any single number:

• The share of sessions fixing broken code fell from 33 percent to 19 percent.
• Operating software grew from 14 percent to 21 percent.
• Writing and data analysis roughly doubled, from about 10 percent to 20 percent.

The estimated value of the average session rose by 27 percent over the same period, with building tasks up about 43 percent, operating tasks 34 percent and fixing 32 percent. A tool that started out mostly repairing things is now mostly making and running them, which matches the direction of the product itself — the last year of releases has been overwhelmingly about orchestration, permissions and running work unattended rather than about writing better functions.

It is not only software engineers, and the gap is small

Software occupations reach 30 percent verified success overall against 26 percent for other professions, and on code-producing sessions specifically the figures are 34 and 29 percent. Every one of the ten largest occupations lands within seven points of software engineers.

A four-point overall gap is much narrower than the discourse around AI coding tools would suggest, and it lines up with the 13 percent of sessions that produce analysis or prose rather than code. If you are a developer wondering why your product manager keeps sending you terminal transcripts, this is why: the tool is not staying in the engineering department.

What I changed after reading it

Four concrete habits, in the order they paid off:

1. Front-load the plan. If I own 70 percent of the planning decisions and 20 percent of the execution ones, a plan reviewed for five minutes beats a diff reviewed for twenty.
2. Track abandonment rather than satisfaction. I now notice when a session produced nothing usable, and every time it has been a scope problem rather than a prompting one.
3. Stop treating long sessions as a smell. Expert sessions are more than twice as long by output; the failure mode is a long session with no plan, not length itself.
4. Budget for operating, not just writing. A fifth of sessions are running and wiring software, so the permissions and tool access for that work deserve the same setup effort as the editing rules.

The study is most useful as a corrective to whatever your own sessions taught you. Mine had taught me that shorter is safer and that new code is the main event; the data says experts run longer sessions and that writing new code is a quarter of the work. The habit I kept from it is narrow and cheap: spend your attention on the plan, because that is the part of the session you still mostly own.