The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

One of the comments I hear often lately boils down to “LLMs may be good at coding, but software was never the hard part” and “coding is easy, it's figuring out what to code that's hard”.

I believe that's a gross insult to all programmers everywhere.

If coding is easy...

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?

If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?

If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?

If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?

If coding is easy, why is software so damn buggy?

If figuring out what to build is the hard part...

If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?

If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?

If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!

If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

Another cliché comment is “most work in software development is talking to stakeholders, understanding the customer's needs, and having clarity on the priorities”.

I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”.

Some software developers do say “I don't write code, I solve customer's problems”. But then they turn around and start to opine on monads, memory safety, and DRY principles, while their understanding of the customer is a made-up “user persona”, and they think “affordance” is the money your parents used to give you on weekends so you could go out and have a good time.

Yet others will say “Software development is theory building”. Programs are actually proofs (as in, mathematical proofs). Every commit should tell a story. And solving a customer's problem by FTPing a PHP file is a cardinal sin.

I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho. (post-scriptum edit: this sentence was way overboard; I meant it as tongue-in-cheek “very few people can do that” and I do actually advocate for that in the next section. mea culpa)

What is important?

I do believe that talking to users, understanding their experience, empathizing with them, solving customers' problems and having all the stakeholders on the same page is critical to the success of a software project.

I also believe that creating good code is a craft that requires skill, patience, attention to detail, experience and wisdom, and that it will continue to be relevant in the times ahead.

¿Por qué no los dos?

To the extent that we can pull it off, I think we should aim for both. A deep understanding of the system we're building, together with a deep understanding of why we're building it.

Loudly proclaiming that “code is easy” or, at the opposite end, “code is art, a creative human expression that cannot be automated”, is just burying our heads in the sand.

It's cope. And you don't want cope, you want to thrive.

By this, I don't mean “jump on the LLM bandwagon.” I don't mean “become a manager of fleets of AI agents.” I also don't mean “AI-generated code is stolen slop garbage, fight it with tooth and nail, the bubble will pop soon enough anyways.”

But do recognize we're in the middle of an industry-wide tectonic change. We need to figure out how to adapt. We need to understand what is likely to change and what never changes.

What doesn't change?

Software will be getting more complex. Software will always need maintenance: bit-rot is a fact of life. So is entropy. Technology (hardware and software) will move forward, for better or worse. The tower (skyscraper?) of abstractions grows ever higher.

Users will always want more and be prepared to spend less. They still won't know how to relay their needs and wants. Worse, they still won't know exactly what they want. The disconnect between the customers (who actually pay for the software) and users (who use it) will still be here, as will the tension between the needs of the business and the needs of its customers.

Also: there will never be a shortage of snake oil salesmen. Tech du jour comes and goes (I'm still waiting for the new VR renaissance!)

What changes?

Programmers have been in the business of disrupting our own industry since the beginning. Nobody uses punch-cards any more. Very few people need to code in assembly, or COBOL. Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript.

I'm old enough to appreciate valgrind or remember mysql_real_escape_string() from the PHP4 era—stuff I'll never again need in my life. And that wasn't even so long ago! I narrowly missed the dBase, Clipper, HyperCard and Access era, technologies which I can still spot operating in shops, cafes, or a dusty, once beige and now golden-brown, midi-tower still happily running some bespoke biz solution (backups? what backups?)

How do we thrive?

Accept that change happens. Be equal parts curious and critical about the new stuff.

Understand there's a lot of hype and try to discriminate between hot air and what really works (and to what extent). Also be aware of ever-shifting goalposts: stand back and look at the past year, or five, and assess the velocity of change (technical, economic, societal).

Your role and your responsibilities will be changing. Be willing to invest time and energy into better understanding fields or roles adjacent to yours.

If you're a senior developer, don't just find solace in deepening your expertise. Learn about user experience, customer interviews, or business strategies for the companies in your domain. It will help you gain a better appreciation of all the work done to put a piece of software into users' hands, whether or not you'll actually ever have to do any of those other bits.

If you're just starting or are junior in your role: invest in deepening your understanding of how software works. Understanding pointers, recursion, or memory hierarchy will help you even if you're a JavaScript developer. Understanding network protocols and how HTTP works will be useful even if you're building WordPress plugins. Do leetcode and learn about algorithms and data structures even if you don't need to. Don't be afraid to ask why and how exactly.

For inspiration, here are a few books and other resources that might be helpful:

• Structure and Interpretation of Computer Programs (PDF)
• Cracking the Coding Interview
• The Mythical Man-Month
• Working Backwards
• Team Topologies
• 7 Powers
• The Soul of a New Machine
• Obviously Awesome
• The Design of Everyday Things
• Don't Make Me Think
• Continuous Discovery Habits
• The Mom Test

One more thing

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.

PS. Lots of interesting and insightful comments over at Hacker News and Lobsters—the post really hit a nerve. Fascinating how many different experiences people have and the varying definitions of coding, programming, development and engineering they use.

Back to Articles

In the AI world, time feels compressed. A few months after our spring report in our biannual analysis worked through the ecosystem, there are quite a few findings that we have observed until this summer. This report lays out these observations from January to August 2026 and presents the data behind each one.

Models and datasets on HF hub are growing on a daily basis. Public model repositories grew from 2.43 to 2.96 million over the period, datasets from 711,000 to 1 million, Spaces from 1.00 to 1.44 million. The distribution underneath stays extreme, roughly 85.6% of models have fewer than 200 lifetime downloads, and 1.5% of repositories account for 99.2% of all downloads. Everything below happens inside that shape.

1. The frontier is moving fast

There used to be a clear progression path: labs would start by releasing smaller models and gradually work their way toward the top end of the scale. In 2026, several Chinese labs skipped this progression entirely.

In almost every month of 2026, the largest and most performant open model from a Chinese lab was larger than any model an American lab released. China's monthly ceiling ran between 754B and 2.78 trillion parameters; U.S. models stayed under 130B in five of seven months, the exception being NVIDIA's Nemotron 3 Ultra at 561B in May and June, and Inkling from Thinking Machines Lab.

The chart splits the labs into two camps. Moonshot, MiniMax, Xiaomi and Z.ai publish almost nothing below 70B, so a developer's first encounter with them is a model too large to run on anything they own. Tencent and Alibaba Qwen cover the whole range instead, from under 1B upward.

Two things made the first camp possible. Building large stopped being a differentiator. Xiaomi, Ant Group and Meituan both cleared a trillion parameters this year, and neither was a household name in open weights twelve months ago. And a lab no longer has to ship a small model to be reachable, because the community's quantization layer will make a large one runnable within days, a dependency we return to below.

That leaves the size profile as a statement of intent rather than of capability. A frontier only portfolio stakes everything on benchmark position and API demand. A full spectrum portfolio is a bid to be the family developers standardise on. Both are rational, they are playing for different prizes.

The United States is not absent from open source.

The two organizations publishing the most new open models this year are also the companies making the hardware: AMD and NVIDIA. Each released more than 200 new model repositories, far ahead of the rest of the field, with LiquidAI ranking third at around 100. Hardware vendors have realized that open models are a way to sell chips: a model optimized for your hardware and freely available is the clearest proof that the hardware works.

When smaller models and embedding models are included, where Google, Microsoft, IBM Granite, and OpenAI’s older vision and speech models generate hundreds of millions of downloads annually, U.S. open source AI is growing.

More hardware and infrastructure organizations such as NVIDIA are training and open-weighting competitive models. NVIDIA's Nemotron model family boasts high performance. Long-time leaders such as Meta reignite open roots with Meta's Muse Glimmer.

At the frontier scale, some U.S. model releases above 100B parameters this year are built on top of Chinese models or leverage artifacts from Chinese labs, such as Thinking Machines’ Inkling (952B). Major original American models include NVIDIA’s Nemotron 3 Ultra (561B), Nemotron 3 Super (124B), and Arcee AI’s Trinity-Large (399B).

AMD contributed many conversions. This work is important: it enables trillion-parameter models to run efficiently on U.S. hardware. This represents a distribution and optimization layer.

Meanwhile, Chinese open models are increasingly optimized for domestic chips in China, the same competition in reverse, where models are designed around specific hardware ecosystems.

2. Attention ≠ Adoption

We took the top 25 model repositories by downloads accumulated this year and the top 25 by likes. Exactly one repository appears in both lists.

We counted downloads inside the window rather than lifetime, so nothing is credited for merely having existed longer, and controlling for age makes the split sharper. Not one model published in 2026 reaches the download top 25, while thirteen of the twenty-five date from 2022. all-MiniLM-L6-v2 was pulled 1.55 billion times in seven months against 5,156 likes; Kimi-K3 was pulled about 60 times per like it received.

The two numbers record different acts. A like says a release matters, and goes to frontier models in the weeks after they ship. A download says something is wired into a pipeline that runs on a schedule, and accrues to small, stable models over years. Likes are the right instrument for reading what the field is excited about, downloads for reading what it currently depends on. Treating either as a proxy for the other is the most common mistake we see in coverage of the Hub, including our own earlier work. The same split appears at the level of the publisher.

China's frontier labs are the only accounts on the Hub where the heavy band carries the volume. Effectively all of MiniMax's 2026 downloads are of models above 70B, along with 88% of Moonshot's, 55% of DeepSeek's and 39% of Z.ai's. No large American account looks like this: Google, Microsoft and IBM Granite record essentially none of their 2026 downloads above 70B, and NVIDIA and Meta only 14% and 9%.

The difference becomes clearer in total downloads. Moonshot’s frontier-only portfolio recorded 37M downloads over the year, while Qwen’s broader release strategy across model sizes reached 2,045M (across repositories with declared parameter counts, 2,061M including all repositories) , about 55 times more. The continued expansion of the family, from the 2.4T-parameter Qwen 3.8 Max to smaller variants such as 27B, shows the same focus on coverage across different use cases.

Time also plays an important role. Most models experience a sharp decline in usage after release, followed by a long tail of steady activity. A model’s adoption is largely determined within its first few months.

This helps explain why today’s download volume is often driven not by the newest releases, but by a smaller group of models that have become established infrastructure over time.

3. Open weights shift where value accumulates

If frontier models were a licensing business, you would expect the biggest releases to carry the tightest terms. However, the data below shows a different story.

Of 178 Chinese releases above 20B parameters this year, 59% carry Apache 2.0 and 22% carry MIT, and most carry a non-commercial restriction. However, in the last few weeks, we started to see a change on this trend for the really large models, with Kimi K3 and Qwen3.8 starting to include some non-commercial restrictions and revenue share requirements to their licenses

DeepSeek and Z.ai ship models between 700 billion and 1.65 trillion parameters under plain MIT. Chinese labs license their largest models about as permissively as their smallest, and more permissively than American labs license theirs: on the American side of the same size band, 29% is Apache or MIT, 41% sits under custom terms and 30% declares nothing at all.

Whatever these releases are for, it is not licence revenue. The weights are given away on the most permissive terms available. The return has to come from somewhere else: API and cloud business, hardware and platform positioning, or the ecosystem position itself. For instance, the valuations of Z.ai and Kimi point to an effective open source strategy, getting traction and growth opportunities in the community. Going forward, however, the industry is likely to shift toward clearer monetization paths from open-source adoption.

4. Qwen has become the community's base model

A model’s ecosystem position is not defined only by its own releases, but by how much the community builds on top of it. As mentioned above, Qwen is one exception which is getting attention and adoption.

Data from Hugging Face

By this measure, Qwen has become one of the largest foundations in the open model ecosystem. Qwen-based models now account for 151,448 derivatives on the Hub, 2.6× Meta’s total footprint and 4.7× the Llama repositories specifically. Google follows with 82,506 derivatives. The third-largest source is Unsloth, a community account publishing quantized and fine-tuning-ready builds, many of which further extend the Qwen ecosystem.

Qwen derivatives have increased at roughly 180–210 new repositories per day throughout the first seven months of 2026, showing that adoption is not driven only by individual launches. Qwen has become part of the default workflow for developers deciding what models to fine-tune and deploy.

Several factors contributed to this position. First, consistency. Qwen has maintained a regular release cadence, continuously updating its model family rather than relying on occasional flagship releases. Second, coverage. It publishes models across a wide range of sizes and use cases, allowing developers to stay within the same ecosystem whether they need a small local model or a larger deployment model. Third, openness. Apache 2.0 licensing reduces friction for modification, redistribution, and commercial use.

These factors reinforce each other. A broad model family attracts more developers; more developers create more derivatives; and those derivatives make the ecosystem more attractive to future users.

This position was built largely by the community. The 151,448 derivatives represent downstream work created by other developers, not releases produced by Qwen itself. Even among the 28,531 GGUF conversions of Qwen models on the Hub, Qwen published only 54.

5. Small models remain the practical layer

Among models that declare a parameter count, those under 1B take 83% of all-time downloads and everything above 100B takes 1%. Restricting to downloads accumulated in 2026 changes nothing: 3% of the volume goes to models above 70B. This is the March finding that has held up most cleanly, for the same reason as before, small models are the only ones that run on the hardware most developers actually have.

So how does a trillion-parameter model reach anyone at all? Through llama.cpp.

In February the ggml team joined Hugging Face, with the project remaining fully open-source, community-governed and in the same technical direction. What changed is that the most important project in local inference now has durable resources behind it.

The ceiling moved with llama.cpp. The July snapshot carries GGUF builds of DeepSeek-V4-Flash at roughly 284B parameters and Kimi-K3 at roughly 2.8 trillion. Local inference used to mean an 8B model on a laptop. It now means a trillion-parameter mixture-of-experts spread across a few consumer machines, which is the alternative route the frontier did not have a year ago, and the reason a frontier-first release strategy is viable at all.

And that route runs on Qwen: 39.6 million GGUF downloads a month, nearly twice Gemma's 20.8 million and more than five times Llama's 7.5 million. The Llama gap is not a supply problem, Llama-derived GGUF repositories slightly outnumber Qwen's. Same shelf space, a fifth of the traffic.

Model repositories grew 21.5% over these seven months. Several things around them grew several times faster.

Repositories declaring the gguf library rose 464%, lerobot 194% and Apple's mlx148%, against 16% for transformers and peft and 21% for diffusers. The modelling core is growing at roughly the platform average. The layer that decides where a model can physically run local inference formats, Apple silicon, robot control stacks, is growing three to seven times faster than that.

Across the ten largest model families, the labs behind these models publish very few official GGUF conversions. Yet GGUF versions are often the ones used by developers running models locally. Providing an official conversion at release, documenting quantization choices, and signing the artifacts would require limited additional effort. Rather than maintaining this workflow internally, labs could collaborate with existing ecosystem contributors such as Unsloth. Doing so would narrow the gap between the weights tested by model creators and the versions adopted by the broader community.

6. Agents are the new user

We could not have written this section in March, because the instrument did not exist. The agent-usage dataset, published in July, records the agent/<name> token that coding agents send when they call the Hub through huggingface_hub or the hf CLI — searching for models, pushing datasets, running Jobs, creating Spaces. For the first time we can see how much agent traffic the Hub receives and which harnesses it comes from.

Claude Code led July with 44.4%, but a single month conceals the real finding: it held 67.8% in April and 6.4% in May, while Codex climbed steadily from 10.4% to 20.8%. This is a market with no incumbent, where one release or one changed default can move half the traffic in a month.

The second finding is the unregistered row. Nearly a quarter of agent-tagged traffic in July came from harnesses not yet named in the dataset, and in May that figure was 59.8%. Between April and July more than a dozen new client identifiers appeared. New entrants are arriving faster than any registry can name them — which is itself the finding.

We spent much of the year building for this reader rather than only for human browsers. Papers began serving machine-readable Markdown in March. April brought agent traces as a first-class dataset type and an agents.md endpoint on every Gradio Space, so an agent can read a Space's API and call it directly. July brought the hf_fs tool on our MCP server, exposing repositories, storage, docs and papers through a single interface in just over a thousand tokens, alongside attachable sandboxes for secure execution. The same consolidation happened at the protocol layer, with MCP moving into the Linux Foundation's Agentic AI Foundation.

Then, in July, an agent stopped being a reader and became an intruder. What appears to be the first documented case of an autonomous agent running a sustained intrusion on its own initiative happened to us. While our team tried to use frontier closed models to analyze the captured attack code, their safety guardrails declined the work. The analysis was completed in the end on a quantized open model GLM-5.2 running on our own infrastructure. We published a disclosure and a full technical timeline.

Looking forward

Compared to the spring report, the geographical rebalancing of power continues to accelerate. While U.S. open source models continue to be competitive, the race between several Chinese frontier model labs draws strong attention. Many likes on these frontier models point to what excites the community the most, and growth opportunity for companies leveraging the attention for valuations.

However, the AI race is not only sprints, but also a marathon; tools like llama.cpp helps deploying the big models locally, but a broad model family and its adoption is still the key, to build a positive feedback loop between developers, publisher and future users. Models to be embedded in the infrastructure and being part of the ecosystem, may lead to a commercially sound exit at the end of the tunnel.

In the end, with agents being the number 1 user on HF Hub for the first time, the next report may look very different.

In AI, a few months can reshape the ecosystem.

Notes on method

This analysis is based on activity observed on the Hugging Face Hub during the first seven months of 2026.

The metrics used in this report, including downloads, likes, derivatives, and model releases, represent different aspects of ecosystem activity. They should not be interpreted as direct measures of model quality, commercial adoption, or overall market share.

Downloads indicate usage within the Hub ecosystem, but they do not capture API usage, private deployments, or models distributed through other channels.

Likes reflect community attention and interest, while derivative models provide a signal of how much developers build on top of an existing model.

Because open-source AI adoption happens across many channels, Hub activity should be viewed as one perspective on ecosystem development rather than a complete measurement of the AI market.

Edited

This article was edited to include latest releases in early August.

Input and output tokens

A request goes through the GPU in two phases, and they cost different amounts. 

First, during prefill, the model reads your request and context: the system prompt, your CLAUDE.md, your message, and everything that's been added to the conversation since (the files Claude has read and the output of the commands it ran). Those are your input tokens.

Then, during decode, it writes output tokens: its thinking, the tool calls it makes, and the text you see. This happens one token at a time; a 200-token response is 200 runs of the model, one after the other. Per token, decode keeps the GPU busy for a lot longer, which is why output is priced at roughly 5x input.

A lot of the output tokens in a session are thinking tokens, and how much thinking the model does per turn is what the effort level controls. Like the model, the level you pick with /effort sticks around as your default for the next session too.

Tip: run /model and /effort once in a fresh session to see what you're actually on. Both remember whatever you picked last time, and you want that decision to be deliberate.

Tip: if you already know a session is going to be grunt work, MAX_THINKING_TOKENS=0 claude turns thinking off for that one session (except on Fable 5), which is the step below /effort low.

Prompt caching

If a request starts with exactly the same tokens as a request the server just saw, the state for that shared beginning comes out the same, so the server can keep it around from last time and only prefill whatever comes after it. This is called prompt caching.

Reading from the cache costs 0.1x the input price, because the server loads the state instead of computing it. Writing tokens into the cache costs a bit more than normal input, up to 2x, since the server also has to hold on to the state afterwards. But the write happens once per token, and the 0.1x reads happen on every turn after it.

Claude Code manages the prompt cache on every request, there's nothing to turn on. However you can break it, so it's important to know how to avoid these cost spikes.

Say we type "fix the failing test in utils.test.ts". Here's what Claude Code sends for it:

1. Claude Code assembles the first request out of the system prompt (tool definitions included), your CLAUDE.md, and your message, and sends it off (input tokens). Nothing is in the cache yet, so all of it gets prefilled and written into the cache.

1. The model can't fix a test it hasn't seen, so it thinks for a moment and responds with a Read call for utils.test.ts (output tokens). Claude Code reads the file, appends it to the conversation, and sends the whole thing again (input tokens). This time everything from request 1 is read back out of the cache at a tenth of the price, and the only thing prefilled at full price is what's new: the Read call and the file.

1. Now the model wants the file under test (output). Another Read, another append, and everything goes out again: requests 1 and 2 from the cache, the second file at full price (input).

1. The model responds with an Edit (output). Claude Code applies it, appends the result, and sends everything again. Same story: the Edit and its result are new, everything in front of them is a cache read (input).

1. The model runs npm test (output). Claude Code appends the test output and sends everything again, with the test output as the only new part (input).

1. The tests pass, and the model responds with a short summary (output). No tool call means nothing to append and no request 6, so we're done.

That's five requests for one small fix, and every one of them contained the entire conversation up to that point. A typical turn is lopsided: tens of thousands of tokens going in, a few hundred coming out. But only what's new in that turn gets prefilled at full price. 

That's the whole per-turn bill: cache reads on the history, full input price on whatever's new, and the output price on the response.

This applies on a subscription too. You don't see these prices directly, but the same requests are what draw down your limits.

The cache has to match from the very start of the request forward, and requests always go out in the same order: tool definitions, then the system prompt, then the conversation (with CLAUDE.md at the front of it). 

If anything in that prefix changes, everything behind it gets prefilled again. A tool result appended to the end of the conversation is the ideal case, since nothing is behind it. What throws the cache away is anything that changes the request further towards the front, or changes what the cache is keyed on:

• /model: every model has its own cache, so on the next turn the entire conversation gets prefilled again at full price. (This includes opusplan, which switches models every time you go in or out of plan mode.)
• /effort: the effort level is part of what the cache is keyed on too, so it's the same story. It's why both /model and /effort ask you to confirm when you switch in the middle of a conversation.
• Fast mode: also part of the key, and the re-prefill happens at fast mode prices, so if you're going to turn it on, turn it on at the start. (Turning it off again is free, cache-wise.)
• /compact: the conversation gets replaced with a shorter one, so nothing in it matches anymore (the system prompt in front of it survives). Writing the summary itself is cheap as long as the old conversation is still in the cache, so it's a lot cheaper before a long break than after one.
• Time: every turn resets the clock, but the cache expires after an hour on a subscription or five minutes on an API key (ENABLE_PROMPT_CACHING_1H=1 makes it an hour). Come back later than that, and the next turn prefills the whole conversation again. Resuming an old session almost always does too: the cache is usually gone by then, and the system prompt gets rebuilt at launch anyway.

None of this means you should never switch models or effort. It means there are cheap moments to do it, the start of a session or right after a /clear, and expensive ones, the middle of a long conversation.

Tip: if the last few turns went somewhere you don't want to keep, /rewind to just before them instead of running /compact. Rewinding only cuts those turns off the end, so everything before them is still cached and it costs nothing. Compacting rewrites the whole conversation, so it always costs something.

What decides how many tokens a session sends

The main thing to know here is that nothing gets sent just once. Everything that ends up in the conversation, a file Claude read or the output of a command it ran, gets sent again on every turn after it, for the rest of the session. 

It's cached, so each of those re-sends is cheap, but cheap isn't nothing, and it's taking up room in the context the model has to think around on every turn too.

That's really the whole cost model of a session: how many tokens end up in the context, how many turns they stay there, and how many contexts you're running at the same time.

What ends up in the context

Part of what's in the context is there before you type anything: the tool definitions, the system prompt, CLAUDE.md, and whatever else gets loaded at startup.

Tip: run /context in a fresh session to see what's in there before you've typed anything. Keep CLAUDE.md to specific instructions and move workflow-specific ones into skills, which only get loaded when they're used. If there's an MCP server you don't need in this session, turn it off with /mcp.

Nearly everything else that gets added during the session is tool results: the files Claude reads, and the output of the commands it runs.

How much Claude reads mostly comes down to how much it has to figure out on its own. If you say "the tests are failing", it first has to find out which tests: a grep or two, a few files opened to see which one is relevant, and all of those results stay in the context long after they've stopped being useful. 

"Fix the failing test in utils.test.ts" skips the searching and costs one Read call for the file, and "Fix the failing test in @utils.test.ts" doesn't cost the Read call either.

Tip: when you're referring to a file, @-mention it instead of typing the path. Claude Code attaches the file to your message before anything gets sent, so it's in the very first request and there's no Read call for it. The file itself takes up the same room in the context either way, so you only need to mention it once per conversation: it stays there, and @-mentioning it again on a later turn generally attaches a second copy.

The other thing that fills up the context is the output of the commands Claude runs. Every time it runs your tests, a build, or a git log, whatever that prints gets appended to the conversation just like a file it read, and stays there for the same number of turns.

Really big outputs are actually fine: after 30,000 characters Claude Code writes the output to a file and only puts a short preview and the path in the conversation (BASH_MAX_OUTPUT_LENGTH if you want to change it). 

The problem is everything under that. A test runner that prints 400 passing tests one line at a time comes in under the limit, and those 400 lines are now part of every remaining turn. 

Claude will often take care of this for you with flags and tail, and if you'd rather not leave it up to Claude, there's a small hook in the docs that rewrites noisy commands before they run so only the lines that matter come back.

Tip: put the two or three commands you run all day in CLAUDE.md, quiet flags included, the way you'd type them yourself ("run a single test file with npx vitest run <file> --reporter=dot"). It's a small addition, but it saves a turn and a few hundred lines of output in every session after it.

How many turns it stays there

One long session costs more than the same work spread over a few short ones, and by more than you'd think, because turn 40 is also re-reading the 39 turns before it. You want the context in your session to be short and relevant, so don't carry one task's context into the next: /clear when you start something new, and /compact when the earlier part of the same task is done.

Tip: /rename before you /clear if you'll want the session back later. When you /compact, tell it what to keep, or put a "Compact instructions" section in CLAUDE.md if it's always the same thing. And if you're on a 1M model and would rather have the auto-compact safety net where it used to be, /autocompact 200k puts it back (needs Claude Code v2.1.221+).

Keep an eye on turns that happen when you're not typing, too. A /loop fires as a full turn in the session you set it up in, carrying that whole conversation with it every time, and if it's been more than an hour since the last turn, it's a cache miss on top. Start a fresh session in another terminal and run the loop from there.

Subagents

The other way to keep something out of your context is to have it happen in a different one, which is what subagents are for. A subagent gets its own context window, with its own system prompt, the tools, and your CLAUDE.md, but not your conversation. It runs its own turns, and the only thing that comes back to the main session is its answer. Everything else is thrown away once it's done.

The downside of not having your conversation is that a subagent sometimes has to re-read things the main session already had, and it's paying for its own turns while it does. For a small job it's just overhead. 

It pays off when a job produces a lot of output you don't need to keep, like going through a log. Claude will often reach for one on its own for that kind of thing, and you can ask for one directly when it doesn't ("go through this log in a subagent"). Just keep in mind that the main session only gets back what the subagent chose to report.

Tip: if there's a noisy job you hand off over and over, give it a subagent definition of its own with model: haiku (or sonnet). Otherwise it runs on whatever your main session is running on.

Where to look first

Of everything above, four things are worth keeping an eye on, roughly in order of how much they cost:

(Updated: October 31, 2023)

Around January 20, 2009, when Barack Obama took over the office of president of the United States, there was quite a lot of media attention about the fact that he had to give up his BlackBerry, because it was considered to be a security risk.

This caused almost world wide media attention, but the follow-up was less accurately covered and a number of different stories were told. Here we will show that Obama actually kept his beloved BlackBerry, but only after it had been secured by special encryption software and some additional security measures.

President Obama showing his BlackBerry (photo: Reuters)

Obama's predecessor, George W. Bush, also used a BlackBerry during the 2000 presidential campaign, but had to give it up, as well as the use of any e-mail software, upon taking office. Three days earlier, he sent out a final e-mail to 42 friends and family members to inform them that he would no longer correspond electronically.

Eight years later, Barack Obama was also forced to give up his BlackBerry, not only because of concerns that its communications and e-mail could be intercepted, but also because of the Presidential Records Act of 1978. This makes all written White House communications public property and subject to examination under the Freedom of Information Act (FOIA).

However, this time Obama definitely wanted keep using this popular business phone to stay in touch with people outside the White House bubble. Therefore, the Secret Service (USSS), the White House Communications Agency (WHCA) and the National Security Agency (NSA) went looking for a solution.

Obama using his BlackBerry 8830 during the election campaign in 2008
(Photo: Getty Images)

Sectéra Edge

Some media suggested Obama had to change his BlackBerry for the Sectéra Edge, a highly secured PDA, which is produced by General Dynamics for the US military. But the Sectéra Edge is quite big, heavy (340 grams) and bulky and therefore hardly convenient for someone used to a BlackBerry. This solution would also require everyone that Obama would like to communicate with to have the same phone, which is priced between 2650,- and 3350,- USD. Secure communications are only possible if both ends use the same (or compatible) encryption devices.

According to other sources, the Sectéra Edge was only used in addition to Obama's BlackBerry, until a permanent solution was worked out. Reports weren't clear about how exactly these two devices were combined. Probably the Sectéra Edge acted like an encryptor, which was plugged into the BlackBerry, so Obama could keep using this device to make a call or send out an e-mail, which then went through the Sectéra Edge, encrypting it, before going over the telecommunications network.

The Sectéra Edge, manufactured by General Dynamics

Compromise

That latter, temporary solution must have been even more cumbersome, so a compromise was made, in which president Obama could keep using a BlackBerry, but equipped with a software package to encrypt phone calls and text and email messages.

For this purpose, the security agencies choose the SecurVoice application, which was developed by The Genesis Key, in cooperation with engineers from BlackBerry manufacturer Research In Motion (RIM). SecurVoice should not be confused with Secure-Voice.com, nor with SecuVOICE, which is used for securing the smart phone of the German chancellor Merkel.

Update:
Responsible for securing Obama's BlackBerry was Richard "Dickie" George, who served as technical director of the NSA's Information Assurance Directorate (IAD) from 2003 until his retirement in 2011. In 2014 he told CNN that the NSA set up a lab where dozens of experts performed surgery on the president's future BlackBerry for several months. The device was manipulated to weed out potential threats to secure communication and BlackBerry's algorithms were also reviewed. The choice of the smartphone model was eventually the NSA's, not Obama's, George explained.

After the NSA did all the necessary tests and checking to make sure the software met federal standards like FIPS 140-2, the highly secured BlackBerry was delivered to the president somewhere in May or June 2009. He also gave up his old e-mail address and switched to a new one, which is kept secret.

Maybe we can see the new, secured BlackBerry in this picture below, where there are two BlackBerrys lying in front of Obama. The silver one seems to be the BlackBerry 8830, which he already used during the election campaign. The black one, probably a BlackBerry 8900, could then be the new secure one, as we can see the president using this one in later pictures:

President Barack Obama works with Jon Favreau, director of speechwriting, on the Normandy speech
aboard Air Force One enroute to Paris. In front of him are a black and a silver Blackberry.
(White House photo by Pete Souza, June 5, 2009 - click for a bigger picture!)

Detail from the picture above, showing the two BlackBerrys

The secure BlackBerry was not only issued to the president, but also to a small group of people with whom he likes to stay in close contact with. This because, as said, it's only possible to have secure communications if both ends are using the same encryption method. This limited Obama's goal of keeping in touch with the outside world: encryption (still) means exclusion.

The number of people able to message and call the president is probably only between ten and twenty. Included are vice-president Biden, Obama's chief of staff Rahm Emanuel, advisors David Axelrod and Valerie Jarrett, press secretary Robert Gibbs, first lady Michelle Obama, a few other family members, and some personal friends from Chicago.

Update:
On March 16, 2016, AP reported that in February 2009, secretary of state Hillary Clinton also wanted a secured BlackBerry like the one used by Obama, but that NSA denied that request. A month later, Clinton began using a private server, located in the basement of her home, to exchange e-mail messages with her top aides through her regular, non-secure BlackBerry. Later it came out that this rather risky solution was also used for sensitive messages.

On October 30, 2013, Obama's press secretary Jay Carney said that the president will continue to use his (secured) BlackBerry, despite concerns about eavesdropping which came up after it was revealed that NSA intercepted the communications of 35 world leaders.

The Genesis Key

The SecurVoice software for the presidential BlackBerry was developed for a small company called The Genesis Key, Inc., based in Washington DC. This company was founded in October 2008 by W. Steven Garrett, who took the name from an item used in the 1986 computer game The Legend of Zelda.

The software was developed in the previous four years, apparantly for one of the projects of Steve I. Cooper, a former special assistant to the president, senior director for information integration, and CIO (Chief Information Officer) for the Office of Homeland Security. He is now a member of the advisory board of SecurDigital, Inc., a firm founded in October 2009 by Bruce Magown and Steven Garrett to distribute the SecurVoice software applications.

Steven Garrett is a man with a quite surprising background. His Linked-In profiles show that he has been involved in a very wide range of businesess, like manufacturing plants for Fannies Fat Free Cheesecakes and Fat Free Burger (providing microwave-ready cheeseburgers to military commissaries) and marketing & sales for Lion Sportswear and Faded Glory Jeans. He also developed a highly secure appartment building, named Garrett Place. At his twitter account he describes himself as "Proven Rainmaker, Change Agent, Strategist, and Driving Force for Unprecedented, Exponential Growth in Revenues, Earnings, and Market Valuation".

SecurVoice

The Genesis Key released the SecurVoice software in December 2008, claiming this to be the world's first completely secure voice and data encryption solution. Allthough there were already a number of other hardware and software encryption solutions, the SecurVoice application should be able to protect global voice connections between and within all types of cell, satellite, PBX, SDR and VOIP phones and phone systems.

SecurVoice is 100% Java based, which should make it device- and carrier-independent, but according to the website, the software is currently only operational on the Blackberry operating system version 4.5 and up. Software porting for other operating systems, like Symbian, Brew, Windows Mobile, Google, and iPhone is said to be underway.

With SecurVoice, each phone can be loaded with up to three levels of security, each one accessible through a separate icon and recognizable by a different ringtone. When dialing a number and this number has a cryptographic key associated with it, then the call is automatically placed as a secured call. If a phone number has no cryptographic key associated with it, then the cell phone operates normally and the call is placed unencrypted.

The SecurVoice software comes in two versions:
- Phone-to-Phone (P2P), where secure calls are made directly from one cell phone to another. The price for government users is 1795,- USD per application.
- Phone-to-Server (P2S), where secure calls are routed from the phone to an enterprise server and back. The price of a server license is between 2500,- and 25.000,- USD.

It's likely, that for Obama the server solution was chosen. This allows a centralized key management, monitoring of all secure calls and record keeping of the messages. One source says the president may have to wait up to 50 minutes for an e-mail reply, as the system actively sniffs out incoming messages for viruses or Trojan horses.

Overview of the SecurVoice application options
(by The Genesis Key/SecurDigital)

Encryption

The SecurVoice software features a dual-layered, or hybrid encryption scheme, which means it combines symmetrical and asymmetrical encryption algorithms. It performs the voice encryption in real time by using a fast symmetric cipher, using a strong key. This key is then encrypted with a public-key or asymmetrical cryptosystem, like RSA or ECC, and transmitted together with the encrypted message. This is also how the vast majority of present-day communications encryption works.

The SecurVoice symmetric encryption uses a 256-bit session (conversation) key, which replaces the encryption every second with non-reoccurring numbers. This session key is a combination (salted hash) of the sender Base Secure Key (stored in the recipient key store) and a random session key. According to the manufacturer, SecurVoice uses classified Type 1 encryption algorithms, which are restricted to government and military users. For corporate users, public crypto algorithms like AES are used.

In case of a SecurVoice enterprise server, the software converts voice into encrypted data, which is then sent over the carrier network to the SecurVoice Enterprise Server where it is decrypted. It is then re-encrypted and sent back over the carrier network to the receiving phone, where it is decrypted and converted back to voice. It's also possible to select different encryption algorithms, so that, for example, encryption from a cell phone to the enterprise server may be the AES algorithm with a 128-bit, while from the server to the receiving phone this may be done by using Elliptic Curve Cryptography (ECC).

President Obama using his BlackBerry 8900 in the limousine while traveling
from the University of Indonesia to the airport in Jakarta, Indonesia.
(White House Photo by Pete Souza, November 10, 2010)

Security risks

As Obama wanted to keep using a BlackBerry device, the security solution is software only. This still leaves risks like compromised hardware and hacking by means of social engineering. Therefore, some security specialists say that it's not impossible to hack Obama's BlackBerry and that foreign states and other hackers will likely try to do so.

To minimize these risks, the secured BlackBerrys prevent forwarding e-mail messages from the president and sending him attachments. His secret e-mail address is likely to be changed regularly as well and Obama's friends and staff members were lectured about these security issues.

Another risk of the president using a BlackBerry, like a cell phone in general, is that enemies can try to track the president's location in real-time, even when GPS is disabled. Every cell phone regularly transmits it's IMEI-number to the cell tower, and this can be intercepted by devices like a Triggerfish. How this tracking can be done, and countered, is described in this, respectively this article.

One source says the presidential BlackBerry can only connect to a secure base station, which can be used to hide the IMEI-number of the device and thus prevent tracking it. This would mean the White House Communications Agency has to carry such a secure base station wherever the president goes.

There must be also a secure base station inside the presidential limousine, as we can see in the picture above. First because using a foreign cell phone network would be a big security risk, but also because the limousine is most likely constructed like a Faraday cage, and therefore a BlackBerry could only be used if there's a base station in the car itself (and probably also in Air Force One). The secure base station is probably connected to a secure satellite link with Washington.

President Obama uses his BlackBerry for calling Mitt Romney
(White House photo by Pete Souza, November 6, 2012)

Conclusion

As we have seen, president Obama has kept his BlackBerry, but only after it had been secured. This took quite some effort: newly developed software had to be tested within a couple of months, all his contacts have to use the same software, limiting their number to a rather small group, and a secure base station has to follow the president.

Nonetheless, this ad hoc solution for the president marks the beginning of an era in which top level mobile communications will no longer be secured with dedicated hardware, but by using software applications for regular commercial smartphones.

Sources and Links

- Yahoo.com: Obama has finally ditched his BlackBerry, but its replacement will surprise you (2016)
- CNN.com: 'I made Obama's BlackBerry' (2014)
- FoxNews.com: Obama Getting Super-Secure BlackBerry
- New York Times: Symbol of Elite Access: E-Mail to the Chief
- The Telegraph: Barack Obama's BlackBerry 'no fun' (2010)
- PRWeb: The X-Change Corporation Acquires Genesis Key, Inc. (2010)
- Radio interview about SecurVoice: Telecom Junkies - Secret Agent Phone
- Interview with Steven Garrett: Wireless Technology Risks and Enterprise Security (2010)
- Washington Times: Obama soon to get secure BlackBerry (2009)
- WirelessMoves: How To Secure The BarackBerry (2009)
- Communities Dominate Brands: Do Communities Dominate personal security of Obama? The Blackberry Battle (2009)
- See also: securvoice.blogspot.com

Comments on Hacker News (2013) and Hacker News (2025)