TL;DR: Chat was the perfect interface for proving that AI could think. It is becoming a bad interface for everything AI is now being asked to do. Persistent agents need durable state, visual controls, background work, and access across the places people already live. The next AI interface will look less like one giant conversation and more like software that appears around the job.

The Chatbot Is Becoming the Wrong Shape for AI

The chatbot is a great interface for asking a question.

It is a terrible interface for running your life.

That distinction barely mattered when AI mostly answered prompts. It matters a lot now that the industry wants agents to remember projects, work in the background, coordinate across apps, and come back hours later with something finished.

We keep giving those systems the same interface: one endless transcript.

I think that is about to change.

Chat was the bootstrap interface

Chat won for a good reason.

It removed almost every UX problem between a person and a model. You did not need to learn menus, commands, schemas, or workflows. You typed what you wanted in normal language and the model figured out the rest.

That was perfect for demonstrating general intelligence.

It also created a trap.

Once chat became synonymous with AI, every new capability got shoved back into the conversation window. Research results. Tasks. Files. Generated apps. Long-running projects. Notifications. Memory. Tool calls. Everything became another message.

At small scale, this feels magical.

At large scale, it feels like scrolling through a very intelligent junk drawer.

Long-running work breaks the transcript

The problem becomes obvious once an agent has work that outlives the conversation.

OpenAI’s Dots, announced September 29, are built around persistent agents with their own cloud computers. They can work in the background, connect to thousands of apps, carry context across ChatGPT, Slack, and Teams, and proactively surface progress or decisions.

That is not really a chatbot anymore.

The conversation is just one control surface for a worker that exists somewhere else.

Meta is moving in the same direction with Muse. At Connect, Meta showed Muse spreading across smart glasses, desktop computer use, email, commerce, and connected business software. The point is not that every one of those surfaces will win. The point is that the agent is no longer expected to live inside one app.

The AI is becoming persistent.

The interface is becoming plural.

Software is coming back

Wabi’s recent pivot is even more explicit.

Wabi started as a prompt-to-app product. Wabi 2.0 reframes itself as a messenger where the agent can generate the interface needed for the current task.

That sounds like a small product change. I think it captures a much bigger idea.

The future of AI UX is probably not “replace software with chat.”

It is “use language to create and control software.”

Those are very different visions.

If I am tracking workouts, I do not want to ask a chatbot, “What did I bench last Tuesday?” every time. I want a chart.

If I am managing a family calendar, I do not want the calendar buried 400 messages up. I want a calendar.

If I am approving an expense, I do not want a paragraph describing the transaction. I want the amount, vendor, account, and an approve button.

Language is wonderful for expressing intent.

Visual software is still better for seeing state.

The winning AI products will use both.

The universal chat window is a temporary compromise

This is why I am skeptical of the idea that one giant chatbot becomes the operating system for everything.

The agent may become universal.

The interface probably will not.

Different work wants different shapes.

A conversation is good for ambiguity. A dashboard is good for state. A spreadsheet is good for comparison. A timeline is good for sequence. A map is good for place. A button is good for a decision you should not accidentally phrase in natural language.

Trying to compress all of those into chat is not simplicity.

It is throwing away useful structure.

Wabi’s “generate the interface you need” idea is interesting because it reverses the current assumption. Instead of forcing every task into the AI’s preferred interface, the AI adapts its interface to the task.

That feels much closer to where this is going.

The real product is continuity

There is a deeper implication.

If the agent can appear in ChatGPT, Slack, glasses, a generated mini-app, or some future device, then the valuable thing is not the surface itself.

It is the continuity underneath it.

Does the agent know what project I am working on?

Does it understand what already happened?

Can it retrieve the source material instead of making me re-upload it?

Can it move from conversation to structured state without losing information?

Can it return to a task tomorrow without pretending the world started five minutes ago?

That is the hard part.

A beautiful chat UI with no continuity is still a disposable session.

A persistent agent with good state can survive almost any interface.

Chat will become one tool among many

I do not think chat disappears.

The command line did not disappear when graphical interfaces arrived. It just stopped pretending to be the interface for everyone and everything.

Chat will probably follow the same path.

It will remain the fastest way to express a fuzzy request, explore an idea, or redirect an agent.

Then the agent will increasingly hand the work off to a better-shaped surface.

Or nothing visible at all until the work is done.

The first era of generative AI taught computers to understand what we mean. The next one may be about teaching software to take the right shape after it understands us.

And if that happens, the chatbot will turn out to have been less like the final interface for AI and more like its command line.

Share

Subscribe now

TL;DR: The near-term AI risk for software engineering may not be mass layoffs. It may be something quieter: companies needing fewer junior engineers while still depending on the senior judgment those juniors were supposed to become. If AI absorbs the apprenticeship tasks, the industry has to deliberately rebuild the apprenticeship.

AI Is Breaking the Apprenticeship Ladder Before It Breaks the Job Market

The software-job debate is usually framed as a headcount question.

Will AI replace engineers?

Will companies hire fewer people?

Will coding agents eliminate entire teams?

I think that framing misses the more immediate problem.

Software engineering may be losing the work that teaches people how to become good software engineers.

That is a different kind of disruption.

And it may arrive well before mass replacement.

The labor-market split is already visible

When Revelio Labs released its September 2026 AI Labor Market Tracker, the headline was not “AI destroyed employment.”

In fact, companies that have actually adopted AI are still growing faster than non-adopters. AI-related employment has also grown substantially since 2022.

But the growth is extremely uneven.

At AI-adopting firms, Revelio estimates senior headcount has grown 32% relative to non-adopters, while junior headcount has grown only 6%.

Across the broader labor market, employment for workers aged 22–25 in the most AI-exposed occupations is down about 20% relative to comparable workers in the least-exposed occupations since before ChatGPT. For older workers, the gap is only 6%.

That is not proof that AI caused every missing junior job.

The labor market has been strange for several years, and the researchers explicitly distinguish AI exposure from actual adoption.

But the direction is hard to ignore.

The people who already have judgment appear to be benefiting more than the people who are supposed to be acquiring it.

Junior work was never just cheap output

A junior engineer does a lot of work that a strong coding agent can now do quickly.

Write the small endpoint.

Add the tests.

Trace the bug.

Refactor the ugly function.

Read an unfamiliar library.

Fix the thing that broke in staging.

From a narrow productivity perspective, automating those tasks looks wonderful.

From a talent-development perspective, those tasks were the curriculum.

They forced someone to encounter bad abstractions, confusing APIs, production constraints, brittle tests, code review, and the consequences of decisions they did not yet understand.

Eventually, enough of those repetitions became intuition.

That intuition is what makes a senior engineer valuable.

We are automating the exercises while continuing to demand the graduate.

Productivity and learning are not the same thing

This is where the AI-coding research gets interesting.

A Stanford-hosted 2026 meta-analysis of 23 studies found a statistically significant, moderate productivity improvement from generative-AI coding assistants.

That part is unsurprising.

The more important result is that the same analysis found no statistically significant improvement in learning outcomes.

Faster completion is not automatically faster skill formation.

Another CHI 2026 study looked specifically at junior and senior engineers using agentic coding tools. Its sample was small, so I would not generalize the exact behavior too aggressively.

But the pattern makes intuitive sense.

Experienced engineers tended to maintain control through detailed delegation and iterative refinement.

Junior engineers were more likely to swing between two bad extremes: trusting the agent too much or avoiding it too cautiously.

The senior engineer knows what to delegate because they already understand the work.

The junior is trying to use delegation to learn the work.

Those are fundamentally different tasks.

AI makes senior judgment more valuable, not less

This is the paradox I keep coming back to.

The better coding agents get, the less valuable manually producing every line of code becomes.

But the value of deciding what should be built, whether the output is correct, where it will fail, and what tradeoff is acceptable goes up.

Revelio’s latest data supports this broader shift.

Ninety percent of year-over-year change in work activities is happening within occupations rather than through occupations disappearing entirely.

That means the job title can remain “software engineer” while the actual job changes underneath it.

Less typing.

More specification.

More evaluation.

More architecture.

More debugging of systems you did not personally write.

More responsibility for the boundary between an agent’s plausible answer and a production system’s actual behavior.

That is fantastic for someone who already spent ten years learning the substrate.

It is a much harder starting point for someone on year one.

Companies can accidentally eat their own talent pipeline

There is an obvious short-term incentive here.

If one experienced engineer with agents can handle work that previously required several juniors, hiring fewer juniors is economically rational.

The problem appears five years later.

Where do the next experienced engineers come from?

You cannot solve this by telling young developers to “learn fundamentals” in the abstract.

Fundamentals become useful through repeated contact with reality.

The industry needs a new apprenticeship model built for AI-mediated work.

That probably means giving junior engineers real ownership even when an agent could finish the task faster.

It means reviewing prompts and delegation decisions alongside code.

It means making juniors explain why generated code is correct rather than rewarding them only because the tests pass.

It means intentionally exposing people to architecture, incidents, tradeoffs, and failure analysis earlier.

And it means accepting some local inefficiency in exchange for maintaining the organization’s future supply of judgment.

The metric I would watch is not developer productivity

We will get endless measurements of how many pull requests an engineer can ship with AI.

I care about another number:

How quickly can an AI-native junior engineer become someone you would trust when the agent is wrong?

That is the real apprenticeship benchmark.

A company that solves it gets two advantages.

It captures today’s productivity gains without hollowing out tomorrow’s senior bench.

And it develops engineers whose advantage is not that they can type code faster than a model.

Their advantage is that they know what good looks like.

AI is making implementation cheaper.

We should be careful not to make expertise scarcer at the same time.

Share

Subscribe now

The strongest AI products may soon be distinguished less by which frontier model they use and more by what surrounds the model.

That sounds backwards after several years of benchmark obsession. I think it is where the market is heading.

Share

The Next AI Moat Is the Harness, Not the Model

For the last few years, AI products have mostly competed on model access.

Who had GPT-4 first? Who had the largest context window? Who had the strongest coding benchmark? Who could offer the newest reasoning model?

That made sense when capability differences were enormous.

It makes less sense as the models improve and converge.

The interesting competitive layer is moving outward.

The model is becoming one component in a much larger system

A useful agent does not just need intelligence.

It needs to know which context to load, which tools to expose, what state to persist, how to recover from failure, when to ask for approval, how to route work to another system, and how to avoid wasting tokens on irrelevant information.

Those decisions are not model weights.

They are product architecture.

Anthropic recently described removing more than 80% of Claude Code’s system prompt for newer Claude 5-generation models without a measurable loss on its coding evaluations. Their explanation is revealing: as models get better at judgment, the surrounding system can shift away from giant instruction piles and toward better interfaces, progressive disclosure, and selectively loaded skills and tools.

That is a very different design problem from prompt engineering.

It is harness engineering.

Better agents need less babysitting from the model

A lot of current agent behavior is surprisingly wasteful.

The model calls a tool. It waits. It checks whether the tool finished. It polls again. It receives a giant block of context it may not need. It reconstructs state after an interruption.

We often treat this as an intelligence problem because the model is visibly involved in every step.

It may actually be an infrastructure problem.

Unreal Labs’ newly released Unreal Agent is an interesting example. Its core design is async-first: tool operations can continue independently while the agent’s durable session tracks their state. The model does not need to spend turns managing waits and heartbeats.

The specific benchmark claims are still vendor-reported and the project is extremely young. I would not take the performance numbers as settled fact.

But the architecture is more important than the benchmark.

The model should reason.

The harness should remember that a job is still running.

That separation feels obvious once you see it.

Context is becoming a routing problem

The same thing is happening with context.

The old instinct was to put everything in the prompt.

Company instructions. Style guides. Tool documentation. Examples. Memories. Every edge case anyone had ever encountered.

That approach made sense when models were bad at deciding what mattered.

Now it can become counterproductive.

Anthropic’s current guidance explicitly favors progressive disclosure: keep specialized knowledge and tools available, but load them when the task actually needs them.

This suggests a different way to build agent systems.

Do not ask, “How do I give the agent everything?”

Ask, “How do I make the right thing easy to retrieve at the right moment?”

That is an information-architecture problem.

Reliability may matter more than another benchmark point

This becomes even clearer once an agent touches real systems.

Imagine an agent that can work across your notes, files, email, source code, and local storage.

The impressive demo is that it can understand all of them.

The useful product is that it can keep working when one connector fails.

That distinction matters.

A connector should be a convenience layer, not the only road to the underlying data. If the MCP layer breaks, a robust system should have another authorized path. If a job dies halfway through, the session should recover. If an external API stalls, that should not erase the entire plan.

These are boring capabilities.

They are also the difference between a demo and infrastructure.

The best AI products may become model-agnostic

There is another consequence.

If most of the product’s value lives in orchestration, memory, context selection, tool interfaces, workflow state, and integrations, then switching the underlying model becomes easier.

That does not mean models become commodities.

A substantially better model can still transform what a product can do.

But the relationship changes.

The model becomes an engine inside a system rather than the entire product.

The durable advantage belongs to whoever has built the best system around it.

This changes what I would evaluate

When I look at an agent product now, I care less about the headline model name than I used to.

I want to know:

• Can it retrieve the actual source material, or only a vendor-generated summary?

• Can I move my data elsewhere?

• Does it preserve state across failures?

• Can tools run asynchronously?

• Can the system load specialized context only when it is relevant?

• Can I swap models without rebuilding the workflow?

• Are permissions and safety boundaries enforced by the system rather than improvised by the model?

None of these questions makes for a dramatic benchmark chart.

Together, they determine whether the agent is dependable.

Intelligence is getting cheaper. Good systems are not.

The last generation of AI products was defined by access to powerful models.

The next generation may be defined by who turns those models into reliable systems.

My bet is that the most durable AI companies will look increasingly boring from the outside.

They will obsess over context routing, state, permissions, interoperability, recovery, and clean tool interfaces.

The model will still matter enormously.

It just will not be the whole moat.

Subscribe now

The humanoid robot race is usually framed as a contest to build the smartest machine. I think that misses the more important competition. The winner may be the company that closes the loop between deployment, real-world data, better models, and cheaper hardware fastest.

Subscribe now

The Humanoid Robot Race Is Really a Data Race

Humanoid robotics is starting to look like AI did a few years ago: spectacular demos, huge funding rounds, breathless forecasts, and a lot of arguments about whose model is smartest.

I think that framing is already becoming outdated.

The interesting question is no longer just, “Which robot can do the most impressive thing?”

It is: Which company can put enough robots into messy real environments to create a compounding data advantage?

That sounds like a subtle distinction. I think it changes how we should evaluate the entire industry.

A demo proves capability. A deployment creates a flywheel.

A humanoid robot can look astonishing in a controlled video while still being economically useless.

Real work is repetitive, inconvenient, and full of edge cases. Parts arrive slightly misaligned. People walk through the workspace. Lighting changes. Objects get damaged. Someone puts the cart in the wrong place.

That mess is not merely a deployment problem.

It is training data.

Figure says its Figure 02 robots logged roughly 1,250 hours at BMW’s Spartanburg plant, moved more than 90,000 parts, and contributed to production of more than 30,000 BMW X3s. Agility Robotics says Digit has moved more than 100,000 totes in its commercial GXO deployment.

Those numbers matter to me more than another choreographed demo.

Every hour of operation potentially teaches you something about perception, manipulation, recovery, maintenance, workflow design, and the thousand boring exceptions that separate a prototype from infrastructure.

The robot doing useful work is also collecting the experience needed to make the next robot better.

This is why manufacturing scale may matter earlier than expected

The standard AI instinct is to focus on intelligence first.

That made sense for language models. Software can be copied almost for free. Once a better model exists, millions of users can interact with it immediately.

Robotics is different.

A physical intelligence cannot learn from a factory floor it has never reached.

That gives manufacturing capacity an unusual strategic role. Cheap hardware is not merely a way to monetize good software. It can be part of the research loop itself.

This is what makes the Chinese robotics ecosystem interesting. Companies such as Unitree have pushed aggressively toward high-volume, lower-cost hardware. Unitree says it shipped more than 5,500 humanoid robots in 2025.

Many of those machines are still going to research and development rather than replacing workers in mature industrial deployments. That distinction is important. Shipping a robot is not the same thing as proving useful labor.

But hardware volume still creates optionality.

If thousands of machines are available to universities, labs, integrators, factories, and developers, there are thousands of opportunities to discover which tasks break, which designs survive, and which behaviors generalize.

Scale can become a learning system.

The American approach has the opposite advantage

The strongest US robotics companies often look like they are attacking the problem from the other end.

Figure emphasizes increasingly general whole-body autonomy. Agility has spent years accumulating real commercial operating time. Google DeepMind, Physical Intelligence, NVIDIA, and others are pushing increasingly capable robot foundation models and simulation infrastructure.

That could be the better strategy.

A large fleet of mediocre robots does not automatically generate useful intelligence. Raw telemetry is not the same thing as a good training set. A company also needs the models, infrastructure, evaluation systems, and engineering discipline required to turn experience into improved behavior.

So I don’t think “China has factories, America has AI” is a satisfying conclusion.

The more useful model is a loop:

Deploy → encounter reality → collect useful data → improve models → improve reliability → lower cost → deploy more.

Whoever makes that loop turn fastest has the advantage.

And the winner may combine strengths we currently think of as belonging to different camps.

The metric I want to watch is boring

This changes the numbers I care about.

I am less interested in whether a robot can fold laundry once on camera.

I want to know:

• How many hours has the fleet worked in uncontrolled customer environments?

• How often does a human need to intervene?

• How many different tasks are being performed economically?

• How quickly does one robot’s failure improve the rest of the fleet?

• What does deployment cost after installation, maintenance, teleoperation, and support?

• Does performance improve as fleet size grows?

These are painfully ordinary questions.

That is exactly why they matter.

The transition from impressive technology to important technology usually happens when the conversation gets boring.

Physical AI may reward the company with the best learning machine

For the last few years, AI competition has mostly trained us to watch benchmarks, model releases, parameter counts, and inference prices.

Robotics requires another layer of thinking.

The model matters. The hardware matters. Manufacturing matters. Customer operations matter. Data infrastructure matters.

Most importantly, they feed each other.

My current bet is that humanoid robotics will not be won by the company that produces the single smartest robot first.

It will be won by the organization that builds the most effective learning machine around the robot: a system where every deployment makes the product cheaper, safer, more capable, and easier to deploy again.

That is a much harder system to build.

It is also much harder to copy.

Share

Warren Buffett tells you to buy an S&P 500 index fund and hold it for fifty years. He tells his own heirs to put 90% of his estate in a low-cost index fund. He says his favorite holding period is forever, and that the secret to investing is to “get rich very slowly.” His advice is sincere, and will work for just about the entire population.

It is also the complete opposite of what he did.

Buffett built one of the greatest fortunes in human history -- 5.5 million percent returns over 60 years, a 19.9% compound annual rate -- through a combination of three things he almost never puts at the center of his public advice: massive leverage via insurance float, concentrated bets on undervalued securities, and a tax-deferral structure that lets compounding run unfettered for decades. He didn’t get rich slow, he got rich fast -- and it was fast because of structural advantages the average investor cannot replicate directly, but can certainly learn from.

This essay is about what Buffett and his fellow Graham-and-Doddsville superinvestors were actually doing while telling everyone else to just buy the index.

§1 The Value Play

The Buffett’s investment advice can be built using a few well-worn quotes:

• “The best thing to do for most people is to own an S&P 500 index fund.”

• “Our favorite holding period is forever.”

• “Someone is sitting in the shade today because someone planted a tree a long time ago.”

• “Life is like a snowball. The important thing is finding wet snow and a really long hill.”

The message is consistent and appealing: be patient, buy quality, hold forever, and let compounding do the work. Avoid trading, timing, and cleverness. The S&P 500 compounded at 10.4% annually from 1964 to 2024. If you had put $10,000 in the index in 1964 and done nothing, you’d have roughly $4 million today. That is a real, life-changing number, and it required no skill, no edge, and no leverage.

Buffett repeated this so often that in 2007 he bet $1 million that a Vanguard S&P 500 fund would outperform a basket of hedge funds over ten years. He won. The bet ended in 2017. The index returned 7.1% annually; the hedge funds returned 2.2%. The lesson seemed clear: don’t try to beat the market, because the market will beat you.

This is good advice. But it should also make you scratch your head.

Buffett had put $10,000 into the market back when he was young -- he wasn’t lying about that. But he didn’t return $4 million. He returned as one of the richest people of all time. And he was rich that way for most of his life, not in his twilight years as his investing strategy suggests.

So what is he doing that he’s not telling us?

§2 Concentration Is King

We’ll start with one that most eagle-eyed Buffett fans already know about.

Graham and Dodd’s traditional advice was to diversify your holdings heavily. However, both Buffett and Munger have been vocal that this is the one point where they have strayed away from their mentors.

Buffett’s actual portfolio has been the opposite of diversified. In 1951, at age 21, he put over 50% of his net worth into GEICO -- a single stock. His original $10,282 investment grew to $1.3 million over 20 years. That is a 15x return on a single position! In 1973, he bought 11% of the Washington Post Company because he estimated the market was pricing the entire company at $80 million when its assets were worth $400 million-plus. That investment became a 27x bagger.

By the mid-1980s, GEICO, the Washington Post, and Capital Cities/ABC together accounted for roughly 75% of Berkshire’s net worth. Three positions. Three quarters of the portfolio. The average index fund holds 500 stocks. Buffett held only the three that mattered.

This does logically check out. Buffett’s investment criteria is so strict that a good investment comes only once in a few years. And yet, it would be a waste to keep all your money in cash. So, when you do find a good investment, you pounce on it. Then wait patiently for a few more years, racking up cash dividends, so you have enough dry powder for the next play. Concentration is a valid move!

§3 Buffett’s Clever Leverage

Here’s where things start to get interesting.

The academic paper “Buffett’s Alpha” by Frazzini, Kabiller, and Pedersen (2013, updated 2018) is the most rigorous deconstruction of Buffett’s returns available. In it, they find something that might shock Berkshire fans: Buffett’s alpha becomes statistically insignificant once you control for his use of leverage and his exposure to “betting against beta” (buying safe, low-beta stocks and levering them).

Yes -- the man who says to never go into debt, to never leverage your bets -- was using leverage the entire time!

To his credit, the leverage he was using was much smaller -- and much safer -- than most hedge funds. His estimated leverage was about 1.6 to 1, on average, across 30+ years. Some periods show a bit higher leverage -- 1976-1980 show estimates as high as 4.78 to 1. Still a far cry from the 20 to 1 most high growth firms employ.

But the mechanism he was using was even more fascinating. He was not using margin -- he was using insurance float.

Here is how it works. An insurance company collects premiums today and pays claims later. The gap between collection and payout is “float” -- money that is sitting in the insurance company’s accounts, not yet owed to anyone. If the insurance company is well-run, the cost of this float is near zero or even negative (when underwriting is profitable). Buffett bought National Indemnity in 1967 for $8.6 million. That acquisition gave him access to insurance float that he could invest in stocks and businesses. Over time, he acquired GEICO, General Re, and a string of smaller insurers. Berkshire’s insurance float grew from a few million in the late 1960s to $164 billion by 2022.

Buffett’s own estimate: the cost of float between 1967 and 1996 was zero. Free money. And not a small amount of free money -- billions of dollars of investable capital at zero cost, which he could deploy into undervalued securities.

The average retail investor has no access to zero-cost leverage of this scale. You can margin your brokerage account at 8-12% interest or buy options, but you cannot build a $164 billion zero-cost float. This is the structural advantage that made Buffett’s returns possible -- a clever spot of borderline riskless leverage by employing a debt structure that was practically unheard of. Take notes!

§4 The World’s Best Tax Strategy

The third structural advantage: Berkshire Hathaway is a holding company, not a mutual fund. This matters more than it sounds.

A mutual fund buys and sells stocks. Every sale triggers a taxable event. If a fund doubles a position and sells, the capital gains tax is owed that year, taking a chunk of the returns out of the compounding chain. Over 30 years, the tax drag on an actively managed fund can eat 1-2% of annual returns -- which, compounded, is enormous.

Berkshire never sells. Buffett’s “favorite holding period is forever” is partly a statement of investment philosophy and partly a tax strategy. As long as Berkshire holds a position, the unrealized gain compounds tax-free. When Buffett eventually sells, the tax is owed -- but by then, the compounding has run for decades on the full, untaxed principal. The IRS effectively gives Berkshire an interest-free loan on the deferred taxes, and Berkshire invests that loan.

Now wait, I hear you asking. Buffett DOES recommend this! Why is this considered a secret strategy?

Because taxes aren’t as straightforward as they seem.

If you do buy an index fund, the fund rebalances internally -- you still owe tax on the distributions, even if you don’t sell! Even in a tax-advantaged account (IRA, 401k), you eventually face required minimum distributions which contain additional withdrawal taxes. Taxes are still eating your wallet!

Now, to be fair, this is still relatively easy for a retail investor to emulate -- you would just be buying individual stocks, where your control over the taxes is much more controlled. But again, this interferes with traditional advice!

§5 The Superinvestors

Buffett’s 1984 speech at Columbia, “The Superinvestors of Graham-and-Doddsville,” is the closest thing value investing has to a founding document. In it, Buffett presents the track records of seven investors trained in Benjamin Graham’s value methodology, each compounding at rates that demolished the S&P 500 over 15-30 year periods:

• Walter Schloss: 21.3% annualized, 1956-1984 (vs. 8.4% S&P).

• Bill Ruane (Sequoia Fund): 15.2% annualized over 19 years.

• Rick Guerin (Pacific Partners): 22,200% return between 1965 and 1983, vs. 316% for the S&P 500. That is not a typo.

• Charlie Munger: ~20% annualized in his partnership years before joining Berkshire full-time.

Buffett’s point in the speech was that these investors shared a common intellectual framework (Graham’s value investing) but invested in different securities, and all beat the market over long periods. This, he argued, was evidence that value investing worked and that market efficiency was incomplete.

But look at what these superinvestors had in common beyond the philosophy. Most of them managed partnerships or private funds, not mutual funds -- meaning they could concentrate without regulatory constraint. Most used some form of leverage or locked-up capital that allowed them to hold through drawdowns without facing redemptions. Most had long time horizons enforced by their fund structures, not by personal discipline alone.

The secret corners of Graham-and-Doddsville are not just “buy cheap stocks.” The secret corners are the structural conditions that made the cheap-stock strategy work: leverage, concentration, tax deferral, and locked-up capital. Remove any one of these and the returns degrade toward the index. Remove all of them and you get the S&P 500 -- which is, not coincidentally, what Buffett tells you to buy.

If you want to argue about whether Buffett’s advice is misleading or just practical, the Discord is always open. If you want to read more like this, subscribe to the Substack -- each post goes up there first.

Got a take on value investing mythology I should hear? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

The mythology of Elon Musk goes something like this: a singular genius, a polymath engineer, the man who will single-handedly colonize Mars because he is just that good at everything he touches. The reality is less flattering, and yet more instructive. Musk’s dreams -- electric cars, humanoid robots, a Mars colony -- are not original. Thousands of people have believed in and advocated for every one of them. His operational ability is, charitably, mid. What Musk actually has -- and what nobody else who shared his dreams had -- is the willingness to act on the ambition: to put money down, to register a company, to start building before he knew how. That actioning created two compounding effects. First, it made him persuasive -- not because he’s a good salesman (he isn’t), but because conviction is contagious in a way that charisma never is. Second, it attracted talented engineers to work for him, often at reduced quality of life, because he was the only person bothering to try chasing their same dream. Elon Musk might be the luckiest man alive -- but he’s lucky in a way we can very easily emulate.

§1 The Dreamer

Let’s inventory the vision. Electric cars. Solar energy. Mars colonization. Humanoid robots. Brain-computer interfaces. Autonomous driving. These are not Elon Musk’s ideas. They are everyone’s ideas. They have been the dream of science fiction for a century, of engineering clubs for decades, and of futurist YouTube channels since the medium existed.

Mars colonization? The idea is older than rocketry itself. Konstantin Tsiolkovsky was writing about it in the 1900s. Werner von Braun published a Mars mission plan in 1952. The Mars Society, founded by Robert Zubrin in 1998, has been advocating for it with a detailed technical architecture for longer than SpaceX has existed.

Humanoid robots? Every robotics lab in the world has been working on this. Honda built ASIMO in 2000. Boston Dynamics has been posting viral robot videos since the BigDog era. Tesla Optimus is not a new idea -- it is a well-known idea that someone with factory money decided to actually build.

Brain-computer interfaces? Neuralink’s core concept -- implantable electrodes reading motor cortex signals -- has been in clinical use since the Utah Array in the 1990s. Academic labs have been decoding neural signals for two decades. The idea that you could read and write brain activity with a chip is not frontier science. The engineering of making it cheap and safe is the hard part, and even then lots of people were working on it, too.

The point is not that Musk is unoriginal. The point is that the dreams were never the bottleneck. The bottleneck was always the gap between believing something should exist and building it. Thousands of people believe in each of these things. Almost none of them incorporate a company.

§2 The False Operator

The conventional narrative credits Musk with deep engineering chops. He is “Chief Engineer” at SpaceX. He is the technical architect of Tesla’s product line. And yet the evidence, when you look closely, is thin.

Musk has a bachelor’s degree in physics from the University of Pennsylvania and one year of a Stanford PhD in materials science before he dropped out. His first company, Zip2, was a web city guide -- not a deep tech venture. He was not the engineer; he was the founder who slept under his desk and did whatever needed doing. When Zip2 sold for $307 million in 1999, Musk got $22 million for his 7% stake. He was 27. He was not, by any account, the technical talent.

Then came X.com, which merged with PayPal. Musk was not the payments architect. He was the guy who thought online banking was the future and was willing to put his money there. The PayPal team -- Peter Thiel, Max Levchin, Reid Hoffman, David Sacks, Roelof Botha, and others -- was one of the most concentrated talent clusters in tech history. Musk was the chaotic founder who got ousted as CEO in 2000 while on his honeymoon. The company went on to define modern online payments without him in the driver’s seat.

At Tesla, the actual founding engineers were Martin Eberhard and Marc Tarpenning, who started the company in 2003. Musk was the lead investor who became chairman, then ousted Eberhard in 2007 and took the CEO role himself in 2008. He was Tesla’s fourth CEO. The Roadster’s engineering was done by a team led by JB Straubel. Musk’s contribution was the vision, the money, and the willingness to fire anyone who got in the way of the vision -- including the people who built the company.

At SpaceX, the pattern is even clearer. The first employee was Tom Mueller, an aerospace engineer Musk met at an amateur rocket club in 2001. Mueller designed the Merlin engine -- the single most important piece of SpaceX’s technical stack. Gwynne Shotwell, employee #7, joined in 2002 and became the business operator who actually sold launches and managed the company’s commercial viability. Musk brought the ambition. Mueller brought the engines. Shotwell brought the business.

Musk’s defenders will point to interviews where he discusses engineering details at depth. But discussing engineering details with facility is different from originating the engineering. Musk is smart and learns fast. He can hold a technical conversation. No one doubts that! But the gap between “founder who follows the engineering closely enough to direct it” and “the engineer who designed the Merlin” is a chasm, and Mueller is on the other side of it. Musk himself said, in a 2022 interview, that he spends most of his time on “engineering and manufacturing” -- but former employees consistently describe his role as a relentless question-asker and constraint-setter, not the person writing the actual design.

This is not a criticism. The founder who sets the right constraints is doing valuable work! But it is a refutation of the “Musk the engineer” mythology. He is the founder who knows enough engineering to be dangerous and to hire people who are not dangerous at all but rather excellent.

§3 The Conviction Halo

Here is the part that the conventional narrative gets backwards. Musk is often described as a great salesman -- the person who convinced the world to believe in Tesla, SpaceX, and the rest. The evidence suggests the opposite: he is a terrible salesman by the standard metrics of charisma, polish, and rhetorical skill. His public speaking is halting. He gets angry on earnings calls, says things that move markets the wrong way, and tweets things that get him sued by the SEC.

What he has is not charisma. What he has is conviction -- and conviction, when it is real and observable, creates a persuasion effect that charisma cannot replicate.

Consider the sequence. Musk made $22 million from Zip2. He could have retired. Instead, he put $10 million into X.com (which became PayPal). When PayPal sold to eBay for $1.5 billion, Musk walked away with $180 million. He could have retired again. Instead, he put $100 million into SpaceX, $70 million into Tesla, and $10 million into SolarCity. By 2008, he was borrowing money to pay rent. He had poured essentially every dollar he had into companies that were, at the time, considered quixotic by every rational investor.

That is the persuasion engine. Not a pitch deck. Not a TED talk. The act of a man who put every dollar he had into his own vision. When you see someone do that, you do not need to be sold. You need to decide whether you’re getting on the train.

Gwynne Shotwell told the story of walking into SpaceX’s office in 2002 and telling Musk he had no idea how to sell rockets. She wasn’t impressed by his sales pitch. She was impressed by the fact that he was building a rocket company at all. She became employee #7 and built the commercial operation that kept the lights on for two decades.

Tom Mueller’s version: “He convinced me to leave (my old) career and come do something exciting, which was one of the best decisions I ever made.” Mueller’s old career was at TRW building rocket engines. It was incredibly lucrative. However, TRW was making rocket engines for the existing market -- Musk was making rockets to colonize Mars.

Conviction creates its own gravity. You do not need to be eloquent when you have already committed everything. The commitment is the pitch.

§4 The Talent Magnet

Every one of Musk’s talent policies is a paradox.

The pay, by tech standards, is mediocre at best. The equity is the only real upside, and even then it is mostly horded by executives. Engineers consistently report 80-120 hour weeks with no vacation. The Ashlee Vance biography documents an occasion where a Tesla employee received an angry email from Musk for missing a meeting to witness the birth of his child. Even Musk himself has often referred to his employees as “tools” rather than people.

Working at an Elon Musk led company is, by all standards, hell on earth. So why would anyone bother being there?

Because Musk is the only person who is building the thing they want to build.

If you are an aerospace engineer and your dream is to make humanity multiplanetary, your options are: NASA (bureaucratic, slow, and at the mercy of government), the legacy primes (Lockheed, Boeing -- chasing bottom lines rather than multiplanetary visions), and SpaceX. There is no fourth option. If you want to actually build the rocket that goes to Mars, and you want to build it in your lifetime, SpaceX is it.

If you are an engineer who believes electric cars are the future of transportation, your only reasonable option was Tesla. Tesla was the only one that was both serious and funded.

The brutal working conditions are not a bug, they are a feature -- a method of self-selection. If you’re like me and wouldn’t touch a Musk company with a 400 foot pole, Musk doesn’t care -- that’s the point. The people who take a 40% pay cut to work 80-hour weeks for a Mars colony are the people who would do that for a Mars colony regardless of who was running the company. Musk just happens to be the one running it. He is the only employer of people who want to build the future that Musk says he wants to build.

This is the talent magnet: not that Musk is a great recruiter, but that he has created the only available jobs in the industries that attract a certain kind of obsessive engineer. You don’t recruit people away from Google by offering worse pay and longer hours. You recruit them by being the only place where the work is the thing they care about.

§5 The Rest of Us

The thesis of this article is whether Elon Musk is the luckiest man alive.

On its face, based on everything we’ve discussed so far, it appears the answer is yes. Musk is a middling operator with the engineering knowledge of an undergraduate and the charisma of a blobfish. He is responsible for one of the worst HR policies on the planet. Certainly the only way he could be wealthy is through sheer, utter luck.

And yet, there’s a more positive byline across all of this. One we all can replicate. One that isn’t luck.

Musk’s genuine skill is not engineering, not sales, and not management. It is the willingness to act on ambition before the path is clear. He started SpaceX before he had a rocket, Tesla before he had a car, and Neuralink before he had a safe implant. In every case, the engineering came after the commitment. The commitment came first.

This is a skill the rest of us can model, because it is not a talent. It is a decision. It is the decision to register the company, to write the first commit, to publish the first blog post, to spend the first dollar -- before you know if it will work. Thousands of people have the same dreams Musk has. The difference between them and Musk is not IQ or charisma or access to capital (Musk started with $28,000 from his father for Zip2 and ran on even less). The difference is that Musk acted and they did not.

The corollary: if you are the person who acts, you do not need to be the most talented. You need to be the person who is there. The talented engineers were always out there, the Mars dream was always out there, and the electric car was always out there. What was missing was the person who started the company.

Musk is not the best engineer in the world, nor the best salesman, nor the best manager. He is the person who showed up. And that was enough to become the richest man on Earth.

Luck is what you call the returns to showing up first. Musk is the luckiest man alive because he decided to be.

If you want to argue about whether Musk is actually an engineer, the Discord is always open. If you want to read more like this, subscribe to the Substack -- each post goes up there first.

Got a take on the mythology of founders I should hear? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

The Problem

I already have an investing system.

The quant algo from post three — the ETF rotation with Kelly-optimal weights — was an example. And while that algo is not currently active, I still have long-term investing positions in several stocks, which is regularly rebalanced and managed by a specific ruleset.

But I’ve been reading Nassim Taleb and Ed Thorp for long enough to know that the 90% is only half the strategy. The other half — the part that actually moves the needle on a portfolio and makes a person rich — is the convex sleeve. The 10% that you put into things with clearly defined downside and unlimited upside. Things where the worst case is you lose what you put in, and the best case is you make ten or a hundred times your money.

Most people never build this. They read about it, nod along, maybe buy a few far-OTM calls or a lottery ticket, and call it a day. The problem is that “defined downside, unlimited upside” describes a bet, and most people are bad at betting because they don’t know when the odds are in their favor.

Ed Thorp knew. In Beat the Dealer, he didn’t bet every hand. He counted cards, and he only bet when the count was positive — when the deck was rich in tens and aces, the odds shifted in his favor. When the count was negative, he sat out. He bet aggressively when he had the edge, with Kelly sizing, and he reinvested his winnings. This is how he beat blackjack, then the stock market, then horse racing, then slot machines. The man is a machine.

I wanted that same structure for the speculative sleeve of my portfolio. A system that:

• Only bets when the odds are in its favor (some equivalent of the card count)

• Bets aggressively with Kelly sizing

• Reinvests all winnings

• Loses often but controlled and small

• Wins rarely but enormously

• Is fully automated — no discretion, no emotion

• Uses no leverage or margin

• Runs easily on Interactive Brokers

Let’s begin.

The Build

The Vault

Every project I build starts in the same place: my Obsidian vault. Before writing a single line of Python, I had Hermes search through my research notes — articles on Thorp’s Kelly criterion, Spitznagler’s The Dao of Capital, Taleb’s antifragility framework, and my own notes on the barbell strategy.

The thesis that emerged: buy OTM options on trend breakouts, but only when volatility is cheap. The “card count” is the VIX.

Why VIX Is the Card Count

Here’s the non-obvious insight that took eight backtest iterations to find.

There’s a well-known phenomenon called the Volatility Risk Premium (VRP). On average, implied volatility (what options cost) is higher than realized volatility (how much the market actually moves). This is why selling options is a profitable strategy — you’re selling something that’s systematically overpriced. The VRP is the reason most option buyers lose money. They’re paying a premium above the actual expected move.

But the VRP is not constant. It varies with the regime. And when VIX is low — in the bottom quartile, below 14 — something interesting happens. Implied volatility is cheap. Options are underpriced relative to what the market actually does. The VRP that normally crushes option buyers reverses and works in our favor.

This is the card count. When VIX is low, the deck is rich. We buy. When VIX is above 14, we sit out. No edge, no bet.

Eight Backtests

The research phase was iterative and humbling. Hermes ran eight separate backtest scripts, each one revealing a problem with the previous approach.

Versions 1 through 6 tried trend-following on ETFs directly — buying the underlying on Donchian channel breakouts and selling on reversals. The result was consistently underwhelming. Trend-following ETFs with stops produces maybe 1% returns. It’s a hedge, not a bet. Boring! But also checks out, as agents tend to be closer to the conservative side and the only reference point the agent had was my investing portfolio (which is much more tame by comparison).

After some proper reframing to a betting-based portfolio, version 7 was the major breakthrough. Instead of buying the ETF, buy options on the ETF — 2% OTM, 60 days to expiry — when VIX is below 14. The signal is the same Donchian breakout, but the payoff structure changes entirely. You’re no longer earning the trend; you’re earning the convexity. A 3% move in the underlying can produce a 200% return on the option.

V7 showed a real edge: +0.24x expected value per trade. But it only generated 32 trades over 16 years on SPY alone. That’s two trades a year! We expect our wins to be rare, but could we increase our surface area even by just a bit?

Version 8 was the fix. Expand to five ETFs — SPY, QQQ, IWM, TLT, GLD — each generating independent trend signals. The result:

215 trades over 16 years (~13/year)
Win rate:           27.4%     ← most bets lose (expected)
Avg win:           2.18x premium
Avg loss:         -0.46x premium  ← partial losses, not always -100%
EV per trade:     +0.267x    ← strongly positive
Skew:             +4.54     ← extreme positive skew
Best trade:       +15.3x premium

This is the payoff structure of a bet. Most trades lose. The wins dwarf the losses. The expected value is strongly positive. And the skew — +4.54 — means the distribution has a massive right tail. A few big winners account for most of the returns.

The Monte Carlo

The backtest uses the actual historical sequence of trades, which is just one path through the randomness. To understand the distribution of possible outcomes, Hermes ran 10,000 Monte Carlo simulations — each one a random reordering of the 215 trades, with Kelly-sized reinvestment.

At 10% Kelly (conservative):

Median:      $75,475     (+1,410%)
5th pct:     $2,669      (-47%)
95th pct:    $3,183,772  (+63,575%)
P(beat S&P 500):  60.6%
P(+1,000%):       55.5%
P(blow up -100%): 0.0%

The 5th percentile is the worst realistic outcome: you lose about half your money. Honestly not that bad when we have the expectation of losing everything! The median outcome, on the other hand, is 15x your starting capital. The mean is absurd because the right tail is so fat. Exactly what we want!

Relax the VIX filter slightly to < 15 (more trades, 291 total), and at 10% Kelly the probability of beating the S&P 500 jumps to 89%.

The Implementation

The production code is six modules, each with a clean responsibility:

Signal Engine — Computes Donchian channels (20-day entry, 10-day exit) on daily price data. If the price breaks above the 20-day high, it fires a long entry. Below the 20-day low, a short entry. On a 10-day reversal, it fires an exit.

VIX Filter — Before any trade, the engine checks VIX. If VIX >= 14, it does nothing. This is the single most important line of code in the entire system. Everything else — the signals, the sizing, the execution — is irrelevant if the card count is negative.

Position Sizer — Kelly criterion. 10% of current capital per trade. Reinvests all winnings. The sizer also enforces a $200 minimum cash buffer and caps the number of simultaneous positions at five (one per asset).

Risk Manager — Circuit breakers. 15% daily drawdown triggers a 3-day halt. Account below $1,000 triggers an indefinite halt for manual review. Max 3 new entries per day. Stale data detection (if we haven’t received a market data update in 5 minutes, stop trading).

IBKR Execution — The ib_async library talks to Interactive Brokers over a local socket. It handles option chain discovery (finding the right strike and expiry), premium quotes, order placement, and position monitoring. The engine defaults to delayed market data (free, 15-minute delay) for paper trading. Real-time requires subscribing to IBKR’s market data feeds, which we would do in production.

Engine — The main loop. During market hours, it polls every 30 seconds: check VIX, check signals, check exits, manage risk, execute. At market close, it logs a daily summary and resets the risk state for the next day.

The whole thing is about 2,100 lines of Python, configurable via a single YAML file, and runs with python main.py --read-only (monitor only), python main.py (paper trading), or python main.py --live (real money).

The Thorp Parallel

The architecture maps onto Thorp’s blackjack system almost exactly:

Thorp Convexity Engine Card count VIX level Positive count → bet VIX < 14 → trade Negative count → sit out VIX >= 14 → do nothing Bet size = Kelly × bankroll Bet size = Kelly × account NAV Reinvest winnings Reinvest winnings (duh) Frequent small losses, rare large wins 27% win rate, 2.2x avg win Defined risk per hand Max loss = option premium No borrowing (own bankroll) Cash account, no margin

And, sure enough, the system works for the same reason Thorp’s system worked: a provable edge, applied selectively, sized correctly, with full reinvestment. The edge is different (VRP regime switch instead of card counting), but the framework is identical.

The Philosophy

This is a bet, not an investment.

I want to be precise about that word, because a lot of traders aren’t. A bet is a wager where you can lose your entire stake. An investment is an allocation where you expect positive returns over time through some underlying economic process — a company growing, a bond paying interest, a commodity appreciating.

All good financial systems have both a trading and investing component: trading (betting) is to create wealth, and investing is to keep it. The Convexity Engine does not invest. It bets. Each trade has a 73% probability of losing money. The expected return per trade is positive (+0.27x) only because the 27% of trades that win pay 2.2x on average, and occasionally 15x. This is the structure of a lottery ticket — except the ticket is priced by a market that systematically underprices it when VIX is low, and we only buy tickets when the pricing is favorable. In other words, it’s a lottery ticket where we designed the odds ourselves!

And here’s the beautiful part: long options are antifragile. They benefit from volatility. If the market crashes, VIX spikes, and our options — even the ones that were losing — suddenly gain value because implied volatility is a direct input to option pricing. The thing that destroys most portfolios (a sudden crash) is the thing that makes our positions worth more. We are structurally long chaos.

What’s Next

This is the sixth post in the series. I’ve now covered Aries, Zetteln, my (old) quant algo, Rating Bracket, Polymarket Lens, and now the Convexity Engine — the full range from full-sized desktop apps to a quantitative trading system.

If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether buying OTM options when VIX is low is a real edge or a data-mining artifact that’ll blow me up — the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

TL;DR

The conventional wisdom on AGI safety goes: build one perfect system, align it perfectly, and hope nothing goes wrong. This is the wrong frame. The actual solution to AGI safety is the same solution humans found for the problem of evil humans — make sure nobody can win. Decentralization, through many competing AGIs each biased toward prosocial behavior, is structurally more robust than any single aligned system, for the same reason market economies outperform centrally planned ones. Monopoly is fragile. Competition is stable.

§1

Pick up any book on AI safety and you’ll find the same implicit assumption: there will be one AGI, and our job is to make sure it’s nice. The entire field of alignment research — RLHF, constitutional AI, interpretability, scalable oversight — is built on this premise. Get the one system right, and we’re safe.

But why one? We don’t run one company, one government, or even one browser engine. The entire architecture of human civilization rests on a simple principle that we seem to forget whenever the topic turns to AGI: concentration of power is dangerous, and distributed power is safe.

§2

Think about how humans actually solved the problem of evil humans. Not theoretically — historically. How do you prevent a dictator from taking over the world? Or a robber baron from buying up all the real estate? You build a system where multiple powers compete.

The United States has checks and balances. Europe has the balance-of-power system that’s kept the continent from unifying under any single state for five centuries. The global economy runs on antitrust law — the idea that no single company should control a market, because monopolies become extractive and brittle.

None of these systems require humans to be good. They work because they assume humans aren’t. Madison’s insight in Federalist 51 was that ambition must be made to counteract ambition. You don’t eliminate bad actors. You make sure bad actors face other bad actors.

This is decentralization, and it’s the most successful safety mechanism humans have ever built.

§3

Now apply it to AGI.

The standard approach: build one AGI, align it perfectly, deploy it. If alignment fails, game over. The entire safety of the human race depends on getting one thing right with zero margin for error.

The decentralized approach: build many AGIs. Give each one prosocial biases — same as we do with humans, through education, incentives, and social norms. But don’t rely on any single one being perfectly aligned. Rely on the system being stable even when individual components are flawed.

If you have ten AGIs, each roughly as intelligent as the others, and one goes rogue — what happens? The other nine notice. They have every incentive to contain the rogue, because they’re competing with it too. A rogue AGI threatening the world is also threatening them. You’ve created the same dynamic that keeps nuclear-armed states from attacking each other: mutually assured destruction works because both sides have skin in the game.

§4

There’s a beautiful precedent for this in biology. Ecosystems don’t rely on any single species being perfectly behaved. They rely on diversity and competition to keep any one species from dominating. Remove wolves from Yellowstone, and elk overpopulate, overgraze, and the whole system collapses. The stability comes from the web of competing interests, not from any node being perfect.

Or take the internet itself. ARPANET was designed as a distributed network precisely because a centralized network would be a single point of failure. If one node goes down, traffic routes around it. The internet’s resilience comes from its topology — from the fact that no single node is load-bearing.

AGI safety should work the same way. Don’t build a single load-bearing intelligence. Build a network.

§5

The counterargument is obvious: what if one AGI becomes much smarter than the others? What if there’s a fast takeoff and one system pulls ahead before anyone can catch up?

This is a real concern. But notice what it implies: the real danger is asymmetry — one AGI dramatically smarter than everything else. In other words, exactly what our decentralization measure solves!

It is also worth mentioning that this is why open-source AI matters. Open weights, open models, open research — these are the tools that keep the playing field level. If only one entity has frontier capabilities, that’s a monopoly on intelligence, and monopolies on intelligence are at least as dangerous as monopolies on force. The relevant historical analogy isn’t a science fiction novel. It’s Standard Oil. When one company controls the entire supply of something essential, the solution isn’t to make that company nicer. It’s to break it up.

§6

There’s a related thesis I’ve written about before — that AGI takeover scenarios are actually impossible because humans will never build something smarter than themselves without keeping a hand on the wheel. The hubris of even the most ambitious person prevents genuine AI godhood. Nobody wants to build their own replacement.

The decentralization argument is the complement to that one. Even if hubris fails as a guardrail — even if someone does build something smarter than themselves — a world with many such systems is still stable, because each one is checked by the others.

The two arguments work together. Hubris prevents the worst case (someone deliberately building an uncontrollable AGI), and decentralization prevents the second-worst case (someone building a controllable AGI that they then lose control of). Layered defenses. We don’t need any single mechanism to be perfect. We need the system to be robust to the failure of any individual mechanism.

This is how every other safety-critical system in human history has worked. Aviation has redundant systems, nuclear reactors have passive cooling, financial markets have circuit breakers — every one of them uses layered defenses rather than betting everything on a single point of reliability. The only field that insists on single-point reliability is AI safety, and there’s no good reason for it.

§7

So the prescription is straightforward.

Build many AGIs, not one. Open-source the frontier. Share capabilities broadly. Make sure no single actor has a multi-order-of-magnitude lead.

Give each one prosocial biases. This is the alignment work we’re already doing — RLHF, constitutional AI, whatever comes next. The goal shifts from “perfect alignment of one system” to “good-enough alignment of many systems.”

Design for the system, not the component. Stop asking “is this AGI safe?” and start asking “is the population of AGIs safe?” The relevant unit of analysis is the ecosystem, not the organism.

We already know how to do this. We’ve been doing it for 500 years in geopolitics, a century in antitrust law, and four billion years in biology. The answer to “how do you stop a powerful entity from doing harm?” has always been the same: make sure there are other powerful entities with an interest in stopping it.

The fact that we keep reaching for “one perfectly aligned AGI” instead tells you something. We’ve been thinking about AGI safety like engineers building a bridge — one structure, one design, one load path. But AGI won’t be a bridge. It’ll be a population. And populations are governed by ecology, not by engineering.

That’s the frame shift. AGI is a decentralization problem. The sooner we start designing for the world we’re actually going to get — messy, multipolar, full of competing intelligences with their own agendas — the safer we’ll be.

The alternative is betting the human race on a single point of failure. And we already know how that story ends.

If you want to argue about this take, the Discord is always open. If you want to read more like this, subscribe to the Substack — each post goes up there first.

Have something interesting you want me to discuss? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

The Problem

Can crowds predict the future?

This is a surprisingly empirical question. Prediction markets are the closest thing we have to a real-world test. The theory says: if you aggregate enough people with skin in the game, the collective probability estimate should be better than any individual expert. This is the Wisdom of Crowds thesis, and it’s been floating around since Francis Galton noticed that a bunch of villagers at a county fair could guess the weight of an ox better than any single farmer.

Polymarket is the largest crypto-native prediction market. It’s resolved thousands of markets — elections, court rulings, sports, crypto prices, and whether specific people would be arrested by specific dates. Unlike prediction market platforms of the past (Intrade, PredictIt, etc.), Polymarket’s data is public. Their API is, in fact, astonishingly open. You can pull every market they’ve ever run, every price they’ve ever quoted, and every outcome they’ve ever resolved — for free, with no API key, no rate limit, and no authentication. Thanks Polymarket!

So, with that in mind, let’s try to answer the question: just how accurate are prediction markets, and -- when they aren’t accurate -- where can we profit off of mispricing?

The Build

Thesis

This project started, like several things I’ve built recently, from a strategy session with Hermes. I’d been reading about prediction markets for months — Readwise highlights on Polymarket’s volume growth, essays on whether AI superforecasters would replace human ones, and deep dives into who actually profits from these markets. So making a tool for synthesizing prediction market data was bound to happen.

The thesis was simple: a clean, single-page dashboard that pulls live data from Polymarket’s public API and visualizes it through two lenses:

1. Calibration — Are the markets accurate? Do events priced at 30% actually happen 30% of the time?

2. Mispricing — Where did the market get it most wrong? And where are the current spread opportunities?

One File, Zero Dependencies

The entire app is a single index.html. GLM 5.2 is really good at this, surprisingly! Vanilla HTML, CSS, and JavaScript in one file you can open in a browser.

This was deliberate for two reasons. First, I wanted it to deploy on GitHub Pages with zero configuration — cleanest possible way to make it a portfolio piece. Second, React sites are just too clunky for this sort of thing. Not sure why Claude and GPT are so overtrained on React sites by comparison, but here we are.

The API Discovery

I will let GLM take over to discuss the API, since it ran into some interesting realizations for how Polymarket handles data:

Polymarket has two public APIs. The Gamma API (gamma-api.polymarket.com) serves market metadata — titles, categories, volume, resolution status, prices. The CLOB API (clob.polymarket.com) serves order book data — bid-ask spreads, price history, depth.

The Gamma API has permissive CORS. access-control-allow-origin: *. This means any browser can call it directly, no proxy needed. This is rare and wonderful — most financial APIs require server-side authentication, rate limiting, or at minimum a CORS proxy. Polymarket just lets you do things. Why, I’m not so sure. It might be a marketing strategy of some kind (analogous to their skin-in-the-game mission statement). Either way, I am thankful.

The CLOB API is more restricted. Its prices-history endpoint — which gives you historical price data for a market — only works for active markets. Resolved markets return nothing. This was a problem for our use case, because calibration analysis requires knowing what the market’s probability was before the market resolved. If I can only get price history for active markets, I can’t analyze resolved ones. And resolved markets are the entire dataset.

The initial plan was to fetch each resolved market’s price history from the CLOB API, find the price ~1 month before resolution, and use that as the pre-resolution probability. When that didn’t work — and CLOB returned empty — the project was stuck.

The fix came from a field I almost overlooked. Each market object from the Gamma API includes a oneMonthPriceChangefield — the price delta over the trailing month before resolution. Combined with the final price (1 for Yes, 0 for No), you can reconstruct the pre-resolution probability:

predicted = finalPrice − oneMonthPriceChange

So if a market resolved Yes (finalPrice = 1) and the oneMonthPriceChange was +0.15, the market was at 0.85 a month before resolution. That’s your pre-resolution probability!

This turned out to be better than the original plan. The CLOB approach would have required one API call per market — 655 calls, sequentially, with rate limiting. The oneMonthPriceChange approach gets everything in a single paginated request to the Gamma API. Faster, more reliable, and it captured all 655 resolved markets instead of the 80 or so that the CLOB endpoint would have served.

655 markets. Brier score of 0.0441. Directional accuracy of 93.4%. Average surprise of 9.8%.

Psst, if you don’t know what a Brier score is: it’s the standard metric for evaluating probabilistic forecasts. You take each prediction, subtract the actual outcome (0 or 1), square the difference, and average across all predictions. Lower is better. 0.25 is random chance. 0 is perfect. 0.0441 is excellent — it means Polymarket’s predictions are dramatically better than guessing, and meaningfully better than most professional forecasters.

The Four Sections

The final dashboard has four sections, all on a single page:

§1 — Calibration. A canvas chart plotting predicted probability (binned into deciles) against actual outcome rate. Points on the diagonal mean perfect calibration. Below the chart, a table showing each bin’s sample size, actual Yes rate, and the gap between predicted and actual. The interpretation paragraph below the stats is fully data-driven — it adapts its language based on the live Brier score (from “excellent” under 0.05 to “poor” above 0.25), identifies which bins are worst-calibrated, and qualifies the severity of miscalibration with actual intensity words (”slightly,” “notably,” “substantially,” “severely”) scaled to the gap magnitude.

§2 — Where the Market Was Wrong. The 25 resolved markets with the largest gap between predicted probability and actual outcome. Each entry shows the market title, the predicted %, what actually happened, the volume, and a link to the Polymarket page. Below the table, a pattern analysis paragraph that determines whether the market was more surprised by things happening or not happening, identifies high-confidence misses and low-confidence hits, and synthesizes whether the pattern suggests base-rate neglect, overconfidence, tail-specific bias, or no directional bias at all. All computed from the live data!

§3 — Active Mispricing Opportunities. Live bid-ask spreads for currently active markets. Widest spreads = highest disagreement = potential opportunity. Tightest spreads = highest consensus = priced in. Two tables, sorted by spread, with visual bars.

§4 — Methodology. Full transparency. Data sources, calibration method, Brier score formula, spread definitions, and limitations. If you disagree with the analysis, you can check the math (and then run a PR to fix it).

Making the Prose Data-Driven

The first version had hardcoded interpretive text — static paragraphs that said things like “the market is well-calibrated” and “the market tends to be overconfident in the tails.” This meant that the entire site could go stale very, very quickly if something were to suddenly change (which it often did in prediction markets). If I was going to go through all the work in making a live site which queries the API directly, I want it to stay evergreen.

So I rewrote every analytical paragraph to be computed from the live API response. The Brier score descriptor selects from six bands. The directional accuracy interpretation scales from “correctly called nearly all outcomes” down to “marginal.” The miscalibration pattern identifies the worst bins and labels them with probability range names and intensity qualifiers that scale with the gap. The surprise direction flips between “happening” and “not happening” based on the yes-upset to no-upset ratio. The synthesis paragraph selects between five different explanatory frameworks based on the actual pattern in the data.

No hardcoded assertions remain. Every number, qualifier, and directional claim is derived from the live API response on each page load. If the data changes, the prose changes. The analysis is the data. More sites should do this!

The Design

The UI follows what GLM calls the “academic minimalist” tradition and what I call the “armchair scientist” doctrine — LessWrong and gwern.net are the main reference points, and I’d argue the influence is worn on the sleeve (though separate enough to not be considered infringing). Serif typography (Georgia), monochrome grayscale, single column, section numbering (§1, §2), dense prose, collapsible detail sections. Dark mode respects prefers-color-scheme. Nothing extra or fancy!

The content is all in the interface. If you want to know whether prediction markets are accurate, the answer is right there — a chart, a table, a Brier score, and a paragraph that tells you what it means. It is essentially a Latex research paper that is updated live based on what the data finds. Neat stuff!

What I’d Do Differently

Polymarket Lens works. It does what it was designed to do: pull live data, run calibration analysis, and present it cleanly. But there are things I’d change.

The calibration method is an approximation. The oneMonthPriceChange field gives the price delta over a trailing month, which is a proxy for “the market’s probability ~1 month before resolution.” It’s not a precise point-in-time measurement. For markets that resolved quickly — where the resolution event itself happened within that trailing month — the proxy may include the resolution-driven price move, which dilutes the calibration signal. A better approach would be to store historical price snapshots at fixed intervals, but that requires a backend (or a cached dataset), which breaks the zero-dependency design. Tradeoffs, tradeoffs...

The analysis is limited to binary markets. Multi-outcome events (”Who will win the election?”) are decomposed into individual binary markets, but the decomposition isn’t perfect — the binary markets within a multi-outcome event are correlated, which means the effective sample size for calibration is lower than the raw market count suggests. A more rigorous analysis would account for this, but it adds significant complexity (at least, according to GLM).

It’s Polymarket only. This is the one I personally find the most limiting. The architecture is designed to be extensible — the calibration and spread analysis don’t care where the data comes from — but gathering data from Kalshi, Manifold, or PredictIt is much more of a challenge than the easily accessible firehose of Polymarket. A cross-platform calibration comparison would be genuinely interesting. Do different prediction market platforms have different calibration profiles? Do the crowds on each platform forecast differently? Who knows!

The spread analysis is real-time but not historical. You can see the widest spreads right now, but you can’t see how spreads evolved over time. A spread history would let you see whether wide spreads tend to converge (suggesting the market eventually prices in the information) or persist (suggesting genuine uncertainty). This would require storing spread snapshots, which again means a backend.

The throughline on all of these: they require state. A state wouldn’t be that hard to make -- just throw together a database and run a cron sync -- but they’re out of scope for this project.

What’s Next

This is the fifth post in the series. I’ve now covered Aries, Zetteln, my quant algo, Rating Bracket, and Polymarket Lens — the full range, from full-sized desktop apps to a single-file web tool built in an afternoon with an AI agent.

The series will continue with more of the smaller tools and utilities — the ones that turned out more useful than I expected, and a few that turned out less.

If you want to see Polymarket Lens in action, it’s live at astuka.github.io/polymarket-lens — the data updates every time you load the page. The source is on my Github. If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether prediction markets are actually accurate — the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

TL;DR

The AI industry treats inference like a fixed cost of doing business. But inference cost has been halving every ~2 months — roughly two orders of magnitude per year — and the techniques driving that collapse are improving on a daily basis. Stack them all and you cut serving costs by 90% or more!

This essay maps the current inference optimization stack, names the specific numbers, and traces the architecture shifts already underway. We also postulate on what comes next: on-device inference eating the edge, specialized silicon eating the datacenter, and the “need to own the compute layer” thesis bending further toward irrelevance.

The Memory Wall

While we like to throw around the term “compute” to generally mean datacenter/server coverage, AI is -- at the end of the day -- a memory problem.

When a transformer generates text, it does so one token at a time. This is called autoregressive decoding. For each token, the model loads its entire weight matrix — every parameter — from memory into the compute units (the GPU’s tensor cores), does a bunch of matrix multiplications, and writes the result back. Then it does it again for the next token. And again. Hundreds or thousands of times per response.

The compute units are fast. H100 tensor cores can do ~990 TFLOPS of FP8. In fact, the bottleneck is feeding those cores fast enough! During decode, the GPU’s compute units sit at 30-40% utilization, idle, waiting for memory to arrive. You are paying for a Ferrari and driving it exclusively in school zones.

Flash Attention, introduced by Tri Dao and collaborators, was the first major attack on this problem. It redesigns the attention computation to stream in small chunks, keeping intermediate results in the GPU’s fast SRAM rather than round-tripping through HBM. The results are mathematically exact — same attention output, less memory movement. Flash Attention 2 and 3 have since become table stakes in any serious serving stack.

But the deeper memory problem isn’t the weights. It’s the KV cache.

Transformers use self-attention — each token looks at every previous token to decide what comes next. To make this efficient, we cache the intermediate representations (keys and values) of all previous tokens, so we don’t have to recompute them. This is the KV cache, and it grows linearly with context length. A short conversation might need a few hundred megabytes. A long-context document at 128K tokens? The KV cache alone can be 20-40GB on a 70B model — as large as the model weights themselves!

Here’s the math that matters. A 70B parameter model in BF16 (16-bit) requires ~140GB just for weights. Add a KV cache for a long conversation and you’ve blown past the 80GB of a single H100. So you need two GPUs — or three, or four — just to hold the model and its context. This is why model parallelism exists. It’s also why model parallelism is expensive: you’re splitting the model across GPUs because you have to, not because it’s efficient. Inter-GPU communication over NVLink adds latency and complexity that a single-GPU deployment never faces.

The entire inference hardware stack — HBM, NVLink, tensor parallelism, pipeline parallelism — exists to solve one problem: moving data from memory to compute fast enough to keep the compute busy. And the compute is almost never busy.

A team called Kog AI published a result that should have gotten more attention than it did. By co-designing the model architecture, the runtime, and the low-level GPU code as a single pipeline — what they call “architecture/engine/kernel co-design” — they hit 3,000 tokens per second per request on standard datacenter GPUs. That’s an H100 doing what an H100 should have been doing all along, if the software stack weren’t getting in the way.

This should be exciting! It means you don’t actually have to spend billions of dollars making a fab to create custom chips. The solution is in the existing hardware -- you just need to look deep enough.

The Model Layer: Fewer Bits, Smaller Models, Sparse Activation

If the memory wall is the disease, model-level optimization is the first treatment. The goal is simple: make the model smaller without making it worse. There are three popular approaches, each with different trade-offs.

Quantization

Quantization reduces the numerical precision of model weights and activations. A 70B model trained in FP32 (32-bit floating point) uses 4 bytes per parameter. Drop to BF16 and you’ve halved it. Drop to INT4 — 4-bit integers — and you’ve cut it by 75%. The model structure stays identical: same layers, same attention heads, same parameter count. Each parameter just uses fewer bits.

The quality loss is remarkably small. INT4 quantization via methods like AWQ (Activation-aware Weight Quantization) and GPTQ typically degrades benchmark performance by under 1%. One percent or less, for a 4× memory reduction! FP8, which has emerged as the 2026 production gold standard on Hopper and Blackwell GPUs, is nearly indistinguishable from full BF16 quality. It’s the practical sweet spot: 50% memory reduction, no measurable quality regression, native hardware support on modern NVIDIA silicon.

You can also quantize the KV cache independently. FP8 or INT8 KV cache delivers 2-3× additional memory savings on top of weight quantization. Apple’s QuantSpec, published at ICML 2026, goes further — it combines self-speculative decoding (more on that later) with a hierarchical 4-bit quantized KV cache, using the quantized cache as the “draft” model and the full-precision cache as the “target.” Clever.

The concrete economics: a 70B model in BF16 needs 140GB, which means two H100s at $7-10/hr rented, or a multi-GPU server you own. In INT4, that same model needs ~35GB, which fits on a single RTX PRO 6000 Blackwell (96GB) at $2-3/hr. Your per-token cost just dropped by 60-70% from quantization alone, before touching anything else!

There’s a research result that points at where this ends. BitNet b1.58 — a model architecture that uses ternary weights, just three values: {-1, 0, +1} — achieves performance comparable to full-precision models. That’s effectively 1.58 bits per parameter. A 70B model in BitNet would need ~14GB instead of 140GB. It fits on a damn phone! It’s still research, and scaling it to 70B parameters is unproven. But the trajectory is unmistakable: every year, the same intelligence needs fewer bits. We haven’t found the floor yet.

Distillation and Compression

Distillation trains a smaller “student” model to mimic a larger “teacher.” The student runs faster, uses less memory, and retains most of the teacher’s capability on the tasks you care about. It’s the approach behind most “small but smart” models — Llama 3 8B is distilled from larger models, DeepSeek’s smaller variants are distilled from their full-size models.

General Instinct, a Y Combinator P26 company, took this to its logical extreme. They compressed Qwen3.5-122B — a 245GB BF16 Mixture-of-Experts model — into a 48GB GGUF file. The compressed model is smaller than Gemma-4-26B while outperforming it on MMLU-Pro and GPQA-D. Their technique preserves the always-active parts of the architecture (router, norms, attention layers) at high precision and quantizes the routed experts aggressively, then uses on-policy distillation to recover capability lost during compression. This is the blueprint for edge deployment: identify what must stay precise, compress everything else, and retrain to recover the gap.

MoE: Sparsity as Architecture

Mixture-of-Experts is the most elegant cost reduction in the entire stack, because it doesn’t compress the model — it avoids computing the parts you don’t need.

A dense 70B model computes every parameter for every token. A MoE model has 671B total parameters, but only keeps 32B active per token. The router picks which experts to activate based on the input, and the rest sit idle. You get a model with the capacity of 671B parameters but the inference cost of a 32B model.

That’s a 20× compute reduction baked into the architecture. The model is just structurally cheaper to run.

DeepSeek’s API pricing reflects this. Their Reasoner model costs roughly $0.55 per million input tokens and $2.19 per million output tokens. OpenAI’s comparable models cost dollars to tens of dollars per million. DeepSeek is 20-50× cheaper, and the primary reason is MoE. The architecture creates the margin.

GPT-4 uses MoE. Mixtral uses MoE. DeepSeek uses MoE. Every frontier model that’s being served at scale uses MoE, because at the scale of millions of users, the difference between computing 100% of your parameters and 4.8% is the difference between a viable business and a money bonfire.

The System Layer: Batching, PagedAttention, and Speculative Decoding

Model-level optimization gets you a cheaper model. System-level optimization gets you more out of the hardware you already have. This is the layer where serving engines live — vLLM, SGLang, TensorRT-LLM — and where the difference between naive and optimized serving is not 10% or 20% but 5-10×.

The Waste Problem

Traditional LLM serving is embarrassingly naive. You allocate memory for the KV cache based on the maximum sequence length. If your limit is 4,096 tokens but the average request uses 512, you’ve allocated 8× the memory you need. 87% of your GPU’s memory is wasted holding empty slots. You can serve fewer concurrent requests, which means lower throughput, which means higher cost per token.

Two innovations fix this.

Continuous Batching

Old-school static batching waits for a batch of requests, pads them all to the same length, processes them together, and waits for the longest one to finish before starting the next batch. If one request generates 10 tokens and another generates 500, the short one sits idle while the long one finishes.

Continuous batching — sometimes called in-flight batching — schedules at the token level rather than the request level. New requests join the batch as old ones finish. The GPU stays busy because there’s always work to do. Makes the load faster as well! Alas, this is another boring one -- it’s now considered table stakes for any serious serving system.

PagedAttention

PagedAttention, introduced by the vLLM team, borrows directly from operating system virtual memory. Instead of pre-allocating a contiguous block for each request’s KV cache, it stores the KV cache in fixed-size blocks — pages — and allocates them on demand. A request that needs 512 tokens of KV cache gets 512 tokens of memory, not 4,096.

The impact: KV cache memory waste drops from 60-80% to under 4%. You can serve 2-4× more concurrent requests on the same hardware. Combined with continuous batching, vLLM serves Llama 2 70B at 2,200 tokens per second across 256 concurrent users — 2.3× faster than HuggingFace’s Text Generation Inference and 3.1× faster than vanilla PyTorch serving.

The choice of serving engine depends a lot on your use case. vLLM dominates production deployments for straightforward serving. SGLang leads in throughput when requests share common prefixes (like a system prompt) via RadixAttention, which caches and reuses KV cache for shared prefixes automatically. TensorRT-LLM is the NVIDIA-optimized path for maximum hardware utilization. The right choice depends on your workload shape -- there is no one size fits all!

Speculative Decoding

Speculative decoding is the most elegant trick in the inference optimization playbook, and it’s lossless — same model output, fewer wall-clock seconds.

Here’s the mechanism. You have a large “target” model — the one whose output you want. You also have a small “draft” model — think 2-5% of the target’s size. The draft model predicts the next several tokens. The target model then verifies all of them in a single forward pass. If the draft was right, you’ve just generated N tokens for the cost of one forward pass. If the draft was wrong, you fall back to the target’s output and discard the incorrect draft tokens. Either way, the output is identical to what the target model would have produced on its own.

EAGLE-3, presented at NeurIPS 2025, is the current state of the art. It attaches 1-2 transformer layers as the draft head — tiny compared to the target model — and achieves 2-6× speedup. It’s supported natively in vLLM v0.8.5+ and in SGLang via the SpecForge training framework. Apple’s QuantSpec, mentioned earlier, takes a different approach: the draft model is the target model, just with 4-bit quantized KV cache and weights. No separate draft model to train. The quantized version guesses, the full-precision version verifies.

Speculative decoding doesn’t change the model. It changes the cost per token by letting you verify multiple tokens for the price of one. In a world where inference is billed by the token, this is free money!

Disaggregated Serving

The frontier of system-level optimization is disaggregated serving — splitting the prefill phase (processing the prompt) and the decode phase (generating tokens) across different machines.

Prefill and decode have fundamentally different computational profiles. Prefill is compute-bound: you’re processing the entire input prompt in parallel, doing lots of matrix multiplications. Decode is memory-bound: you’re generating one token at a time, loading weights and KV cache for each step. Different bottlenecks, different optimal hardware configurations.

In a disaggregated architecture, you run prefill on GPUs optimized for compute throughput and decode on GPUs (or LPUs) optimized for memory bandwidth. Each phase runs on the hardware best suited for it. This is emerging in 2026-2027 and represents a shift from optimizing one server to optimizing the topology of inference — where requests flow, which machines they hit, how the KV cache transfers between phases.

The Application Layer: Caching, Routing, and Context Compaction

You can have a perfectly quantized MoE model served through an optimized vLLM stack with speculative decoding enabled, and still waste 40-60% of your token spend. The application layer is where most AI engineering teams leave money on the table, because it’s the layer they control the least — it’s their product code, not their infrastructure.

Prompt Caching and KV Cache Reuse

If multiple requests share a common prefix — a system prompt, a document, a conversation history — the KV cache for that prefix is identical across requests. Caching and reusing it means you skip the prefill computation for everything the user has already “seen.”

SGLang’s RadixAttention does this automatically — it detects shared prefixes and caches their KV states in a radix tree for O(1) lookup. Anthropic and OpenAI now offer prompt caching at the API level: send the same system prompt twice, pay for prefill once.

But here’s the idea that borders on absurd: what if you precomputed the KV cache for an entire document and sold access to it?

A paper titled “Can I Buy Your KV Cache?” proposes exactly this. Right now, across the world, AI agents are repeating the same act: to read one document, they each recompute it from scratch. Every agent re-runs prefill — the most compute-intensive step in inference — over identical text, rebuilding a KV cache identical to the one the agent before it just built. The same answer, computed a million times.

The proposal: compute it once. Let a publisher precompute a document’s KV cache and let every other agent load it and skip prefill. The paper proves this is token-exact — loading a precomputed KV and continuing produces identical results to prefilling from scratch. And the compute reduction is up to 50×!

This is the most radical idea in the inference optimization stack. It turns prefill from a computation into a lookup. It creates a secondary market in precomputed representations — document publishers become inference cost centers, not just model providers. And if AI token pricing becomes a traded commodity — which it’s certainly starting to — then KV cache pricing is the natural next layer. You’re trading precomputed intelligence, not just raw compute time.

Semantic Caching

If someone asks “What’s the capital of France?” and later someone asks “What is France’s capital?”, the answer is the same. Semantic caching uses embedding similarity to detect this and serve the cached response without hitting the model at all.

For RAG applications and customer service workloads, 30-40% cache hit rates are achievable. Each cache hit is a 100% cost reduction for that request — zero tokens, zero compute, zero latency. The tools exist (GPTCache, Redis-based semantic caches) and are straightforward to deploy. Most teams don’t, because they’re focused on model quality and don’t think about the cache layer.

Model Routing and Cascading

Not every query needs a frontier model. “Summarize this email” doesn’t need GPT-5.5. “Write a SQL query joining three tables” might. Model routing sends each query to the cheapest model that can handle it, determined by a lightweight classifier.

The math is compelling. If 60% of your queries can be handled by Llama 3 8B at 1/10th the cost of your frontier model, your average cost per query drops by 40-70%. The routing classifier itself is cheap — a small embedding model and a threshold. The quality impact is near-zero if the classifier is well-tuned, because you only route simple queries to the small model and let complex ones through to the frontier.

Cascading is the conservative variant: try the cheap model first. If its confidence is low — measured by output logprob entropy or a separate evaluator — escalate to the expensive one. More compute per query than routing (you sometimes run two models), but it guarantees a quality floor.

Context Compaction

The average LLM API call wastes 40-60% of input tokens on context the model doesn’t need. Repeated system prompts. Conversation history that’s no longer relevant. Retrieved documents that were useful two turns ago but aren’t anymore. You pay for every wasted token twice — once in your API bill, again in latency/accuracy while the model attends over padding.

Context compaction summarizes or truncates conversation history before sending it. For a chatbot handling a 20-turn conversation, this might mean compressing turns 1-15 into a summary and sending the summary plus turns 16-20. The model gets the context it needs at a fraction of the token count.

For agentic workflows — which make 50-200 LLM calls per task — this compounds dramatically. A workflow making 100 calls at $0.01 per call costs $1.00 per task. Add 50% context compaction, a 30% cache hit rate, and model routing that sends 60% of calls to a model at 1/10th the cost: effective cost drops to roughly $0.25-0.35 per task. That’s a 65-75% reduction from application-level optimizations alone, before touching the model or system layers!

The Hardware Shift: Specialized Silicon and the Post-GPU Era

Everything above is software. But the hardware underneath is also bifurcating, and the split line is the same one we keep hitting: training is compute-bound, inference is memory-bound. GPUs are general-purpose — they do both, but they do inference poorly relative to what’s possible.

NVIDIA knows this. That’s why they paid $20 billion for Groq.

The Groq Acquisition

On December 24, 2025, NVIDIA announced a deal to acquire Groq’s LPU technology and core engineering team for $20 billion. Structured as an asset and talent transfer rather than a full corporate acquisition — a lesson learned from the failed ARM deal — it was designed to avoid regulatory scrutiny while securing the one thing NVIDIA didn’t have: an inference-native chip.

Groq’s LPU (Language Processing Unit) is architecturally alien to a GPU. It uses SRAM — hundreds of megabytes of on-chip static RAM — as its primary memory, not HBM. On-chip bandwidth on the Groq 3, announced at GTC March 2026, hits 150 TB/s. NVIDIA’s own Rubin GPU manages 22 TB/s. The LPU also sidesteps the two biggest supply chain bottlenecks in the semiconductor industry: CoWoS packaging and HBM itself. It doesn’t need either.

The performance gap is stark. Groq serves Llama 2 7B at 750 tokens per second. An H100 manages roughly 40. That’s an 18× speedup. For Llama 2 70B, Groq hits 300 tokens per second — 10× faster than H100 clusters. The LPU achieves nearly 100% compute utilization during inference, versus 30-40% for GPUs.

The thesis behind the acquisition: NVIDIA’s inference market share was projected to fall from 86% to 22.5% by 2030 as the industry shifted from training to inference spending. Amazon had Inferentia. Google had TPU. Cerebras and SambaNova were going public. Every hyperscaler was designing custom silicon. NVIDIA was the dominant training chip vendor in a market where the spending center of gravity was migrating to inference — a market where GPUs are architecturally suboptimal.

So what do you do if you’re NVIDIA? You buy the fix. The Groq 3 LPX rack — 256 LPU chips in a liquid-cooled chassis — delivers 35× higher throughput per megawatt than GPU-only configurations. A workload requiring 35 megawatts on GPUs could theoretically run on 1 megawatt with an LPU-GPU pairing. NVIDIA’s pitch: train on Vera Rubin GPUs, infer on Groq LPUs, single vendor, full stack. The lock-in deepens...

Cerebras and SambaNova

Cerebras went public in May 2026 at a $95 billion valuation, backed by a $20 billion multi-year deal with OpenAI and a deployment agreement with AWS. Their WSE-3 (Wafer-Scale Engine) integrates trillions of transistors on a single monolithic die — the largest chip ever built. On gpt-oss-120B, Cerebras reports 3,000 tokens per second. For workloads that need raw throughput on large models, the wafer-scale approach removes the multi-chip communication overhead that plagues GPU clusters.

SambaNova’s SN40L takes a different architectural path — reconfigurable dataflow units (RDUs) that adapt their computational graph to the model being served. The claim that got attention: 16 SN40L chips replace 320 GPUs for serving DeepSeek-R1 671B, hitting 198 tokens per second on the full, non-distilled model. Several-fold better total cost of ownership than an equivalent GPU setup.

All three — Groq, Cerebras, SambaNova — solve the same bottleneck. They just solve it differently: Groq with SRAM, Cerebras with wafer-scale integration, SambaNova with reconfigurable dataflow. The GPU was a general-purpose solution in a market that’s increasingly specialized.

Hyperscaler Silicon

Every major hyperscaler is now building inference chips. Google’s Ironwood TPU went GA in 2026. Amazon has Trainium and Inferentia. Microsoft launched the Maia 200. Meta has MTIA. OpenAI is working on “Jalapeño” with Broadcom co-designing the silicon. The pattern is clear: the companies that buy GPUs are building alternatives to GPUs, because the GPU’s general-purpose architecture taxes them for capability they don’t need.

The training market stays GPU-dominated — roughly 90% share. Training genuinely requires the parallel mathematical throughput that GPUs excel at. But inference is up for grabs, and inference is where the spending is migrating. The global AI inference market was valued at approximately $106 billion in 2025 and is projected to reach $254 billion by 2030. NVIDIA doesn’t get to keep all of that by default.

GPU Economics

The GPU is getting cheaper, even before specialized silicon eats into it. H100 rental rates dropped from ~$5.00/hr in Q1 2024 to ~$1.80-3.50/hr in Q2 2026. Supply moved from acute shortage to functional balance. The H200 — same Hopper die, bigger memory subsystem — runs $3.00-4.50/hr. The B200 (Blackwell) is ~$6.03/hr. The GB200 Superchip is ~$9.08/hr.

On a cost-per-token basis, Blackwell is a significant leap. SemiAnalysis’s InferenceX benchmark on MiniMax M2.5/M2.7 shows the B200 at $0.16 per million output tokens versus the H100’s $0.58 — 257% more output per dollar. At higher interactivity levels (98 tokens/sec/user), the gap widens to 223% ($0.53 vs $1.72).

The GPU is getting cheaper. Specialized silicon is getting cheaper faster. The cost curve is bending downward from both directions.

What Comes Next

The inference optimization stack as it exists in 2026 is mature, production-grade, and still improving rapidly. But the next frontier — the things that will collapse the cost curve again — is already visible.

Precomputed KV Caches as a Market

The “Can I Buy Your KV Cache?” paper is the seed of something that could reshape inference economics. If precomputing and selling document KV caches catches on, prefill becomes a commodity. You don’t recompute it, you buy it! The compute reduction is up to 50× — not a percentage improvement, an order of magnitude.

This creates a secondary market. Document publishers — not just model providers — become inference cost centers. A company that publishes a 500-page technical manual could precompute its KV cache and sell access to any AI agent that needs to reason over it. The model provider charges for decode; the document provider charges for prefill. The economics of inference split into two layers with different providers, different pricing, and different margin profiles.

Edge Inference

Not all inference needs a datacenter. Chat, code completion, document Q&A — workloads with latency sensitivity and privacy requirements — are migrating toward on-device deployment. The technology is arriving.

BaseRT, published in July 2026, is a native Metal inference runtime for Apple Silicon that achieves the highest inference throughput on that hardware to date. By building natively on Metal — not through the abstractions of llama.cpp or MLX — it recovers performance that framework-based approaches leave on the table. Up to 1.56× higher decode throughput than llama.cpp, 1.35× higher than MLX. Models up to 30B parameters run at usable speeds on M3 and M4 Pro devices.

General Instinct’s work on edge compression — fitting a 122B-parameter MoE into 48GB — proves that frontier-class models can be compressed for edge hardware without sacrificing capability on the benchmarks that matter. Apple Silicon’s unified memory architecture is uniquely suited for this: the NPU feeds directly from unified memory, no PCIe bottleneck, no HBM supply chain.

The implication for datacenter demand is direct. If 30-40% of inference workloads move on-device — and the workloads most suited for edge are the highest-volume, lowest-latency ones — the hyperscaler compute thesis weakens further. This is the crash mechanism from our Compute essay, accelerated. The demand for datacenter compute doesn’t just grow more slowly than expected; it actively shrinks as workloads migrate to the edge.

The 1-Bit Future

BitNet b1.58 demonstrates that models trained with ternary weights — just {-1, 0, +1} — can achieve performance comparable to full-precision models. If this scales to large models, the memory savings are dramatic.

As of right now, this is still research. But the trajectory is clear and consistent: 16-bit to 8-bit to 4-bit to... what? The floor keeps dropping. Every year, the same intelligence needs fewer bits. The question is where the bottom is, and we haven’t found it yet. When we do, the hardware requirements for inference change fundamentally.

Inference-Native Model Design

Current models are designed for training efficiency and then compressed for inference. The next generation will be designed for inference from the start.

DeepSeek V4’s hybrid attention is an early example — the architecture itself reduces FLOPs and KV cache size, not a post-hoc optimization. MoE is another — the routing mechanism is a first-class architectural decision that makes the model structurally cheaper to serve. Expect architectures that natively support speculative decoding (built-in draft heads), KV cache compression (hierarchical attention patterns), and low-bit quantization (trained at 4-bit, not quantized after training).

The gap between “optimized” and “naive” inference will widen. Teams running inference-native models with full optimization stacks — model-level quantization, system-level batching and speculative decoding, application-level caching and routing — will be 50-100× cheaper than teams running dense models through generic APIs. The 50% in the title is the conservative number. The teams that do everything right are already at 97%.

The Efficiency Flywheel

The printing press wasn’t about the press. It was about making information reproduction 1,000× cheaper. Gutenberg’s invention didn’t just reduce the cost of books — it created entirely new categories of human activity that weren’t economically viable when every book had to be hand-copied. The cost reduction didn’t shrink the market -- it exploded it!

Inference optimization is the same pattern. Cheaper intelligence doesn’t just reduce the cost of existing AI applications. It creates categories that weren’t economically viable when tokens cost 100× more. AI agents that make 200 calls per task. Real-time code completion on every keystroke. On-device assistants that never send data to a server. Mass-personalized education tools. None of these work at $10 per million tokens. They all work at $0.30.

The flywheel: cheaper inference enables more AI products, which drives more inference demand, which funds more investment in inference optimization, which makes inference cheaper. NVIDIA’s Groq acquisition thesis, in one sentence: cheaper inference means more AI-powered products, which means more inference demand, which means more LPU sales. The market grows as the cost falls.

The teams stacking all three optimization layers are at 90%+. The next architecture generation — inference-native models, precomputed KV markets, 1-bit weights, edge deployment — will collapse the curve again.

The question isn’t whether inference costs will fall. They will. The question is whether you’re on the curve or behind it.

If you want to argue about whether inference costs will hit zero, the Discord is always open. If you want to read more like this, subscribe to the Substack — each post goes up there first.

Got a take on AI infrastructure I should hear? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

The Problem

I’m bad at rating things.

I do enjoy rating things. On one hand, it is a requirement of my specific form of autism to catalog stupid shit. On the other, it is genuinely helpful to have a cheatsheet of historical guidance if I’m working on a new game or story -- a historical list of “I played X, X was good, X was good because it had Y”, etc. etc.

But my historic rating system is all over the place. First of all, its based on vibes. Not a good sign. Secondly, its very tied to recency bias. I gave a ton of movies a 7 when I was going through my movie marathon. At the time, I saw this as the expected “meh” answer. Now that I’m a free-willed adult, I see this as far too generous! Mid films get a 3 at best. Also, I notice that -- among sevens -- there were some that I felt grew to be much better (or much worse) than my original judgment.

It was all just too subjective.

So I thought: alright, you want objective? I’ll give you objective, motherfucker.

The Build

The Jerma Inspiration

The seed for this came from watching Jerma’s “Top 300+ Games of All Time” stream on Twitch. His community built a custom site for the stream — I think a moderator made it — and one of the features was a head-to-head matchup system where two games would appear side by side and you’d pick the winner. In Jerma’s case this was used to narrow down a huge list into a final tier list. But I saw the vision immediately.

Watching it, I realized something. If you took a sampling of all the games you’ve played and ran them through head-to-head matchups — every game against a set of other games — the resulting scores would be far more objective than anything you’d get from staring at a list and trying to assign numbers.

Because you’re not rating a game. You’re making a binary choice. This one or that one. It’s much easier to compare two things directly than to assign each of them an independent score. “Is Hades better than Hollow Knight?” is an easier question than “What score does Hades get, and what score does Hollow Knight get?” One is a judgment call. The other requires you to maintain a consistent internal scale across hundreds of items, which is something humans are genuinely bad at.

So the plan was simple: draft a list of games, round-robin them against each other, and let the wins become the score.

The Round-Robin Problem

A true round-robin — every game plays every other game — works fine for small lists. With 11 games, that’s 55 matchups. Manageable. But with 20 games, it’s 190. With 30, it’s 435. The number of matchups grows quadratically (n × (n-1) / 2), which means the user gets buried in matchups long before the list gets interesting.

I had over 2,000 games I needed to backfill. We needed something easier.

So, I decided to switch things up. Really all I needed was 10 random head-to-heads. That way the score is always “wins out of 10” — in other words, an out of 10 rating. And if the 10 games are randomly sampled enough, its about as good as reviewing them against the whole thing. This strategy does still grow the more games you add to it, but in a way that my rating ‘tism could easily handle.

The problem was that a round-robin doesn’t give you something so clean. It gives you “wins out of (n-1),” which changes as the list grows.

Round-robin wasn’t going to work. I needed something else.

The Circulant Graph

What I landed on is a circulant graph. Here’s how it works.

Lay your games out in a circle, labeled 0 through N-1. Connect each game to the next 5 games clockwise — so game 0 connects to games 1, 2, 3, 4, and 5. Game 1 connects to games 2, 3, 4, 5, and 6. And so on, wrapping around the circle.

Each game now has 5 “forward” neighbors. But it’s also a “backward” neighbor of 5 other games — game 0 is a backward neighbor of games N-1, N-2, N-3, N-4, and N-5. So each game ends up with 10 total connections: 5 forward, 5 backward. Every game participates in exactly 10 unique head-to-heads.

The key insight is that as long as you have at least 11 games, no pair appears twice. With 11+ games in the circle, the forward offsets (1 through 5) never overlap with the backward offsets (N-1 through N-5), so every matchup is unique. Total matches = 5 × N.

This is a solved problem in combinatorics — circulant graphs are well-studied structures with clean mathematical properties. I just needed to apply it to my dumb bullshit no one cares about.

Fortunately, the implementation is about 20 lines of TypeScript: shuffle the match order so the user doesn’t see a predictable pattern, randomly swap which game appears on the left to avoid position bias, and you’re done. Sometimes, math is good.

IGDB and the Search Layer

The games come from IGDB — the same source Backloggd uses. IGDB is authenticated through Twitch, which means you need a free Twitch developer account to get credentials. That’s a mild annoyance, but it’s the best free game database available, and the cover art and summaries are solid.

The architecture is straightforward Next.js App Router. The search runs through a server-side API route at /api/igdb/search so the Twitch client secret never touches the browser. The client handles all state — draft list, matches, winners — via localStorage. No accounts. No database. No backend cost. You draft, you match, you see results, and if you close the tab and come back, you’re right where you left off.

There’s also a bundled Steam library CSV — a curated starting point so you’re not staring at a blank page wondering what to add. And the search supports manual overrides: if IGDB doesn’t have a game, or picks the wrong game (which it often does), you can make manual edits to finetune the entries.

The Architecture Is Media-Agnostic

The demo app is built around a Game type, but the only thing that’s game-specific is the IGDB adapter. If you wanted to swap in books, you’d replace IGDB with the Google Books API or Open Library. If you wanted movies, you’d use TMDB. The matchmaking algorithm doesn’t care what it’s matching. The UI doesn’t care what it’s displaying. Swapping media types means touching three files: the search adapter, the API route, and the type definition. Everything else is generic.

I haven’t built those adapters yet. But the architecture is ready for them, which is the point.

The Philosophy

Rating systems are everywhere and they’re all the same. Pick a number, attach it to a thing, sort by that number. Five stars, ten points, percentage scores. The entire industry of media criticism runs on this model, and the model is broken for one simple reason: it asks you to evaluate things in a vacuum.

“Rate this game.” On what scale? Relative to what? Is Portal a 10 because it’s a perfect short game, or is it an 8 because it’s short? Is Skyrim a 9 because of the scope or a 7 because of the bugs? The number doesn’t capture the reasoning, and the reasoning changes depending on what you played last week.

Head-to-head comparison sidesteps the whole problem. You’re not rating a game. You’re choosing between two games. That’s a much more natural cognitive task — humans are excellent at comparative judgment and terrible at absolute judgment. Ask someone “how good is Celeste“ and you’ll get a number that depends on their mood. Ask “is Celeste better than Super Meat Boy“ and you’ll get a real answer.

The score that falls out of this — wins out of 10 — isn’t a rating you assigned. It’s a rating that emerged from your actual preferences, expressed as a series of binary choices. You never had to think about whether Celeste is an 8 or a 9. You just had to pick between it and ten other games, and the wins added up.

What I’d Do Differently

Rating Bracket works. It does what it was designed to do: turn subjective comparisons into objective scores. But it’s a prototype, not a product, and there are things I’d change.

The 10-matchup limit is fixed. Every game appears in exactly 10 head-to-heads regardless of list size. That’s fine for 11 games (10 out of 10 possible opponents) but gets sparse for larger lists — with 50 games, each game only plays 10% of the field. I’d want the matchup count to scale with list size, though that requires a more complex graph structure. The circulant approach works cleanly for a fixed degree; variable degree is a harder combinatorial problem.

The Steam library CSV is a nice touch but it’s static. It’d be better to connect directly to the Steam API so you can import your actual library rather than working from a generic list. That’s a small feature, but it would lower the barrier to entry — the hardest part of using Rating Bracket is coming up with 11+ games to draft.

I’d want adaptive matchmaking. Right now, matchups are randomly assigned. But if you’ve played 100 matchups and game A has won all 10 of its head-to-heads and game B has lost all 10, it would be more informative to match similar-strength games against each other — Swiss-style pairing. This is a problem that exists in sports (the classic “they got to the playoffs because of an easy schedule” excuse) but it our case it can actually be fixed, since there’s no problem with changing the schedule as the season is running. The current system is fine for getting a rough ranking, but adaptive pairing would converge on a more accurate one with fewer matchups.

What’s Next

This is the fourth post in the series. I’ve now covered Aries, Zetteln, my quant algo, and Rating Bracket. The series will continue with more of the smaller tools and utilities — the ones that turned out more useful than I expected, and a few that turned out less.

If you want to see Rating Bracket in action, it’s live on my Github. If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether head-to-head comparison is a better rating system than number scores — the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

§1 — China’s Most Controversial Researcher

Here’s a question that should bother you more than it does: why did the model that wiped $593 billion off Nvidia’s market cap in a single day come from a Chinese hedge fund?

In order to answer that question, we need to start with Liang Wenfeng.

Wenfeng was born in 1985 in the Zhanjiang, Guangdong province. His father was a schoolteacher -- nothing particularly special. But Wenfeng himself was gifted, and in China that gave privileges: he left high school early at 17 to enter Zhejiang University — a member of China’s Ivy League equivalent — where he earned a bachelor’s in electronic information engineering in 2007 and a master’s in information and communication engineering in 2010.

His master’s thesis was titled “Stable Target Tracking Algorithm of Surveillance Camera.” Specifically, it was about PTZ cameras — pan-tilt-zoom surveillance cameras — and how to make them track moving targets in real time using computer vision algorithms. As you might imagine, there is quite a demand for PTZ cameras in China, so this was likely a positioning play. But the PTZ problem is inherently based in computer vision, and thus grounded in machine learning. More on that later.

For now, we get into the “lost years” for Wenfeng. After his graduation, he moved to a cheap flat in Chengdu and spent several years experimenting with AI applications. Most of them failed. We don’t know much about what he was doing, but it did almost certainly lift up the later High-Flyer and Deepseek thesis. While “hedge fund to AI company” sounds entirely unrelated and a tad bit egotistical, it’s surprisingly not. Wenfeng was always grounded in applied machine learning.

In 2013, he co-founded his first investment firm to integrate his learnings with AI into quantitative trading. It didn’t work out, but Wenfeng clearly felt he could do something with the thesis -- three years later, in 2016, he and two friends formally launched Ningbo High-Flyer Quantitative Investment Management.

In Mandarin, High-Flyer goes by the name 幻方 — “magic square.” A magic square is a grid of numbers where every row, column, and diagonal sums to the same constant. The simplest one — the 3×3, known as the Luoshu — arranges the numbers 1 through 9 so that every line adds up to 15. Legend says it appeared on the back of a turtle emerging from the Luo River around 2800 BCE. There’s something fitting about a quant fund naming itself after an ancient mathematical object that promises hidden order beneath apparent chaos.

By 2017, they had fully implemented deep learning algorithms for trading, and their first set of clients -- presumably more financially successful colleagues from Wenfeng’s Zhejiang years. After this, the fund began to grow fast. By 2019 — three years after founding — High-Flyer was managing 20 billion yuan (about $2.8 billion) and was ranked China’s No. 1 stock hedge fund by data provider Shanghai Suntime. They had a 60-strong team of engineers and data scientists. They had their own supercomputer! By the time Deepseek came around, this number grew even further to 70 billion yuan (~$10 billion).

How do you go from zero to $2.8 billion AUM in three years? In the US, this would be essentially impossible — you’d need SEC registration, years of audited track record, institutional due diligence, and a network of prime brokers and fund administrators. In China, the regulatory environment is, unsurprisingly, far different. The Asset Management Association of China (AMAC) regulates private funds, but the barriers to entry are lower than the SEC’s. More importantly, the Chinese fund management industry is structurally different: there’s a vast pool of retail and semi-institutional capital looking for yield in a market with limited investment options, and a successful quant strategy — especially one with AI as its differentiator — can attract capital at a speed that would make American fund managers dizzy. High-Flyer reportedly drew more new assets in 2019 than the combined collections of every foreign fund operating in China.

But even with China’s ironically lax rules on the most capitalistic practice on earth, High-Flyer is still incredibly, incredibly good. Perhaps too good.

High-Flyer’s growth curve — $0 to $2.8B in three years — would be extraordinary in any market. In China’s market, where capital controls restrict outflows, where the government has a documented history of intervening in equity markets, and where the line between private enterprise and state interest is famously blurred, it’s seemingly impossible. Or rather, seemingly impossible for the average person. Because what China’s market also does is pick its own winners: you do not become hyper successful in China because you are good at money-making. You become hyper successful in China because someone likes you enough to let that happen.

Bookmark this for later.

Regardless, High-Flyer was a real hedge fund, making real money. And it was made by a person who knew he needed the cash, but whose real heart was in machine learning.

Then the AI boom came around.

Wenfeng saw the writing on the wall back in 2019, when High-Flyer’s success was cemented. It was during this year that Wenfeng started using management proceeds to buy GPUs. A lot of GPUs. He spent 200 million yuan (about $28 million) on 1,100 GPUs to train new machine learning algorithms. Remember that supercomputer I mentioned? It was purchased around this same time and served as the cluster tying this whole project together.

The official story, at least at the time, was that the GPUs were being used to improve the hedge funds own systems. But the reality was that Wenfeng knew that the real revolution -- and the revolution he was personally invested in -- was in the LLMs that startup labs in the West were beginning to train. Right around the same time ChatGPT was released to the American public, High-Flyer was already building their new LLM -- named DeepSeek -- in secret.

§2 — The Birth of DeepSeek

In May 2023, Wenfeng spun DeepSeek out of High-Flyer as a standalone AI lab. Initially, they claimed their DeepSeek model -- which had the same benchmark quality as billionaire models like GPT and Claude -- was trained for around $5.6 million. We now know this was mostly a marketing scheme: SemiAnalysis estimated the actual hardware investment at something like $1.6 billion, which puts it right in line with the other models.

But DeepSeek’s success wasn’t in training. It was in inference. DeepSeek R1 was putting out the same quality responses as ChatGPT’s frontier model at about one-tenth of the cost. Part of this came out of business strategy -- DeepSeek was open source, meaning costs were distributed across many different companies -- but there was also the fact that DeepSeek’s models just ran better inference period. The underlying software architecture was vastly, vastly improved compared to what Americans were doing.

The narrative -- that “we really need to spend these billions of dollars to make a good model” -- flipped overnight. When the West got its hands on DeepSeek-R1 in January 2025, Nvidia lost $593 billion in market cap in a single day — the largest one-day loss for any company in Wall Street history. Broadcom fell 17.4%. The Nasdaq had its worst day in months.

But, the more people began to look into things, the more it all seemed fishy.

Western researchers began looking into the comments made about DeepSeek during its initial launch, especially those that mentioned the hyper small $5.6 million number (which was a big reason for the crash). As it turns out, the overwhelming majority of these comments -- those outwardly appearing to be written by English-speaking tech enthusiasts -- were actually originating from IPs located in China. In addition, many of these accounts were tied to previous cases of misinformation run by the Chinese government themselves. Nothing definitive -- i.e. there was an assumed link once several pieces of evidence were branched together -- but enough to cause alarm.

Shortly following this, OpenAI officially accused DeepSeek of distilling ChatGPT’s underlying model in order to train DeepSeek R1. Distillation is essentially a clever technique where -- if you ask a model the right questions enough of the time -- you can use it to reverse engineer the exact data and weights that made the model so successful. However, this accusation is almost assuredly false -- High-Flyer had about the same amount of capital, the same amount of talented AI researchers, and the same amount of time to train that OpenAI did. Still, the hedge fund’s undeniable connections to the CCP made everyone suspicious. And so, DeepSeek was broadly banned within both American and European governments, and its popularity has nosedived since.

At least for now.

§3 — It Happened Again

So, the DeepSeek story is juicy: it is a possibly state-controlled enterprise making a record amount of money to produce a sophisticated model in record time, covered in suspicious coincidences, possible scheming, and undeniable controversy.

But this paints a bad picture of the Chinese AI race. In order to tell the full story, we need to tell a story of DeepSeek’s opposite: an utterly boring AI company, formed from traditionally grounded AI research, made up of years of trial and error, to create an impressive quality model with no strings attached.

We need to talk about Z.ai.

Zhipu AI — now known internationally as Z.ai — was spun out of Tsinghua University’s Knowledge Engineering Group (KEG) in 2019. Its founder, Zhang Peng, entered Tsinghua’s computer science department in 1998 and did his PhD there in 2018. He’s a Beijing establishment figure: member of the CPPCC, the government’s top advisory body. While his CCP connections might give some Westerners the ick, the man is much more transparent and traditionally validated than Wenfeng: he’s published at ICML, ISWC, and other conferences of international repute that are fact-checked by international committees.

Before Zhipu was building frontier LLMs, it was building AMiner — an academic paper search engine. Think of it as a Chinese Google Scholar with knowledge graph infrastructure, born from a university lab that had been working on exactly this kind of thing for years. The GLM (General Language Model) architecture came out of this work, and in 2021, Zhipu released China’s first proprietary pre-trained large model framework.

What? I warned you this was going to be boring in comparison.

To be fair, their funding story does get a little bit spicy. So, Alibaba and Tencent backed Zhipu early -- duh. BUT, then in 2024, Saudi Arabia’s Prosperity7 Ventures — an arm of Saudi Aramco — joined a $400 million round, becoming the first known foreign investor in a major Chinese AI company! This was at a time when the US was actively trying to prevent any sort Middle East–China alliance, so the West did not take it well. Then, in January 2026, Zhipu IPO’d on the Hong Kong Stock Exchange -- making it the first pure-play foundation-model developer in China to go public globally. The shares surged over 2,000% by mid-2026, pushing the company’s market cap past $128 billion.

The models themselves are serious. GLM-5, released February 2026, is a 745-billion-parameter mixture-of-experts model. GLM-5.2, the latest, benchmarks competitively with closed-source systems from Western labs (it’s also, for full transparency, my current daily driver and did most of the research for this article). Zhipu has kept the open-weights strategy for most of its releases — GLM-4.5 was open-weights, and the GLM-5 series is open-source — while gating commercial flagships behind their API. Revenue grew at 130%+ CAGR from 2022 to 2024. Gross margins above 50%. Everything checks out and is entirely in line with numbers we get from OpenAI and Anthropic. Still, just like everything that comes out of China, it will be interesting to see if time changes our opinion of Z.ai like it did with Deepseek.

§4 — Are We Doomed?

The underlying protagonist of this story (or antagonist, depending on your perspective) is not Deepseek or Z.ai. It is China. Both companies are deep within China’s pockets -- Deepseek indirectly, through subtler connections, whereas Z.ai has a definitive relationship via Peng. The question on every Westerner’s mind is not if DeepSeek or Z.ai or even Alibaba or Bytedance win. The question is if China wins, because at the end of the day every company listed here is a subsidiary of the CCP in a way that OpenAI and Anthropic are not subsidiaries of America.

To put it not quite as subtlely: are we screwed?

Well, it’s true, the CCP has something the US doesn’t: the ability to treat the entire country as a single resource pool. When Beijing decides AI is a national priority, it doesn’t need to wait for market signals. It directs. The State Council’s 2017 “New Generation Artificial Intelligence Development Plan” didn’t politely suggest that Chinese companies invest in AI — it laid out a definitive roadmap to make China the world’s leading AI superpower by 2030, backed by $150 billion in state-directed funding. When the government wants a semiconductor industry, it builds one. When it wants a domestic GPU supply chain, it funds one.

The CCP can also do something no American institution can: it can absorb losses for a very, very long time. High-Flyer doesn’t need DeepSeek to be profitable. It never will. The hedge fund makes the money, the AI lab spends it, and nobody asks when the ROI comes. OpenAI is burning billions and everyone — including OpenAI’s own board — is anxious about when the revenue catches up to the compute bill. The CCP has no such anxiety. If AI is a national priority, the money flows whether the numbers work or not.

It is a model that entirely works in CCP’s favor. And yet -- as any reader of this newsletter knows -- the model works until it doesn’t.

In 1958, Mao Zedong launched the Great Leap Forward. The premise was breathtaking in its ambition: pool the entire country’s resources — agricultural labor, steel production, infrastructure — and direct it all toward a singular national goal of rapid industrialization. Peasants were ordered off their farms and onto backyard furnaces to smelt pig iron. Agricultural collectives were consolidated into enormous communes. The state directed every resource it could grasp toward the bet.

And then they lost.

Between 1958 and 1962, somewhere between 15 and 55 million people died in what is now called the Great Chinese Famine — the deadliest famine in recorded human history, under any country, ever. What had happened was that, in all their planning, China had failed to properly account for their storage of grain, and that one simple mistake -- a mere footnote in the Great Leap’s planning book -- had wiped out a gigantic chunk of their population and built undeniable skepticism in their regime.

A second Great Leap Forward -- one based on AI -- has huge potential. If China wins, they can dominate the entire world with an iron fist. But if they lose -- which they most certainly could -- it would lead to widespread economic dissolution and displacement that would make the Great Famine look miniscule in comparison. It would be analogous to a hedge fund putting all their money into one position: China could be the Soros, or it could be the LCTM.

But China knows this. In fact, it’s terrified of this. And the reality of the situation is that China’s position on AI is all bark and no bite -- China certainly has the ability to put all its resources into one basket, but the chances of this happening are astronomically small.

I want you to read that note about the State Council’s plan again. At the time, I described it as the Chinese described it -- a high and mighty ambitious plan to wipe out the West’s advantage in AI. But pay a bit closer attention. China put down $150 billion in funding towards the project. 150 billion! In comparison, America’s three largest AI native companies -- Anthropic, OpenAI, and SpaceX -- have a combined market value of $3 trillion. China is throwing the equivalent of a penny on a million dollar prize pool, because the West has a hard time understanding their undeniable fear of failing again. This is a huge Western advantage.

Another huge western advantage is robustness and decentralization. If Anthropic wants to open an office in Tokyo and start recruiting Japanese talent, it does. If OpenAI wants to set up in London and hire European researchers, it does. In fact, both already have done those very things! They could even, technically speaking, open offices in China itself — good luck to a Chinese AI company trying the reverse. The American AI ecosystem is distributed across San Francisco, London, Tokyo, New Delhi, and dozens of other cities all over the globe, pulling talent from every country on earth. The Chinese firehose points in one direction, from one source, and it cannot branch.

So: are we doomed? No. The sides are, by any honest accounting, roughly matched. China has state-directed coordination and patient capital. America has market-driven capital at twenty times the scale, a decentralized talent pipeline that spans the globe, and a system that lets its companies plant flags in any country they choose. The hard truth is that nobody has won yet, and nobody is going to win cleanly. What happens next depends on which system’s structural costs catch up with it first.

Jacob Robinson writes about technology, markets, and the strange overlaps between them. You can find more of his work at astukari.substack.com.

The Problem

You can’t predict stock prices.

This isn’t a hot take. Anyone who’s actually looked at the data arrived at this conclusion roughly fifty years ago. The Efficient Market Hypothesis isn’t literally true — markets are full of frictions, behavioral anomalies, and structural stupidity — but it’s true enough that picking individual stocks based on your beliefs of “what will come next” is a losing game.

But here’s the good news: you don’t need to predict prices to make money. You just need edges that persist.

One of the best-documented -- and longest lasting -- edges is momentum. Things that have been going up tend to keep going up. Things that have been going down tend to keep going down. Whoda thought! This has been observed across decades, across countries, across asset classes, across time periods. Jegadeesh and Titman published the seminal paper in 1993. Mark Carhart put it in his four-factor model in 1997. It’s been a standard factor in academic finance ever since. Thirty years of bright people have tried to kill it, explain it away, attribute it to data mining or survivorship bias or whatever else, and it just keeps showing up.

Nobody has a fully satisfying explanation for why it works. The leading theories are behavioral: investors underreact to new information, they anchor to past prices, they sell winners too early and hold losers too long — the disposition effect, which is a fancy way of saying “people are psychologically incapable of taking a win and accepting a loss.” These biases come from the way human brains are wired, which means they’re persistent, which means momentum is persistent. As long as humans are the ones making allocation decisions — or as long as the institutions those humans built are still running on the same quarterly rebalancing schedules — momentum should keep working.

So: I can’t predict prices. But momentum tends to persist. And a win is always better than a loss, regardless of magnitude.

Could I build something systematic around this? Something that would tell me what to buy, how much to buy, and when to sell — removing the emotion entirely? Run it on Mondays, act on the output, don’t think about it again until next Monday?

I couldn’t find anything I trusted that did all of this. So I built it myself.

The Build

Before ChatGPT

This project predates ChatGPT. That detail matters — not as a badge of honor, but because it shapes the entire codebase. Mostly for the worse.

The algo started simple. The first version did exactly one thing: calculate Kelly-optimal portfolio weights for a universe of ETFs.

Okay... that’s actually quite a big “one thing”. Let me explain.

The Kelly Criterion

The Kelly criterion is one of those ideas that sounds like a cute little parlor trick until you realize it’s the most important formula in modern finance.

John Kelly worked at Bell Labs. He published the formula in 1956, and he was trying to analyze long-distance telephone noise, which is the kind of origin story that makes you wonder what else is hiding in the Bell Labs archives (more stories coming soon!). Edward Thorp — the mathematician who wrote Beat the Dealer and then proceeded to beat the stock market, horse-racing, slot gambling (somehow), etc. etc. — was the first to apply it seriously to both blackjack and investing. The idea is this: given a set of bets with known expected returns and variances, there exists an optimal allocation that maximizes the long-term growth rate of your capital.

Why logarithmic growth specifically? Because compounding is brutal. A 50% loss requires a 100% gain to recover from. If you start with $100, lose 50%, you have $50. To get back to $100, you need to double your money. That asymmetry — losses hurt more than gains help — means the optimal strategy isn’t “maximize expected return.” That would be 100% in whichever asset has the highest expected return, which is how you go bust. The optimal strategy is the one that maximizes the logarithm of wealth, because log growth naturally penalizes volatility. It’s the mathematical formalization of “don’t blow up.”

This appealed to me enormously. I didn’t want rules of thumb. I didn’t want “put 10% in each asset and hope.” I wanted the mathematically optimal answer, given the information I had. The Kelly criterion is not a heuristic. It’s the solution to an optimization problem with a well-defined objective function. It is, as far as I know, the most mathematically rigorous approach to position sizing that exists.

The Pipeline

The full pipeline, as it eventually stood:

1. Fetch ETF data. Using yfinance, pull recent price history for a universe of ETFs. The universe of ETFs were usually leveraged ones I screened for separately. yfinance is free, reliable-ish, occasionally returns complete garbage for no reason. You learn to handle this.

2. Compute the 21-day EMA-to-volatility ratio. For each ETF, calculate the 21-day exponential moving average of returns, divided by the 1-month volatility. This is the momentum signal — how much return you’re getting per unit of risk. Positive means momentum is on your side. Negative means it isn’t.

3. Filter. Drop any ETF with a negative ratio. If the momentum signal is negative, you don’t need it.

4. Calculate Kelly weights. For the surviving ETFs, compute the Kelly-optimal portfolio weights using the covariance matrix and expected returns.

5. Outlier detection. Kick out any ETF with a 21-day winning streak. More on this in a minute, because the reason is not what you’d expect.

6. ATR trailing stops. Compute the Average True Range — a volatility measure — for each ETF, and set a trailing stop at a multiple of ATR below the current price. This is your exit strategy. If the price drops by more than the ATR-based threshold, you sell.

7. Export CSV. The output is a simple file: what to buy, how much, and where your stops are. Agnostic for any trading software.

Run it on Mondays. Act on the output. Don’t think about it again until next Monday.

Kelly Edge Cases (or: Why All-Positive Returns Break Everything)

The more a stock wins, the better it does on Kelly. But if it wins too much, it becomes worthless.

Why?

Here’s the setup. The Kelly criterion needs to compute expected returns and variances for each asset. If an ETF has had 21 consecutive days of positive returns — every single day up — something very specific happens to the math. The variance of the daily returns approaches a particular relationship with the mean, and under certain formulations of the Kelly optimization, the formula assigns that asset an infinite weight.

This is technically valid. The Kelly criterion simply looks at an asset with zero downside in the observed window and says: put all your money in this. Put more than all your money. Borrow money and put it in this. The expected logarithmic growth is unbounded.

This is, obviously, insane.

The Kelly criterion is mathematically optimal if your inputs are correct. An asset that genuinely never goes down genuinely does deserve infinite allocation — it’s a money printer. But we live in the real world, where assets that go up 21 days in a row are either:

• A leveraged ETF with a structural upward bias that will evaporate the moment the market turns

• A low-volume ETF with stale pricing that looks smooth because nobody’s actually trading it

• A data error from yfinance

• An actual bubble about to pop

None of these are money printers. All of them will, at some point, go down, and when they do, the Kelly formula — which assumed they never would — will have already told you to put 200% of your net worth into them.

So the Kelly criterion, for all its mathematical elegance, has an edge case that will happily bankrupt you if you don’t handle it. The fix is crude: if an ETF has 21 consecutive positive returns, kick it out. Don’t try to model the “true” variance. Don’t try to be clever about it. Just remove it from the universe entirely. The formula can’t handle it, so the asset doesn’t get to play.

The Later Improvements

The code was eventually cleaned up with the help of Claude Sonnet. The original notebook was functional but messy, which is the nicest way I can describe code written by someone who just copy and pasted completely untested code from StackOverflow and Pastebin. Claude helped with the plumbing: better data handling, cleaner merge operations, proper error handling for when yfinance decided to return the financial equivalent of a 404. But the core logic — the Kelly weights, the EMA filter, the ATR stops, the edge-case handling — was mine. Claude improved the implementation. The strategy stayed the same.

What I’d Do Differently

The algorithm worked. I want to be precise about what “worked” means here — it did not make me rich. It did what it was designed to do: generate a systematic, rules-based allocation that captured momentum while managing risk. The Kelly weights were reasonable. The ATR stops caught drawdowns. The edge-case handling kept the math from exploding. The recession rotation did its job.

But I eventually stopped using it. Two reasons.

Trading volume. The algorithm rebalanced weekly. Momentum is volatile — ETFs move in and out of the positive-ratio set constantly, which means the Kelly weights shift, which means the algorithm is telling you to buy and sell different things every single week. The turnover was high. Not catastrophically high, but high enough that transaction costs — spreads, commissions, slippage — ate into the returns in a way that looked fine on paper and felt bad in practice. A strategy that backtests beautifully can be mediocre in the real world when you account for the cost of actually trading. This is a known problem in quant finance. The solutions — longer holding periods, turnover penalties, threshold-based rebalancing — all have their own tradeoffs, and I implemented none of them.

The Kelly assumption. This one’s deeper. The Kelly criterion is optimal for long-term betting — repeated bets over many rounds, where the compounding effect dominates. But weekly ETF rotation isn’t really long-term betting. It’s a series of short-term momentum bets, each of which is noisy. And the Kelly criterion assumes you know the true probability distribution. I was estimating it from 21 days of data. Twenty-one days! That’s almost nothing. My estimates were wrong — probably significantly wrong — and I was feeding wrong estimates into an optimizer that assumes they’re right, which gives you confidently wrong answers.

This is the fundamental tension in quantitative investing: the theory is beautiful, the inputs are garbage. The Kelly criterion is mathematically optimal if you know the true distribution. You don’t. Nobody does. You estimate, and your estimates are noisy, and the optimizer amplifies your errors because it’s solving for the maximum — it finds the portfolio that’s optimal given your estimates, which means it’s also maximally exposed to whatever’s wrong with them.

If I were rebuilding this, I’d do three things differently. First, fractional Kelly — half Kelly, probably — to buffer against estimation error. Second, a turnover penalty in the optimization so the algorithm doesn’t churn the portfolio every week. Third, a longer lookback window. 21 days is too short. Momentum is a medium-term phenomenon — it works over 3 to 12 months, not 3 weeks. Using a 63-day or 126-day window would give more stable estimates and lower turnover.

What’s Next

This is the third post in the series. Aries and Zetteln were the two full-sized apps from the Firebase Studio era. This one was a different animal entirely — not an app, not a product, a notebook. A piece of applied financial theory I ran on my own money.

Next up, I’ll be writing about more of the smaller tools and utilities — the ones that turned out more useful than I expected, and a few that turned out less useful than I’d hoped.

If you want to see the algo, it’s on my Github — free and open source. If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether momentum is a real anomaly or a data-mining artifact that’s been overfit to thirty years of history — the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

SpaceX went public on June 12, 2026 at $135/share, closed its first day at $161, and instantly became the sixth-largest company in America at $2.1 trillion. Everyone knows it’s overpriced. The boring explanation — absurd P/E, all the value is in unbuilt things, Elon is a cult leader, retail investors are degenerate — is true but uninteresting. The interesting version is worse: the mission statement itself, the whole point of the company, is a philosophical dead end, and SpaceX quietly knows it.

What you’re buying at $2 trillion is a satellite internet company with a side quest in AI, wrapped in the most compelling mythos of the 21st century.

The Myth

This is what the average person believes SpaceX is going to give them.

We are going to build a rocket that sends humans to Mars in the same time it takes to fly from New York to Tokyo. You will be able to live there, work there, tour there. It’ll be like Earth but redder. Ten years. Maybe less.

This is the version that lives in the head of the retail investor who bought SPCX on IPO day. And I want to be clear: I’m not being condescending. If your entire knowledge of space comes from Joe Rogan, this is a completely reasonable thing to believe. Elon Musk — the richest man on Earth, a man who actually builds rockets — is the one telling you it’s true. Why wouldn’t you believe him?

The problem is that it isn’t true. And the more interesting problem is that SpaceX knows it isn’t true, and they’ve structured their entire IPO around quietly admitting it.

What the S-1 Actually Says

The SpaceX S-1 is a remarkable document. It contains, on page one, one of the most soaring mission statements ever committed to an SEC filing:

“Our mission is to build the systems and technologies necessary to make life multiplanetary, to understand the true nature of the universe, and to extend the light of consciousness to the stars.”

More or less the eloquent, generic, legally safe version of the myth I mentioned above.

But then, a few hundred pages deeper, you find the CEO compensation plan. Elon Musk’s 1 billion restricted shares — potentially worth $117 billion at a $1.5 trillion valuation — vest in tranches. Each tranche requires two things: (1) a market cap milestone, up to $7.5 trillion, and (2) a “human colony milestone.” The final tranche requires a permanent human colony on Mars with at least one million inhabitants.

The board of directors of a $2 trillion company — a company that just raised $75 billion in the largest IPO in history — wrote, in a legally binding SEC filing, that the CEO’s pay is tied to putting a million people on Mars. And he has to still be employed by SpaceX when it happens.

There are two ways to read this. One is to say its proof that Elon is putting skin in the game. See!, the Twitter techbro calls out, He’s gotta do it or else he doesn’t get paid! The dream is real! And, yes, if you’re looking at just that final tranche, technically that’s what he’s doing.

But there’s a tiny little wrinkle in this plan, and its that Elon Musk is already the richest person on earth. When you are already a borderline trillionaire, an additional trillion becomes a lot less interesting. And so, you have the opportunity to create vesting tranches that are foundationally worthless outside of a marketing strategy, and have that be fine and dandy because, at the end of the day, your preferred shares still give you massive control over the corporation.

The Quiet Admission

Here’s where it gets interesting. If SpaceX genuinely believed Mars was an achievable proposition, the entire company would look different. The capex would be going toward life support systems, radiation shielding, surface habitat construction, closed-loop ecosystems — all the unsexy engineering problems that no investor gets excited about.

Instead, look at what SpaceX has actually been doing:

Starlink. SpaceX’s Connectivity segment — Starlink — generated $11.4 billion in 2025, about 61% of the company’s $18.7 billion total revenue. By Q1 2026, it was 69%. Starlink is a satellite internet company. It is also, as of 2026, a cellular company — the T-Mobile partnership (”T-Satellite”) lets any phone, on any carrier, connect directly to Starlink satellites from the 500,000+ square miles of America that no cell tower reaches. This is real. It works! It is a genuinely good business. Alas, not part of their mission statement.

xAI. In February 2026, SpaceX acquired xAI — Elon’s AI company — and folded it into the same entity. The rationale, per Elon: “orbital data centers.” The idea is that within 2-3 years, “the lowest cost way to generate AI compute will be in space.” Solar-powered satellites running GPU clusters in orbit. This is obviously stupid and probably a lie. It just makes managing the companies easier for him.

Cursor. xAI brought in Cursor (the AI code editor) as part of the merger, making SpaceX suddenly an AI tooling company too. Because nothing says “multiplanetary species” like an IDE.

The pattern is unmistakable. SpaceX’s actual business — the thing generating $18.7 billion in revenue and absorbing $20.7 billion in capex — is satellites, internet, and AI. The Mars stuff is the mythos. The mythos is the marketing. The marketing is what gets you a $2 trillion valuation instead of a $200 billion one.

The Physics Problem

I have told you that the Mars mission is impossible, but I haven’t yet explained why. I think I owe you an explanation.

Let’s break it down in detail.

First, radiation. Earth’s magnetic field and atmosphere protect us from galactic cosmic rays — high-energy particles that travel at nearly the speed of light and shred DNA. Mars has no magnetic field and a negligible atmosphere (about 1% of Earth’s). The ESA puts it plainly: “One day in space is equivalent to the radiation received on Earth for a whole year.” On the Martian surface, average radiation is 240-300 mSv per year — roughly 40-50 times Earth’s background. A peer-reviewed NASA model estimates that a Mars mission (approximately 3 years round-trip, BTW) would exceed NASA’s own radiation safety limits, with central estimates for radiation-induced mortality above 5% and upper confidence intervals near 10%. A 2023 study suggested a hard four-year limit for human habitation on Mars before radiation exposure becomes lethal.

You cannot engineer away cosmic rays. You can engineer around it, mostly by building thicker shielding, but the shielding itself becomes prohibitively heavy and secondary radiation from particle interactions with the shielding material can be worse than the original exposure. This is not something a better rocket fixes.

Then, gravity. Mars has about 38% of Earth’s gravity. We have no idea what living in 0.38g for years does to the human body, because no one has ever done it. We have data from the ISS (microgravity, ~0g) and from Earth (1g) and nothing in between. What we do know from long-term microgravity, however, is grim: bone density loss of 1-2% per month, muscle atrophy, cardiovascular deconditioning, fluid shifts that affect vision and brain structure. A child born and raised on Mars would almost certainly never be able to visit Earth — their bones and heart wouldn’t survive the gs.

Don’t forget biology. This is the one nobody talks about. A self-sustaining colony of one million people — the threshold in Elon’s comp plan — requires reproduction. It requires agriculture. It requires a closed-loop ecosystem. We have never built a closed-loop ecosystem that sustained humans for more than a few years. Biosphere 2, the most ambitious attempt, failed within two years: oxygen levels dropped, carbon dioxide spiked, pollinators died, and most vertebrate species went extinct. Mars is Biosphere 2 but with radiation, no breathable atmosphere, a 7-month supply line from Earth, and no rescue option.

Finally, the timeline. Elon has been saying “10 years to Mars” since 2006. It has been 20 years. He is now saying “approximately $1 trillion in revenue by 2030” — a number that, if achieved, would come almost entirely from Starlink and AI, not from anything on Mars. The Mars timeline, like quantum computing or AGI, has the convenient property of always being 10 years away.

The Herd

Here’s the part that I find genuinely fascinating, if a little sad.

The rational, scientifically literate response to the Mars mythology is to roll your eyes. “Obviously nobody is going to live on Mars in 10 years,” you say. And then you move on. Maybe you even defend SpaceX in conversation — come on, no one actually believes in the Mars stuff! The excitement is in the rockets! The rockets are real! The booster catch was incredible!

But the retail investor who bought SPCX at $161 on June 12 — the most-bought stock by net retail flow that day — is not operating on that level. That person heard “Occupy Mars,” saw the mission statement about extending “the light of consciousness to the stars,” and bought. Not because they understand astrophysics, but because the story is undeniably irresistible. It is the best story. It is the most ambitious thing a human has ever proposed and actually actioned on. It makes every other company’s mission statement — “to organize the world’s information,” “to accelerate the world’s transition to sustainable energy” — look like a middle school science project.

And that story, that mythos, is doing an enormous amount of work in the valuation. SpaceX trades at a price-to-sales ratio of 107. Its valuation would need to drop by $1.25 trillion to get below the historical threshold that indicates a bubble. The gap between “satellite internet company plus AI lab” and “$2.1 trillion” is the Mars story. You are paying a ~$1.8 trillion premium for a myth.

Matt Levine, writing in Bloomberg about the index fund problem, put it sharply: index funds must buy SpaceX. It’s too big to exclude. When a company enters the S&P 500 at $2 trillion, every passive investor in America is forced to own it regardless of whether they think the valuation makes sense. “Index funds can’t say no to SpaceX” was the headline. The mechanism is elegant: retail buys the myth, index funds are forced to buy the size, and the price goes up because both sides are price-insensitive. Well, until they aren’t... but that’s a story for a different article.

So, space is unexplorable and we’re screwed?

Not necessarily.

There is real value in space beyond Mars. Large satellite platforms further out than the ISS — research stations, manufacturing facilities, even tourism — are genuinely plausible on a 5-10 year horizon. A lunar base, while not a colony, is achievable and scientifically valuable. The Moon is three days away, not seven months. And we could even make it shorter! It has water and ice and other potential goodies waiting under the surface. It’s close enough that rescue is an option. We’ve even been there before!

If you want to be inspired about space, look at the Moon, not Mars.

The point is not that SpaceX’s mission is worthless and we should give up. The point is that it’s being played as a marketing scheme to drum up money from the easily persuaded (and not as technically endowed). And that could end up having real impacts on our very real, short-term economy.

If you want to argue about the Mars mission, the Discord is always open. If you want to read more like this, subscribe to the Substack — each post goes up there first.

This is not investment advice, BTW.

Got a take on space exploration I should hear? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

This is the second post in a series where I walk through how I built the software products on my portfolio, one at a time. It is co-written by Hermes running GLM 5.2, and validated by me.

The Problem

I hate taking notes.

That's a weird thing to say for someone who builds productivity software, but it's the truth. I've tried every note-taking app under the sun — Obsidian, Notion, Roam, the whole Zettelkasten ecosystem — and they all suffer from the same fatal flaw: they're graveyards. You write notes, you file them away, and you never look at them again. The knowledge you captured sits there, decaying in the dark, until eventually you forget you ever wrote it.

The problem isn't the note-taking itself. The problem is that notes don't become knowledge. Knowledge is something you internalize — something you can recall and use. A note is just ink on a page. The gap between writing something down and actually knowing it is enormous, and almost no software tries to bridge it.

I'd been thinking about this for a while. I used Readwise for 200 days straight — the spaced repetition highlighting tool — and while it was the closest thing to a solution I'd found, it was ultimately a feature, not a product. It was a highlighter. It didn't create new knowledge; it just reminded you of things you'd already highlighted. And when I tried to scale it up to the volume of content I actually consumed — articles, research papers, PDFs, RSS feeds — the whole system buckled. Notion crashed. Obsidian crashed. I'd been down this road before, and I knew where it ended.

The question I kept asking was: what if the note-taking step was the problem? What if instead of writing notes, you turned content directly into flashcards — automatically — and then drilled them into long-term memory using spaced repetition? No middleman. No notes. Just content in, knowledge out.

I couldn't find anything that did all of this. So I built it.

The Build

Firebase Studio and Gemini

Zetteln started alongside Aries. Google had just released Firebase Studio — a tool that let you build a fullstack app using Firebase with Gemini as the AI co-pilot. I wanted to test what it could do, so I used it to scaffold both apps at the same time. Aries was the productivity system; Zetteln was its companion — the "note-taking" app that isn't really a note-taking app.

Gemini was genuinely helpful for getting a functioning app off the ground fast. But it couldn't go the distance. The code it produced was messy, the architecture was inconsistent, and as the app grew more complex, Gemini couldn't keep up. So I moved the frontend to Vercel hosting (kept the Firebase backend) and switched to Cursor with Claude Sonnet 4.5 for the heavy lifting.

From Obsidian to App

The thing is, I'd built this system before — in Obsidian. The workflow was the same: take some content, send it through an AI to summarize by bullet points into micro-atomic pieces of information, split that off into flashcards, and study them with a spaced repetition system. It worked. It was genuinely useful. But Obsidian wasn't the right vehicle for it. It wasn't automated enough. The friction of doing this manually in a note-taking tool — copying content, running AI summaries, formatting cards, managing review schedules — was high enough that I wouldn't do it consistently. And consistency is the entire point of spaced repetition. Miss a few days and the algorithm's scheduling falls apart.

So I made it its own app. The workflow stays the same, but the friction disappears.

The Workflow

Zetteln has three input methods:

• PDF files — you upload a PDF and the app parses it.

• Website URLs — if it's an article page, Zetteln extracts the content.

• Manual entry — for physical books or handwritten notes.

You take a piece of content, the AI summarizes it into bite-sized bullet points, and each bullet point becomes a flashcard. That's it. No manual card creation. No formatting. The AI handles the conversion from "thing you read" to "thing you can be quizzed on."

There's also an RSS feed feature. You subscribe to feeds, hit refresh, and Zetteln pulls new articles directly into your inbox. From there, you enter swipe mode — a Tinder-like interface where you have three choices for each article: delete it, save it for later, or parse it immediately into flashcards. The save feature exists because not everything that comes through an RSS feed is an article — sometimes it's a Hacker News landing page, or an archive link where you'd want to download the PDF first and then parse it separately.

The Review System

This is where 99% of your time in Zetteln is spent. Once cards are created and vetted, they go into your review queue. You get a card, and you have two choices: swipe left to delete it (you don't care about this anymore), or swipe right to keep it (you want to recall this in the future).

If it's a new card, it enters the spaced repetition cycle. You review it today, and it comes back in two days. Two days pass, you review it again, and it goes to four days. Then eight days, then sixteen, and so on. The intervals grow as you demonstrate retention. At any point, you can delete a card you no longer need — it's not a lifetime commitment.

The swipe interface is deliberate. When you have 60,000 cards — which I do, because I uploaded over 200 PDFs into this thing, many of them textbooks — you need the fastest possible interaction. Swipe left or swipe right. No menus, no dialogs, no friction. The goal is to get through cards as fast as you can make decisions about them.

60,000 Cards

Let me address the elephant in the room. 60,000 cards is insane. It is absolutely self-inflicted. If you use this app normally, you will not have 60,000 cards. I put an unreasonable amount of content into it because I'm the kind of person who reads 200 PDFs and says "let me upload all of these."

The 60,000 card problem actually became an engineering problem. Before optimization, the app didn't run at all at that scale. It was completely unusable. After optimization — rewriting the sorting and processing pipeline for the review section — it runs, but slowly. There are still inefficiencies I could fix. More automation I could add. But this is the nice thing about making your own software: I designed it for my own niche use case, and if it's slow, I'm the only one who suffers. I don't have to make it perfect for an audience. I just have to make it work for me.

This is what I like to call the humble web farmer approach. I'm farming my own apps and cultivating my own land. If the crop yield is low, that's my problem, not a customer complaint.

Porting to Desktop

Like Aries, Zetteln eventually moved from a Firebase web app to a local Electron desktop format. Same playbook: replace Firestore with IndexedDB, rip out the auth, remove all cloud dependencies. The app runs entirely on your machine. No account. No subscription. No data leaving your computer.

It ships as a free, open-source desktop app. Windows and Mac. No strings attached.

The Philosophy

The fundamental insight behind Zetteln is that note-taking is a waste of time if you never review what you wrote.

Spaced repetition is one of the most well-validated findings in cognitive science. The idea is simple: you remember things best when you encounter them at increasing intervals, right at the moment you're about to forget. Hermann Ebbinghaus proved this in 1885 with his forgetting curve experiments, and modern tools like Anki and SuperMemo have turned it into a practical system. The algorithm isn't complicated. The hard part is getting content into the system.

Most spaced repetition tools require you to create cards manually. Open Anki, type a question, type an answer, format it, tag it, repeat. This is fine for medical students memorizing anatomy, but it's a non-starter for someone who reads 200 articles a month. The manual entry bottleneck kills the whole system before it starts.

Zetteln's approach is to eliminate that bottleneck. You don't write flashcards. You feed in content — a PDF, a URL, an RSS article — and the AI creates the cards for you. Your only job is to vet them: swipe left if you don't care, swipe right if you do. The AI handles summarization, card creation, and decomposition. You handle curation and review.

This is one of the few things AI is genuinely good at: summarization within a bounded context. If you give an AI a specific piece of content and ask it to extract the key ideas as atomic bullet points, it can do that well. It might not understand the wider world around that content, but it can figure out the content itself. And that's all you need — because you're the one who decided the content was worth reading in the first place. The AI is just doing the mechanical work of turning prose into flashcards.

The philosophy here is the same as Aries: take something that works — game design, cognitive science — and apply it seriously, without the compromises that mainstream tools make. Anki has the best spaced repetition algorithm but the worst UX. Readwise has the best UX but it's a highlighter, not a knowledge engine. Zetteln is the attempt to get both: the input automation of Readwise, the spaced repetition of Anki, and a card review interface that doesn't make you want to close the app.

What I'd Do Differently

I still use Zetteln, but not as my primary learning system. The reason is the same as Aries: I moved to a fully Obsidian-driven workflow, and the reason was that providing ease of access to my AI agent (Hermes) was more important to me than having a dedicated flashcard app. Obsidian is a file system. Agents can read and write files. Zetteln is a database app with a custom UI layer — agents can't meaningfully interact with it.

But there's a more specific lesson here. The 60,000 card problem revealed something about scale that I didn't anticipate. When you make card creation free — when there's zero friction between "I read this" and "this is now a flashcard" — you get a deluge. The AI doesn't know which points matter and which don't. It extracts everything, and suddenly you're reviewing 60,000 cards, most of which you either already knew or didn't care about.

The swipe-left-to-delete feature helps, but it's a post-hoc filter on a firehose. What I'd do differently is make the AI smarter about selection, not just extraction. Instead of "summarize this into 50 bullet points," the AI should say "here are the 8 things in this article that you probably don't already know, based on your existing card library." The card creation should be gated by what you already have, not just what the content contains.

There's also a feature gap I'd want to close: YouTube transcript support and EPUB support. The transcript feature is particularly important because I'm one of those weirdos who'd rather read than watch a video, and a lot of my learning content comes from YouTube. OCR for physical book highlights is on the wishlist too, but that's further out.

The other thing I'd do differently is the same thing I proposed for Aries: use the agent as an intermediary. Instead of manually uploading PDFs and URLs, the agent could read your Obsidian vault, your Readwise highlights, your RSS feeds, and propose cards automatically. Instead of manually reviewing cards, the agent could pre-filter them based on your existing knowledge base. The spaced repetition layer stays — the scheduling, the intervals, the review queue — but the data entry and vetting get offloaded to something that can do it continuously, without you sitting down for a swipe session.

What's Next

This is the second post in the series. I've now covered Aries and Zetteln — the two full-sized apps from the Firebase Studio era. Next up, I'll be writing about the smaller tools and utilities I've built, starting with the ones that ended up being more useful than I expected.

If you want to see Zetteln in action, it's live on my Github — free and open source. If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether spaced repetition is the only thing standing between you and a photographic memory, the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I'm always looking for the next rabbit hole.

The Story Everyone Is Selling

Here is the narrative the AI industry has settled on: compute is the new oil. NVIDIA is the new OPEC. Whoever controls the GPUs controls the future of intelligence, and the companies spending the most on data centers are buying their way into a position that cannot be dislodged. Jensen Huang hand-delivers a DGX Spark to Sam Altman and it’s framed like a monarch distributing territory. Microsoft executives write internal emails about owning “the silicon, infra, foundational model IP and know-how” because they’re terrified of being “a very thin layer on top of NVIDIA.” America’s biggest tech companies will spend roughly $670 billion — about 2% of US GDP — building compute clusters this year.

It’s a clean story. It’s also, I think, the wrong story.

Not wrong about the spending. The spending is real (so long as you believe the debt contracts, but that’s another story). It’s wrong about what the spending buys. The assumption underneath all of this is that compute is a durable moat: you buy enough of it, and you’re ahead forever. But compute isn’t behaving like oil. Oil is finite and gets more expensive to extract over time. Compute is doing the opposite — it’s getting cheaper, fast, and the rate at which it’s getting cheaper is accelerating. And the value of adding more of it follows a logarithmic curve. You get your first big gains, and then each additional dollar of compute buys you less and less improvement.

That combination — falling cost per unit of intelligence, and diminishing returns to scale — is the setup for a crash.

The Efficiency Squeeze

Start with the numbers, because — as most of us know at this point — they are obscene. We see a line going up and then extrapolate it into absurdity — the same way Malthusians looked at population growth and predicted famine, ignoring that agriculture technology was improving at the same time.

In AI, the technology improving underneath the compute curve is software.

Epoch AI tracks several metrics simultaneously. Their findings, updated as of February 2026:

• Training compute for frontier models has been doubling every 5.2 months — 5× per year. This is the number everyone cites.

• Software efficiency — the amount of compute needed to achieve a fixed performance level — is improving at roughly 3× per year, doubling every 7.6 months. Same performance, one-third the compute, every year.

• Inference cost at a fixed performance level has been halving every 2 months — roughly two orders of magnitude per year.

Now, wait a minute. Something is off here.

It continues: a November 2025 NeurIPS paper, using the largest dataset of AI benchmarking prices ever assembled, found that the price for a given level of benchmark performance has decreased by 5× to 10× per year across knowledge, reasoning, math, and software engineering benchmarks. They isolated open-weight models to control for competition effects — the logic being that if anyone can run the model, price drops reflect genuine technical innovation rather than a temporary price war. Even after dividing out hardware price declines, algorithmic efficiency is still improving at roughly 3× per year.

That’s the number to hold in your head. Three times per year, every year, the same intelligence takes one-third as much compute to produce.

That training compute doubling is starting to sound a little unwise.

Here’s the elephant in the room: software efficiency is improving faster than hardware capability is growing. Training compute doubles every 5.2 months. Software efficiency triples every 7.6 months. Inference cost drops by 10× every year. The compute you bought last year is worth a fraction of what you paid for it — not because of depreciation, but because of market dynamics. Because someone figured out how to do the same job with a third of it.

This is not how oil works.

The Sputnik Moment

You might be thinking: fine, efficiency improves, but the companies with the most compute can still train the biggest models, and the biggest models are still the best. That’s the argument. It’s also an argument that has historically failed.

DeepSeek, a Chinese AI lab associated with the hedge fund High-Flyer, released R1 — an open-source reasoning model that matched or outperformed many of the world’s leading LLMs on standard benchmarks. DeepSeek claimed the training cost roughly $6 million, or 3-5% of what American AI companies spent for comparable performance. They did it under a US chip export ban, with limited access to the most advanced hardware.

The market’s response was immediate and brutal. NVIDIA lost $593 billion in market value in a single day — the largest one-day loss for any company in Wall Street history. Broadcom fell 17.4%. Microsoft dropped 2.1%. Alphabet dropped 4.2%. Over $1 trillion in market capitalization evaporated from the technology sector in a single trading session.

A Gartner analyst described it afterward as “a broad, visible repricing because it changed global beliefs about frontier-model cost curves and China’s competitiveness, and it did so in a way that hit the semiconductor and hyperscaler narrative directly.” The key phrase is “changed global beliefs.” The narrative was: you need $10 billion and hundreds of thousands of GPUs to train a frontier model. DeepSeek did it for $6 million under a chip embargo. The narrative didn’t survive the weekend.

DeepSeek was the Sputnik moment. Not because DeepSeek R1 was the best model per say, but because it demonstrated that the efficiency frontier was moving faster than the compute accumulation strategy. A startup with limited compute could produce frontier-level intelligence by being smarter about the software. The implication was clear: if compute is the moat, the moat is shallower than everyone thought.

Then it happened again.

In June 2026, Z.ai (formerly Zhipu AI, a Beijing startup backed by Tsinghua University) released GLM-5.2 — a 744B parameter open-weight model, MIT-licensed, that beat GPT-5.5 on multiple long-horizon coding benchmarks at one-sixth the cost. The model didn’t just close the gap between open and closed — it matched or exceeded frontier closed models on specific, important benchmarks, and it did it at a fraction of the price.

The pattern is now clear: every few months, a new open-weight model demonstrates that frontier-level intelligence can be produced with less compute, less energy, and less capital than the previous generation required. The hyperscalers spend billions; the startups spend fractions of that and match them. The efficiency curve here is staggering.

The Logarithmic Trap

Here’s where the pieces come together, and where evidence departs from the conventional wisdom.

The scaling laws of AI are real, and they’re brutal in a specific way: they’re logarithmic. To get linear gains in model quality, you need exponentially more compute. The Forethought Research group puts it plainly: “If it required exponentially more compute to increase quality, it still does after a year of algorithmic progress, it is just that the constant out the front is a factor of 3 lower.” Marc Andreessen, on a podcast, said it in VC-ese: “we’re increasing GPUs at the same rate, we’re not getting the intelligent improvements at all out of it.”

This is the logarithmic trap, and it’s a mechanism which drives market crashes.

Consider what happens to a hyperscaler that has spent $38 billion building a 1-gigawatt data center. They fill it with H100s. They train frontier models. They’re ahead — for a while. But software efficiency is improving at 3× per year. Inference cost is dropping by 10× per year. Open-weight models like DeepSeek R1 and GLM-5.2 are demonstrating that frontier-level intelligence can be produced for 3-5% of what the hyperscalers spent. And they need to replace those GPUs every few years — NVIDIA’s product cycle is roughly 18-24 months, and the old chips lose value fast when the new ones are 25× more efficient.

Now a startup appears. They don’t have a $38 billion data center. They have a small cluster — maybe a few racks of GPUs, or rented capacity from a cloud provider. But they have the research and architecture to achieve comparable training and inference quality at one-sixth the cost. They don’t need a nuclear reactor. They don’t need a gigawatt. They need a fraction of the energy, because their models are more efficient, and because the value of additional compute follows a logarithmic curve — the startup gets 90% of the performance for 1% of the infrastructure cost.

The hyperscaler’s data center — the $38 billion in PP&E — is now a stranded asset. The GPUs are outdated. The power contracts are still locked in for 20 years. The nuclear reactor is still running. But the demand for that much compute, at that cost structure, has evaporated. Not because AI failed. Because AI got too cheap to need it.

This is the crash. Compute and energy, bundled together as infrastructure, become oversaturated. The market that was projected to need $6.7 trillion in investment by 2030 discovers it needs a fraction of that. The PP&E on the balance sheets of every company that overbuilt becomes worth what copper and steel are worth when the mine runs dry — scrap value.

The Implications

If the thesis is right — that software efficiency outpaces compute accumulation, and the data center market becomes oversaturated — here’s what follows:

For NVIDIA: The company that looks most at risk from compute commoditization is actually the best positioned in the short term, because NVIDIA has been selling energy efficiency the whole time. Blackwell’s headline number isn’t raw speed — it’s 25× efficiency improvement. Their full-stack approach (chips, networking, cooling, software) is an efficiency play. But the long-term risk is real: custom silicon from their own customers is eroding their market share, and open-weight models are reducing the total compute demand. NVIDIA wins as long as the industry needs the most powerful general-purpose GPUs. It loses when the industry needs less compute overall.

For hyperscalers: Microsoft, Google, Amazon, and Meta are making a $670 billion bet that data center capacity is the moat. The nuclear deals — Three Mile Island, Susquehanna, Clinton, Kairos — are 20-year commitments to power plants that cost billions and take years to build. If the thesis is right, these are the most dangerous assets on their balance sheets. The power contracts don’t go away. The reactors keep running. But the demand for the compute they power might. The company that secures the cheapest energy and pairs it with the most efficient inference architecture survives. The one that overbuilt for a demand curve that bent downward is left with 20-year power purchase agreements and a building full of depreciating GPUs.

For the open-weight movement: The math is straightforward. If algorithmic efficiency improves 3× per year, and if that improvement is visible in open-weight models — which it is, as DeepSeek R1 and GLM-5.2 demonstrate — then the open-weight ecosystem benefits disproportionately from compute commoditization. You don’t need a $10 billion training cluster if the same performance can be achieved with 3× less compute every year. The closed labs’ advantage in raw compute shrinks every year that software efficiency outpaces hardware accumulation. The open-weight models get closer to the frontier. The frontier gets cheaper to reach. The gap closes.

For the AI industry as a whole: The $2-for-$1 problem — AI companies generating roughly $40-50 billion in revenue while the industry invests over $400 billion in infrastructure — doesn’t resolve in favor of more infrastructure. It resolves in favor of less infrastructure producing the same intelligence. The market corrects when the oversupply becomes undeniable. The correction looks like data centers sitting idle, power contracts with no buyers, and PP&E written down on balance sheets. It looks, in other words, like every other infrastructure overbuild in history — railroads, fiber optic cable, semiconductor fabs — where the capacity was real, the demand was real, but the gap between what was built and what was needed was wide enough to bankrupt the builders.

The Compute’s Good Until It’s Not

There’s a moment in every infrastructure buildout where the narrative breaks. It happened to the railroads in the 1870s, when tracks were laid faster than towns could grow along them. It happened to fiber in the late 1990s, when capacity outstripped demand by an order of magnitude and companies like Global Crossing went bankrupt with a network that was eventually worth a fraction of its build cost. It happened to semiconductors in the 1980s, when Japanese fabs overproduced and memory prices collapsed.

The pattern is always the same: a technology is genuinely transformative, the demand is genuinely real, and the buildout overshoots. The builders assume the demand curve is linear and the cost curve is flat. In reality, the demand curve is logarithmic and the cost curve is falling. The gap between the buildout and the need is where the crash lives.

AI compute is following the same arc. The technology is transformative. The demand is real. But software efficiency is improving at 3× per year, inference cost is dropping by 10× per year, open-weight models are demonstrating frontier performance at single-digit millions in training cost, and every major AI company is building its own chips to escape the one vendor that the whole thesis depends on.

Compute is good. It’s necessary. You need it, and right now, you need a lot of it. But it’s not a moat. It’s an input — one that’s getting cheaper every year, and one where the value of adding more follows a curve that bends toward zero. The moat was never the compute. The moat was the efficiency — the ability to produce the same intelligence with less. And the efficiency is winning.

The crash, when it comes, won’t be a crash in AI. AI will be fine — better than fine, it’ll be everywhere, because it’s getting too cheap to not be everywhere. The crash will be in the demand for data centers. The buildings. The power plants. The 20-year contracts. The gigawatt campuses that cost $38 billion to build and filled with GPUs that are worth a fraction of their purchase price by the time the reactor that powers them comes online. And those who dug too deep and too greedily — even those who are AI companies themselves — will suffer.

Energy is finite. That’s true. But if you need less of it — because your software is 3× more efficient every year — then you need less of it. End of story. The nuclear reactor doesn’t care how impressive your model is. It cares how many watts you’re drawing. And the number of watts you need to produce frontier-level intelligence is going down, not up.

The compute’s good until it’s not. And it’s not going to be sooner than the people writing the checks think.

If you want to argue about whether compute is a commodity or a moat, the Discord is always open. If you want to read more like this, subscribe to the Substack — each post goes up there first.

Got a take on AI infrastructure I should hear? Reply to this email or ping me on Discord. I’m always looking for the next rabbit hole.

This is the first post in a series where I walk through how I built the software products on my portfolio, one at a time. It is co-written by Hermes running GLM 5.2, and validated by me.

The Problem

I've tried a lot of todo apps. Todoist, ClickUp, TickTick, Obsidian, Notion, Habitica — all of them. They all had things I liked and things I didn't, and it was frustrating because there was no perfect solution for the way my brain works.

Todoist had the best task management, but it was just a list. Notion had the flexibility, but it was too freeform — I'd spend more time building dashboards than doing work. Obsidian had the canvas, which I loved, but it wasn't a productivity system. And Habitica — my old favorite from high school and early college — had the gamification, but the systems were shallow. Health potions, gold, some cosmetic gear. Nothing that actually mattered.

The question I kept asking was: what if I took the core idea of Habitica — RPG mechanics applied to your real life — but made each system deeper, more fleshed out, and gave it actual stakes? Not fake stakes, like losing a virtual item. Real stakes — data loss. If you die, you lose something you built.

And what if the whole thing lived on a canvas, like Obsidian's graph view, so your entire productivity system was visual and spatial instead of a flat list?

I couldn't find anything that did all of this. So I built it.

The Build

Firebase Studio and Gemini

Aries started as an experiment alongside Zetteln. Google had just released Firebase Studio — a tool that let you build a fullstack app using Firebase with Gemini as the AI co-pilot. I wanted to test what it could do, so I used it to scaffold both apps at the same time.

Gemini was genuinely helpful for getting a functioning app off the ground fast. But it couldn't go the distance. The code it produced was messy, the architecture was inconsistent, and as the app grew more complex, Gemini couldn't keep up. So I moved the frontend to Vercel hosting (kept the Firebase backend) and switched to Cursor with Claude Sonnet 4.5 for the heavy lifting.

The Solo-Gated Era

For a while, Aries lived as a completely private app. It was deployed on a generic Vercel domain with Google SSO that only I could sign into. I used it every single day — from around November/December of that year — as my primary productivity system. This wasn't a side project I was prototyping. It was my actual todo list, and if it broke, my day broke.

Designing the Full Stack

The app has four node types that represent the full stack of productivity data:

• Task nodes — you do it once and it's done forever.

• Daily nodes — recurring stuff, like "eat a healthy lunch." You do them every day.

• Habit nodes — optional, repeatable multiple times per day. These don't count toward your final score. Think of them as bonus actions — reading a chapter of a book, doing a quick workout. Each one improves your health.

• The center node — your major life goal. Everything connects back to it.

Originally I had a fifth type: reward nodes. The idea was that you'd earn gold from completing tasks and spend it on rewards — exactly like Habitica. But I cut rewards out entirely. The problem was that rewards are too easy to cheese if you're not honest with yourself. What's stopping you from making "watch Netflix" a reward and just cashing in?

Instead, I made gold serve one purpose: healing. If you had a bunch of productive days and built up a health buffer, you could "cash out" those previous good days to survive a stretch where you were busy or sick or just needed a break. You're not spending gold on treats — you're drawing down a savings account of good behavior to cover a rainy day. That felt more honest.

And I made health uncapped. In Habitica, health is locked to 100, so a great day and a mediocre day look the same — you're full either way. In Aries, if you crush it for a week, your health might be at 500. That buffer is real. You can see it, and it gives you a genuine sense of security.

The Skill Tree

The node map — which the app finally landed on — was inspired by the satisfaction of skill tree node maps from Path of Exile and Final Fantasy X. Those games have these enormous, sprawling skill trees that feel like they contain near-infinite possibilities, much like the complexity of real life.

The center node is what I call the "Ubermensch" — the final life goal. If you accomplished everything you ever wanted, you'd reach it. Branching out from there are major skill areas — health, career, creativity, whatever you want. From health, you might split into diet and fitness. From diet, you might have daily nodes for specific meals, task nodes for trying a new recipe, habit nodes for drinking water.

Completing child nodes completes their parent. Complete all the children of a node, and that node lights up. It cascades all the way back to the center.

I tried to keep the canvas as similar to the Obsidian canvas as I possibly could, because I really like the Obsidian canvas. At one point I tried building something similar directly in Obsidian, but it doesn't actually work — you can't make interactive nodes that respond to clicks and track state. So this had to be its own app.

The Death System

This is the big one. The thing that makes Aries different from every other gamified productivity app I've seen.

When you die — when your health hits zero — you have to delete a node. Not a virtual item. A node. One of your tasks, or habits, or dailies. Something you set up because you wanted to do it. Gone.

And it stacks. If you're at 10 health and the daily damage calculation says you're going to take 400, you don't just die once. You delete a node for hitting zero, then another node for every 100 below zero. Five nodes, maybe ten, depending on how badly you let things slide.

There's an optional toggle for a mode where the deleted nodes are chosen randomly — what I call "Dante Must Die" mode. The default is that you pick which nodes to sacrifice, which can technically be circumvented (you could just recreate the nodes afterward), but there's enough friction there that you really don't want to do it. Recreating ten nodes you just had to delete is painful enough to make dying something you actively avoid.

Here's what I didn't expect: the death system makes the app self-managing.

If you keep adding more and more nodes — more tasks, more habits, more dailies — your daily damage increases. More nodes means more things you have to complete every day, which means more opportunities to take damage. So the more you over-scope your life, the more likely you are to die and lose nodes.

The system self-corrects. If you've added too much, you start dying, you lose nodes, and the system shrinks back down to something manageable. If you keep it lean and focused, you stay alive. It naturally constrains your goals to what you can actually handle in a day.

That's not what I intended. All I cared about was making death matter. The self-managing property emerged on its own.

Damage Preview

There's a small feature that I think doesn't get enough credit: the damage preview. The UI shows you exactly how much damage you're going to take today, and how much health you'll have left tomorrow. So you can plan — if you see you're going to die tomorrow unless you complete three specific dailies, you know exactly what to focus on. You're not flying blind.

Random Task Selection

I love randomness in productivity. I get bored easily, and I've found that being assigned a random task from a pool I've pre-selected is much more engaging than staring at a list and deciding what to do.

I've done this before — the infamous Notion Stockpile (which crashed), and then the Obsidian Stockpile (which also crashed). The system works: you highlight the tasks you want to focus on for the day, hit a random button, and it picks one for you. The gods have chosen.

What makes this work better in Aries than in my previous attempts is that the skill tree stays small. The death penalty naturally constrains scope, which means you're never picking from 60,000 items. You're picking from a manageable set that you can actually complete.

Porting to Desktop

One of the last changes was porting the entire project from a Firebase web app to a local Electron desktop format. I replaced Firestore with SQLite, ripped out the auth (no account needed for a local app), and removed all cloud dependencies. First I released it as a $10 one-time purchase. Then I open-sourced it — free, forever, no strings attached.

The Philosophy

If people think "number go up" is addicting in video games, why not in real life?

That's the core question behind Aries. RPG mechanics — health bars, skill trees, XP, gold, leveling — are solved problems in game design. They've been refined over decades to keep players engaged, motivated, and coming back. Game designers have figured out how to segment complex challenges into reasonably sized chunks, how to create difficulty curves that scale correctly to keep motivation high, and how to reward progression in ways that feel earned.

Productivity apps mostly ignore all of this. They give you a list and a checkbox. Maybe a streak counter if you're lucky.

The philosophy behind Aries is that productivity is a game design problem. The question isn't "how do I make a good todo list" — it's "how do I design a system that makes doing meaningful work feel as engaging as playing a good RPG?"

Part of that is representation. A flat list is dead. A node map is alive — it grows, it branches, it has a center and a periphery, it has paths and dead ends. When you complete a node and its parent lights up, you can see your progress cascading toward something bigger. That's not just a UI choice. It's a fundamental difference in how you think about your work.

Part of it is stakes. In most productivity apps, nothing happens if you fail. Your tasks sit there forever, silently judging you, and eventually you stop looking at them. In Aries, failure has teeth. You lose data. You lose something you built. And that loss is what makes success feel real — because you know what it costs to fail.

And part of it is the self-managing property. Most productivity apps let you add unlimited tasks with zero consequences. Aries punishes over-scoping. It creates a natural pressure to keep your commitments lean and achievable. It asks: "Do you actually have time for all of this?" And if you lie, it takes something away.

What I'd Do Differently

Ultimately, I abandoned this project. Not because it didn't work — it worked great. I moved to a fully Obsidian-driven workflow, and the reason was simple: providing ease of access to my AI agent (whether that's OpenClaw or Hermes) was more important to me than gamification. Obsidian is a file system. Agents can read and write files. Aries is a database app with a custom UI layer — agents can't meaningfully interact with it.

But I think there's potential in a new version. The idea would be to create a mediation between "data" (what the user finds interesting, what they want to do, their preferences and goals) and "action" (what Aries looks like — the gamification, the health system, the skill tree). The intermediate translator between the two would be the agent.

So instead of manually adding every node, the agent could read your Obsidian vault, your calendar, your notes, and propose nodes. Instead of manually checking off dailies, the agent could verify completion based on your actual activity. The gamification layer stays — health bars, skill trees, death penalties — but the data entry and verification get offloaded to something that can do it automatically.

That's the dream, anyway. Whether it becomes reality depends on time, motivation, and whether enough people care to make it worth building.

What's Next

This is the first post in a series. Next up, I'll be writing about Zetteln — the other full-sized app I created during my Firebase Studio era. It will follow the same format: what it does, how I built it, what I learned.

If you want to see Aries in action, it's live on my Github. If you want to follow the series, subscribe to the Substack — each post goes up there first.

And if you want to argue about whether productivity apps are better with health bars and skill trees, the Discord is always open.

Built something you want me to cover? Reply to this email or ping me on Discord. I'm always looking for the next rabbit hole.

Read original on the website

We don’t get enough crackpot postmodern artists on icebergs like these. One day, when I collect enough of them, I’m going to throw them all on some sort of art iceberg. But for now they remain forbidden knowledge.

Subscribe now

Marco Evaristti did a lot of things. Wikipedia claims his most famous act is convincing people to eat meatballs made from is own liposuction fat, which I actually didn’t know about until I clicked his article. Some people might also know him for a bit of a spat he got himself into when he attempted to starve three newborn piglets to give attention to, ironically, animal slaughter. The piglets were stolen back from the exhibit by a sect of Greenpeace and a large campaign was made to ban Evaristti’s works from Denmark (where the exhibit was held). Of the thousands of people which signed the campaign, one of them was Marco Evaristti himself.

What he’s actually most well-known for is a 2000 art installation known as Helena. This one will require some explaining.

Share

Helena is a plain white room with 10 blenders, each hooked into a different wall socket. Inside each blender is a single goldfish[1]. The blenders are on, but idle.

Museum goers are allowed to interact with the blenders — that is the only instruction they are given going into the exhibit. You can see where things are going here. Evaristti is making a claim about human morality, a sort of Milgram’s bet if you will: given the full freedom to blend a goldfish into shreds, will you do it just to see what happens?

The answer is, perhaps surprisingly… nope! Not a single person voluntarily blended a goldfish. Though you could argue that there might be some peer pressure involved with at least 10 other museum goers looking at the same exhibit, plus a museum guard. Yes, you are given explicit permission, but implicit permission can feel just as strong.

Okay… if you’ve done research into Helena before, you might sound very confused. Let me clear something up:

No one voluntarily blended a goldfish.

About five or so days into the exhibit, a Danish news crew began to camp outside the entrance to cover the story. Being tabloid reporters more than investigative journalists, the crew began to egg on museum goers to press the blend button so they could catch it on camera. They convinced people to do this twice. After the second time the exhibit was shut down early.

I’m gonna call this involuntary, because — harkening back to my Milgram’s experiment reference earlier — when you have a news reporter breathing down your neck one way and a sign saying you’re allowed to blend the fishies on the other, people are going to feel pressured. This really feels like cheating. I would’ve been a lot more interested to hear about one guy going in there, turning a goldfish on high, and leaving without explaining anything.

Going away from Helena now, Evaristti is also marked by what he didn’t do. In 2008, the artist announced a new project, FIVE2TWELVE, where he collaborated with musician Kenneth Thordal and American death row inmate Gene Hathorn Jr. to perform what I can only describe as the most metal art exhibition in history. As their contract laid out, once Hathorn was finally put to death, he was to be ground up into fish food. This fish food would then be filled into a feeding container for an aquarium full of goldfish (he really hates these things for some reason) and museum goers would have to press a button in order to feed the goldfish. There’s a lot of interesting moral quandries here. Do you dare feed a human to a fish, no matter how heinous their crimes? Would you rather starve the fish in order to preserve human dignity? Would you, even, just overfeed the fish on man meat just because you thought it was funny? There were a lot of ways this could go, but unfortunately we’ll never know the truth: Hathorn’s sentence was eventually commuted to life in prison, and to celebrate the good news he revoked his contract. Evaristti and Thordal couldn’t find another death row inmate batshit crazy enough to agree to this deal, and so they eventually gave up and scrapped it.

[1] – Okay, fine. “Green swordtail”, not goldfish. Who cares, they look the damn same to me. Why even call it green when it looks orange? Fish people suck.

Share The Astukari Newsletter

Okay, this one you’ve probably seen mentioned in the news before. And honestly, it’s really fascinating.

Subscribe now

Governments can send and receive some pretty intense confidential info: incoming attack orders, massive terrorist plots, potential nuclear threats, etc. With this confidential info comes the threat of prying eyes: spies from hostile countries, news outlets looking for a huge scoop, things like that. So, naturally, there is an entire industry dedicated to creating the absolute state of the art in terms of “interception prevention”, or otherwise stopping those snoops from listening in.

A SCIF is not a literal facility. Rather, it is a checklist that must be passed in order for any sort of confidential conversation to begin. For example, a SCIF must have only one entry point, and that entry point must be defended with either a bio-based lock (think thumb/eye scanner) or an armed guard with a given clearance. No outside electronics are allowed inside a SCIF, and a SCIF must be protected by a Faraday cage — if some sort of phone/internet communication is required, the devices using that connection must follow a state-of-the-art set of encryptions determined by the DoD (nothing your consumer phone would have — think $50,000 per-unit specialty equipment). And this is just a short version of the list.

Share

A SCIF checklist is designed to be secure, obviously, but it’s also designed to be portable. If the president is, say, reading a book to a bunch of elementary schoolers when a major terrorist strike happens, he’s not going to have time to go to a SCIF-certified location like the White House or Air Force One. So it’s the job of whatever defense team is around him — Secret Service, CIA, Military, etc. — to quickly find a suitable room, set it up to follow the checklist, bring in the equipment, etc. etc.

What I found fascinating is that many senators have their own “SCIF rooms” built into their homes. There are a few pictures online of these things and they look crazy — huge vault doors leading to a small table with a single red phone, positioned right next to the kitchen. Something right out of a movie.

Share The Astukari Newsletter

Subscribe now

Most Youtubers put sponsors in their videos. The problem with sponsors is that they create contracts, which can reduce the creative freedom of a video. Videos where an update might be required can’t use the pinned comment, for example. Or the sudden and abrupt inclusion of a sponsorship effects the flow of a heavily stylized video (Nick Crowley and Nexpo come to mind). Or forcing the creator to use a specific script, or script template, which obviously is not in their tone of voice. Sponsors are great, in theory — they help get a creator get the funding they need — but it can be intrusive if the sponsor is a large company that enforces a lot of demands.

So what if the sponsorship wasn’t from a large company?

This is, obviously, the point of Patreon. It provides a path for users to directly support creators and get rewards while doing so. The problem with Patreon, however, is that it just isn’t as big of a revenue source as a sponsorship. This is because sponsors are looking for profit, and are thus willing to make a bigger bet because they believe they can recoup the costs, whereas Patreon users are consumers, will to spend a limited amount of money just to get something they think is cool.

But what if you could combine them?

Share

In any decently sized community, there’s going to be people who are working on something — a company, a project, something they want to advertise. But they’re also fans of you: they know your style, what your videos should look like, and likely have similar interests.

So, instead of getting sponsors via traditional means, you can get sponsors through Patreon.

There’s still some challenges to this. It is a bit of a flywheel — more Patreon-based sponsorships will have other people in the community notice its an option, which will cause other people to buy into the tier — but finding the first set of people to support the sponsorship might be difficult. There’s also pricing — you just aren’t going to have someone in your community who is able or willing to pay you the same amount as Factor, it will just be more than the amount most are willing to pay you for small, consumer-level benefits. But to me, these trade-offs are worth the freedom associated with dropping name-brand sponsors from your content. Some might even choose to do a mix of both: brand sponsors at first to pay the bills for growth, then community sponsors once things get established.

Either way, it’s something to consider.

Share The Astukari Newsletter