Tim Dettmers, who runs a machine learning lab at Carnegie Mellon, asked a class of 150 students who was afraid of not getting a job after graduating. About 120 hands went up. His blog post about it, published on 21 September 2026, argues that the fear rests on a wrong assumption: that the future belongs to whoever has the most GPUs.
His argument is about academic research, but most of it applies to anyone who works with AI agents (programs that use a language model to plan and carry out multi-step work, such as Claude Code). We run a second brain: a folder of plain-text notes that several agents read, write and act on every day. This post explains the main ideas in his post, looks at the one release we could read in full, and turns them into concrete changes for our setup and yours.
What changed when agents arrived?
Dettmers' starting observation is simple. With agents, a research project that used to take a year of engineering now takes weeks, sometimes days. When each project becomes cheap, a single project stops being impressive.
He puts it in one line: the unit of research is no longer the paper, it is the ecosystem. A paper here and a paper there, each self-contained, asks the reader to stitch the pieces together. That format made sense when every piece was expensive. Now the hard part is building pieces that build on each other, so that each one makes the next more useful.
An analogy: when bricks were hand-made, a single good brick was worth showing off. Once bricks come off a machine, nobody cares about one brick. They care whether you built a house. The analogy stops working in one place: a house is finished, while an ecosystem keeps growing as other people add to it.
What did his lab release?
The post announced an open-source week: two open-source projects and four papers, released together on purpose. The post covers three pieces:
- An agent harness (the code around a model that gives it tools, memory and rules) that you point at a code repository and leave. He reports it optimised his lab's Mac inference kernels on its own.
- Local frontier models: large open models running on a single desktop GPU or a high-memory laptop.
- A local autonomous research system that proposes problems, runs experiments and reports results with no internet access. In his example it produced four results on a bioinformatics problem in about two hours, without reaching the best known result on the overall problem.
Those numbers are his claims, and we have not tested them. One release we could at least read in full is CliffCompaction, published the next day as a paper and an MIT-licensed tool. Dettmers is a co-author, so its figures are his team's claims too, not an independent check.
What is CliffCompaction, and why does it matter for everyone running agents?
An agent's context window is its working memory: everything the model can see at once. Long sessions fill it. The usual fix, called compaction, replaces the conversation so far with a shorter version and continues from there. The CliffCompaction paper argues that when that shorter version is a rewrite, and later rewrites are made from earlier ones, drift compounds.
CliffCompaction does two things differently, according to its paper:
- It only truncates or drops content, never rewrites it. What stays is the original text, so nothing is paraphrased into something slightly wrong.
- It never compacts a compaction. Each pass works from the original content and throws away the previous compacted output, so errors don't pile up.
It runs as a proxy, a small program that sits between the agent and the model provider, so the agent itself does not change. The paper reports cost cuts of up to 50% under a bounded context while keeping or improving scores on the Terminal-Bench benchmark. Dettmers adds that one partner company measured a 45% drop in its total AI spend. Setup, from the project's README, is two commands:
uv tool install cliffcompaction
cliff enablecliff enable defaults to Claude Code. cliff disable reverses it.
What do you do with the money you save?
This is the part of the post most people will skip, and it is the most useful. If each attempt costs half as much, you can run two attempts for the price of one and keep the better result. The paper reports over 10 percentage points more on Terminal-Bench from test-time scaling (spending on extra attempts), for less than the cost of two full-context runs.
The general rule: cheaper attempts are not only a saving, they are a budget for trying twice. Our view, which we have yet to measure: for hard tasks, two independent tries and a check that picks the better one are worth testing against one careful try.
How should a person work with agents now?
Dettmers gives three habits he now asks of his PhD students:
- Work on the ecosystem. Judge a piece of work by what it connects to.
- Run many projects in parallel. An agent can carry one project while you think about another.
- Attack the problem first, understand it as you go. The old order was basics, then methods, then problems. With agents you can start from the problem and look up what you need along the way. Your attention goes to the hard part.
He frames all three with one sentence: let go of how you work, not who you are. Methods are negotiable. Your personality, the people you love and what you hold important are not, and holding those steady is what makes it possible to change everything else quickly.
There is one more line worth keeping. His lab built a tool that turned a recorded meeting into research questions checked against the literature. It needed him to copy and paste between two steps by hand, so he stopped using it. The students then asked for it back. His conclusion: the only evaluation of a research tool he trusts is that people ask for it after you stop giving it to them.
What we are changing in our second brain
Our setup: a vault of notes in plain markdown, a shared rules file every agent reads, skills (written procedures an agent loads when it needs them), a kanban board where requests become cards, and several agent lanes that pick up cards in parallel. Here is what the post changes, in order of how soon we expect to act on it:
- Trial CliffCompaction on one agent lane for a week. One lane, its own proxy instance, the other agents untouched. We compare cost per card and how often a card's checks pass against the week before. This is a plan; we have not run it yet.
- Spend any saving on second attempts. When a card fails its checks, run two variations and let the checker pick, rather than one retry.
- Measure skills by "asked for again". A skill that ran is not the same as a skill that helped. We will look at which skills and outputs get requested again, and review the ones nobody asked for in a month.
- Hunt down manual hand-offs. Every place a person copies, pastes or forwards between two steps is where a pipeline quietly dies. We plan to list them and remove them one by one.
- Make every new piece name its neighbours. Notes already have to link to the project they belong to. New skills and tools should say what they build on and what can build on them.
- Keep sources verbatim and summarise once. We already save some articles as an untouched copy next to a separate analysis note. We want that to be the rule for every saved source, with analysis always written from the original, never from an earlier summary. It is CliffCompaction's rule applied to notes.
How to apply this to your own agent setup
If you run agents, three checks take less than an hour:
- Look at your longest sessions. If they compact often, a truncate-only proxy is cheap to try and easy to remove.
- Find one task you retry by hand and try two parallel attempts with an automatic check instead.
- List the tools you built in the last three months and mark which ones you or anyone else asked for again. Drop or fix the rest.
The core idea is Dettmers': when each piece is cheap, the value is in how the pieces connect and whether people keep coming back for them. Read his full post at https://timdettmers.com/2026/09/21/dlab-open-source-week/ and follow what we build at https://x.com/myargoquest.