So what will you do? Will you settle for the access to intelligence that you currently have, or will you fight for more?

Tokenmaxxing is your way out. By massively increasing your consumption of tokens, you can scale the capabilities of the underlying models that serve them.

In this guide, we explain why this works and provide tips on how you might apply it productively to your work. But first, let’s look at how scaling compute leads to more intelligent models.

Scaling Laws

Modern LLMs are built and deployed in stages.

First, AI labs train a base model through pre-training, often followed by mid-training or continued pre-training to refine capabilities such as reasoning, coding, long-context handling, or domain knowledge.

Second, they perform post-training, using methods such as supervised fine-tuning, preference tuning, reinforcement learning, and safety tuning to improve instruction-following, alignment, reliability, and task performance. After this stage, the AI is ready to deploy.

Third, the deployed model produces answers through inference, where the trained weights are used to process a user’s input and generate output.

Sam Altman describes this eloquently in his 2025 blog post, Three Observations:

The intelligence of an AI model roughly equals the log of the resources used to train and run it. These resources are chiefly training compute, data, and inference compute. It appears that you can spend arbitrary amounts of money and get continuous and predictable gains; the scaling laws that predict this are accurate over many orders of magnitude.

We will explore this a bit more in detail for each phase of the AI development and deployment process.

Train-Time Compute

At train-time (pre-training and mid-training), the result couldn’t be more clear. If you have a bigger data center, you can produce a better model. This was convincingly established by Kaplan et al., “Scaling Laws for Neural Language Models”.

Post-Training Compute

During post-training, intelligence also scales with compute—although it is worth mentioning that this process is multi-factorial and has a variety of other bottlenecks, such as the quality of the reward signal. Nevertheless, the results are clearly shown by Khatri et al., “The Art of Scaling Reinforcement Learning Compute for LLMs”.

Test-Time Compute

Test-time compute, also known as inference-time compute, is the process of using more compute during inference—which can actually improve the quality of the output of a model that is already trained. This form of scaling is explained well in Muennighoff et al., “s1: Simple test-time scaling”.

This is core to the difference between ChatGPT Instant, Thinking and Pro.

Although there may be differences between the underlying model weights, fundamentally Pro thinks much longer than the other modes. In essence, it generates more tokens and, by scaling its token usage, it produces a better result.

The following graph was published when OpenAI released their o-series reasoning models, a precursor to the latest ChatGPT 5.5 series.

As you can see, using the same model (o3), they were able to increase the score on a the ARC-AGI benchmark by simply increasing the compute budget. Although their exact reasoning methods are proprietary, a large portion of these gains come from simply allowing the model to “think longer” by generating more tokens before arriving at a final result.

With that said, test-time compute is very broad and labs are constantly working on more sophisticated methods. Later in this guide, we will discuss DeepMind’s AlphaEvolve, which they also frame as a test-time scaling method.

But we can draw an important distinction between AlphaEvolve and ChatGPT’s Pro reasoning.

Both implement test-time scaling, but ChatGPT Pro does so on the provider’s side while AlphaEvolve does so on the consumer’s side. In other words, DeepMind implemented AlphaEvolve by wrapping a harness around standard Gemini models. For AI researchers, this distinction is not very important. But for consumers like us, this makes all the difference in the world.

The core insight is we would like to offer is that you can scale test-time compute yourself, as a consumer.

There is ample evidence to prove that this works, which we will explore later in this guide.

Consumer Test-Time Scaling

Consumer-side test-time scaling is the process of increasing how much inference you use, as a consumer. In other words, it is tokenmaxxing.

It can be measured by increasing what we sometimes refer to as harness-time compute, which is calculated as the average amount of compute per inference call times the number of calls you make to achieve a single result.

You can intuitively think about it like this: Since a single inference call will have a limited compute budget, wrapping that inference call in a harness that makes multiple inference calls can essentially force an AI to continue thinking.

In the previously shown o-series benchmark chart, o3-high had 172x the compute of o3-low. Now think about this: might it be possible for one to approximate o3-high level results by calling o3-low 172+ times to check its own work? This has not been explicitly demonstrated, but there is a good reason to believe that a properly designed consumer-side test-time scaling system could achieve something to this effect. We will explore the evidence for this in the next section.

The Churning Technique

One of the best ways to scale consumer-side test-time compute is through a general process we call churning.

Churning is traditionally a process of mixing milk until it produces butter.

Doing one rotation with a hand-crank churn will not produce butter, but after 1000 rotations it will.

In the context AI, churning is the process of asking AI to do the same thing 10, 100, or possibly even 1000 times. In doing so, it eliminates the problems in its work product and produces butter—uh, I mean better—results. Through each iteration, the core prompt usually remains constant, while providing the model with updated context so that it can build on its past work.

Ask yourself this: why do you use Claude Code and Codex instead of asking ChatGPT Pro to one-shot your app? It’s obviously because agents generate superior results.

We would argue that agents work by churning.

If you think about it, an agent basically runs inference in a loop, continuously adding to the context so that the next inference call can check its past work and correct its mistakes.

While reasoning models employ many techniques to keep their test-time chain-of-thought on track, agents are constantly grounding their work in the real world by testing, type checking, and compiling your app.

This ultimately explains why Yann LeCun’s concern about compounding error in autoregressive models doesn’t prevent agents from completing tasks with very long threads.

When an agent gets off-track, real deterministic tool call results collapse the error.

Agents are the clearest example of churning today, but we will argue that it is possible to employ this technique in other contexts as well.

Self-Refine

One generally effective way to improve LLM output is thought a process called iterative refinement, as shown in Madaan et al., “Self-Refine: Iterative Refinement with Self-Feedback”

They ran a fully autonomous review process where an LLM gave itself feedback and then took that feedback to refine its previous answer in a loop.

This improved the performance of the LLM across all tasks, with an average benefit of 20% from 4 iterations. While they did notice diminishing returns, it is worth noting that all forms of compute scaling (train-time, post-training, and test-time) face diminishing returns whenever they are measured.

Based on their published data, we created a chart to visualize the improvements for each type of task across each iteration.

Certain tasks clearly are more suitable to this specific approach than others, but every task they tested benefited from more iterations nonetheless.

In some ways, this is a naive and suboptimal approach. It is likely possible that there are better ways to churn results for any given task, but the exciting part about this is that this generalizes well across all tasks.

So What?

To build an intuition for why this is powerful, imagine if you ran this generic, fully automated process on every inference call you made. Your inference costs would ~9x (the original prompt + 4 iterations of one feedback prompt and one review prompt), but on average you would benefit by getting 20% better results. In our previous article How Startups Can Beat Big AI Labs, we discuss why a fixed cost increase is usually worth accepting for a compounding benefit.

…scaling AI usage to produce a better result is worth paying more for despite the fact that it has diminishing returns.

…the cost and value scale with different curves. Cost increases linearly, you pay a fixed amount more each month. If your plan is priced at $3000, compared to the $200 plan, that is $2800 extra in cost per month. So in January the company pays $2800 more, in February it increases to $5600… and by December the total reaches $33600. This is just a fraction of an engineer’s salary.

But a 20% better result compounds. Productive work builds on past work and technical debt grows exponentially. In January the product is 20% better, in February it is 44% better… and in December it is 892% better.

Compositional Approaches

Test-time scaling methods are composable.

Agents themselves use reasoning models while scaling further by churning. And that’s not even the end of the story.

A new class of consumer-side test-time scaling has recently emerged as a layer that wraps around agents. It turns out that you can ask agents to work on the same problem many times—and doing so often vastly improves their capabilities.

Properly scaling any part of this stack should amplify the performance of the other parts.

So let’s explore how we can churn on this top layer.

Autoresearch

The great Andrej Karpathy famously pioneered a technique called autoreseach, which essentially runs an agent in a loop giving it a task and an objective metric by which it can evaluate its work.

He describes the process like this:

The idea: give an AI agent a small but real LLM training setup and let it experiment autonomously overnight. It modifies the code, trains for 5 minutes, checks if the result improved, keeps or discards, and repeats. You wake up in the morning to a log of experiments and (hopefully) a better model. The training code here is a simplified single-GPU implementation of nanochat. The core idea is that you're not touching any of the Python files like you normally would as a researcher. Instead, you are programming the program.md Markdown files that provide context to the AI agents and set up your autonomous research org. The default program.md in this repo is intentionally kept as a bare bones baseline, though it's obvious how one would iterate on it over time to find the "research org code" that achieves the fastest research progress, how you'd add more agents to the mix, etc. A bit more context on this project is here in this tweet and this tweet.

We created a visual for this process like this:

As you can see, he was able to improve his model substantially after 83 iterations.

Autoresearch is beautiful and simple. But other researchers have automated research in more elaborate ways. As mentioned earlier, DeepMind’s AlphaEvolve scaled test-time compute massively while using standard Gemini models. This required them to generate thousands of LLM samples—which is orders of magnitude more than Karpathy’s 83 iterations visualized above.

Although, we must admit, including “AGI” in the title of this guide is intended to be clickbait, AlphaEvolve arguably gets close. Its results are astounding. Some of its breakthroughs are now implemented in production code at Google today.

AlphaEvolve’s procedure found an algorithm to multiply 4x4 complex-valued matrices using 48 scalar multiplications, improving upon Strassen’s 1969 algorithm that was previously known as the best in this setting. This finding demonstrates a significant advance over our previous work, AlphaTensor, which specialized in matrix multiplication algorithms, and for 4x4 matrices, only found improvements for binary arithmetic.

To investigate AlphaEvolve’s breadth, we applied the system to over 50 open problems in mathematical analysis, geometry, combinatorics and number theory. The system’s flexibility enabled us to set up most experiments in a matter of hours. In roughly 75% of cases, it rediscovered state-of-the-art solutions, to the best of our knowledge.

And in 20% of cases, AlphaEvolve improved the previously best known solutions, making progress on the corresponding open problems. For example, it advanced the kissing number problem. This geometric challenge has fascinated mathematicians for over 300 years and concerns the maximum number of non-overlapping spheres that touch a common unit sphere. AlphaEvolve discovered a configuration of 593 outer spheres and established a new lower bound in 11 dimensions.

Autoresearch works particularly well because you can easily and efficiently quantify the loss in an AI model. Both Autoresearch and AlphaEvolve work well with anything that can quickly generate objective quantifiable results that you can measure an experiment against.

However, churning works for things that are less objective and quantifiable as well.

Ralphing

Ralphing, invented by Geoffrey Huntley, is the process of running an agent in a loop so that it can complete a task that is too complicated for it to otherwise complete in a single shot. This is particularly useful when the scope of the project is so large that the agent will get sidetracked by compacting its context numerous times before it is able to achieve its goals.

The process itself is simple. You pin your product spec to SPEC.md and you instruct the agent to audit the current implementation of the codebase to see if it fully adheres to the spec, and if not to implement the spec.

At first, the agent will find the spec has not been implemented and so it will take a pass at trying to build it. Since the project is presumably very complex, it won’t succeed on the first try. However, at this point the loop restarts and you instruct it to audit the codebase again. This time it will find it is slightly closer its goal but has more work to do—and it will take another pass at it. After many iterations, the project will be successfully completed.

By properly constructing a prompt that you save to PROMPT.md you can run a ralph loop as simply as

while :; do cat PROMPT.md | claude --dangerously-skip-permissions -p ; done

Building an app correctly is inherently more subjective than optimizing a neural network, so providing metrics for how much this improves an agent’s capability is difficult. But anecdotally this works surprisingly well. Geoffrey Huntley was able to build an entire programming language, Cursed Lang, from scratch using this method.

Specification Churning

At Modular Cloud, we build our product specifications through a method we call “spec churning”. It is essentially iterative refinement with a human-in-the-loop for disambiguation.

Currently, we use GPT 5.5 Pro providing feedback and Claude Code running Opus 4.7 with max effort for applying feedback.

Unlike self-refine, we run this process for anywhere from 10-100+ iterations and only stop when GPT 5.5 Pro has no more suggestions. Contrary to popular belief, this does eventually happen.

This provides remarkable results and allows us to build comprehensive specs covering edge cases that we would simply not consider ourselves.

Keeping a human in-the-loop helps keep the review inline with our intentions. It allows us to put minimal effort into the initial spec, so that we can outsource the process of explaining our ideas to the AI by simply answering a series of pointed questions, a process known as iterative disambiguation.

We then take the specs we have developed and turn them into a working code using a ralph loop. By running this fully automated process, we are able to build robust software end-to-end by only answering questions about the spec.

We will publish more about this specific workflow at a later time and will share our full stack of tooling that helps us automate it. If want to be notified, when this happens, consider subscribing at the bottom of this post.

Even though we haven’t published our full system yet, there is still something you can try today. Take a spec for the software you are building and feed it into ChatGPT Pro at least 10 times. After each iteration, have an AI agent update your spec with the feedback it provided.

Tokenmaxxing

Churning is just a subset of tokenmaxxing techniques. Tokenmaxxing doesn’t have to run in a loop. It can mean that you are asking ChatGPT lots of questions, getting deeper insights into your work. It can also mean that you are using LLMs to handle repetitive tasks like writing emails, that don’t require iterative refinement.

It can entail methods we didn’t have time to cover in the previous section like genetic algorithms, Best-of-N, LLM-as-a-Judge, and more. There is so much research that is waiting to be applied to consumer-side workflows.

The more you scale your AI usage, the more prolific you will become. Right now there is a big arbitrage opportunity in using AI to perform human work at the fraction of the cost.

Our general rule of thumb is this: don’t waste tokens by feeding LLMs random or useless prompts, but if you can find any productive way to leverage this technology at all, then you probably should—even if it is inefficient and the benefit is minimal.

You still need to be focused. Don’t spend all day using AI to research goblins, gremlins, and other creatures if your job is software engineering. But you should maximally leverage AI for software engineering related tasks.

What about the cost? Go into debt if you have to (joking! kind of…). You probably should spend within your means, but we suggest scaling your usage to cap out your budget first. Only then should you try to optimize your workflow by substituting cheaper models for tasks they are well suited for—and replacing lower value automations with higher value ones.

You will get better at what you practice. If you practice automating work with AI, your capacity to do so will increase.

Personal Kardashev Scale

Renowned astrophysicist Nikolai Kardashev wrote influential papers on how advanced extraterrestrial civilizations might be detected. His central premise was that more technologically advanced civilizations would likely be capable of harnessing greater amounts of energy. As a result, searches for extraterrestrial intelligence could look for powerful artificial emissions, especially communication signals, and other signs of large-scale energy use.

He famously grouped civilizations into three categories, known as the Kardashev Scale:

• A Type I civilization (planetary) is able to access all the energy available on its planet and store it for consumption.

• A Type II civilization (stellar) can directly consume a star‘s energy, most likely through the use of a Dyson sphere.

• A Type III civilization (galactic) is able to capture all the energy emitted by its galaxy, and every object within it, such as every star, black hole, etc.

To some extent, these categories and labels are arbitrary—but the through line is that each level productively uses vastly more energy than the one preceding it.

This idea was refined further by other great minds. Notably, Carl Sagan introduced intermediary stages, estimating that—at the time of his writing—Earth was a Type 0.7 civilization. In other words, Sagan and others found it useful to think of the Kardashev Scale as more of a gradient than a discrete classification.

But Kardashev was actually not the first research that identified a connection between the level of advancement of a civilization to its energy consumption. An earlier example of this was the work of anthropologist Leslie White, whose views could be summarized as:

1. Technology is an attempt to solve the problems of survival.

2. This attempt ultimately means capturing enough energy and diverting it for human needs.

3. Societies that capture more energy and use it more efficiently have an advantage over other societies.

4. Therefore, these different societies are more advanced in an evolutionary sense.

Putting all of this together, we can build a useful pragmatic, working definition for what constitutes an advanced civilization. Although this is not a perfect definition, it is a useful heuristic.

But what is a civilization if not a collection of individuals? And what is an individual if not a collection of cells (or neurons)? From a systems perspective, there is no reason why we should think differently about the two.

Therefore, if you want to be the most advanced and powerful version of yourself, maybe you should consider ascending your own personal Kardashev Scale.

Tokenmaxxing is a way to do this. Tokens are a proxy for the productive use of energy. So, what are you waiting for?

Death by Bundle

The worst thing that can happen is for your product to get rolled up into their subscription bundles. Anthropic and OpenAI both have $20 per month, $100 per month, and $200 per month subscriptions that offer subsidized AI inference pricing. Everyone wants to use these subscriptions because their value cannot be beat. If your product tries to use these subscriptions on behalf of users, not only does this make your business model difficult—but your application can be banned from using the subscription plan by the big labs. Just look at what Anthropic did to OpenClaw.

So your goal, as an AI founder, is to do everything you can to reduce that chance that your product gets rolled into their bundles.

Compete on Price

You can never price under an AI lab. It’s just not possible. You have to buy inference from them—and they charge a markup. Even if they were selling at-cost, they also have raised much more capital than you and can provide bigger subsidies to their users.

Instead of pricing low, you can win by pricing high.

Your product should cost at least $500 per month per seat. Or ideally, $5000 per month per seat. The higher your price, the more defensible your product will be.

But with this high price comes a high responsibility to deliver. You can’t price a simple app at $5000 per month. You need to have relatively low margins on that revenue. With a $5000 per month subscription, you should aim for inference costs to be at least $2500. If your inference costs are $4000, that is even more defensible… but you need to balance defensibility with business viability—and low margins make building a profitable business very difficult.

Your ultimate goal is to build a product that allows people to command the productive of as many tokens as possible.

Doing this works because it wrecks the economics of the big labs’ bundles. You can vibecode an app for less than $200 in tokens. Therefore, a Claude Code subscription can cost $200 and most people won’t use that much—even though some power users utilize more than that. Overall, this makes the subscriptions profitable for the labs.

Let’s say that Claude Code enables a user to vibecode an app for $150 in tokens. You want your product to be able to build a better version of that same app by increasing inference usage to $1500. The inference cost is 10x greater, but the app itself doesn’t need to be 10x better. It can be 2x better, or even just 20% better.

There will be a big market for this. Yes, it will price out budget users—but many serious enterprises will gladly pay more for better results. The fact is that artificial intelligence is a huge arbitrage on human intelligence. Even without the utmost cost efficiency, AI is still much cheaper than humans doing the work. Therefore, scaling AI usage to produce a better result is worth paying more for despite the fact that it has diminishing returns.

Further, the cost and value scale with different curves. Cost increases linearly, you pay a fixed amount more each month. If your plan is priced at $3000, compared to the $200 plan, that is $2800 extra in cost per month. So in January the company pays $2800 more, in February it increases to $5600… and by December the total reaches $33600. This is just a fraction of an engineer’s salary.

But a 20% better result compounds. Productive work builds on past work and technical debt grows exponentially. In January the product is 20% better, in February it is 44% better… and in December it is 892% better.

The big AI labs will certainly add higher price tiers at some point. But there is a limit to what they can do. The demand for better AI tools is there—as was just demonstrated—but subsidizing them in the bundle cannot scale. As the labs push up the limits of the subsidized plans, they in turn cannibalize their inference revenue—pushing more customers to use their subsidized plans rather than their APIs. The problem is that they have only a limited number of GPUs and, if people were using their APIs, they could simply raise the cost per token of inference to meet increased demand. But since the customers are on the subsidized plan, they need to instead lower the limits without lowering the price, thereby reducing the subsidy—and ultimately eliminating their advantage over you.

Turn Their Product Into a Feature

Oh how the tables have turned. Normally, big AI labs are the ones turn entire startups’ products into features on their platforms. But you can actually do the same to them.

Frontier models themselves have competition. Claude Opus/Mythos, GPT Pro, Codex, Gemini, perhaps the next version of Grok all have their respective strengths. There is no single model that dominates in all areas.

This creates an opportunity to build a superior product that delivers superior results by combining frontier models from different labs.

This could mean building a workflow that uses Claude for some takes and Codex for others. It could also mean using an LLM council to improve the quality of responses.

The more that you can improve the capabilities of your product by leaning on multiple models, the bigger your moat will be. Note: remember if this increases your inference costs, that’s actually good, too.

This is something that the big labs simply can’t do. It is very unlikely they will launch a product that relies substantially on a model outside of their own respective ecosystems. And if they do, the usage certainly won’t be significantly subsidized.

The world of multi-model apps is on a fundamentally even playing field.

Do What They Can’t

The above ideas are a strong starting place for a startup looking to build a moat in this hyper-competitive industry. But remember, you are not only competing with the big labs—but also other startups and open source projects. If you want to see our playbook for these other forms of competition, let us know!

The overarching theme is that you want to lean into things that big labs cannot. They cannot rely on other labs’ models and have limits on how much they can scale their subsidies. Therefore, you want to build products at higher price points that massively increase token usage and also rely on multiple models from different labs.

You can also consider doing other things that they can’t do.

One big, but hard, opportunity is around human-based operations. They are not in that business and are unlikely to enter it given their existing scale. Creating tools that provide specialized humans-in-the-loop for certain tasks could be a substantive moat.

Another one would be to cater to vice industries such as memecoins, gambling, and adult services. If you do this, remember that you are at the mercy of their Terms of Service, and probably should opt for open source models.

1. Charge a few major blockchains a large fee to maintain custom block explorers. This would make us more of a software consulting company without a scalable revenue model. In the age of AI, it’s debatable that such a service is even needed. To the extent that it is, there isn’t much money it.

2. Launch a pointless token. We never even considered this.

3. Attempt to position our centralized infrastructure as a lynchpin for an otherwise open ecosystem. Similarly to #2, this is contrary to our values. Short-term this could work by enhancing DX, but long-term this would be a net negative to the industry.

And so, after working to provide a block explorer service to a large variety of blockchains, including EVM, SVM, Cosmos, Move chains and more, we decided to pivot.

The realization we came to through this process is that blockchain developers shouldn’t use blockchain-specific tools, they should be empowered to use industry standard tools.

Instead of using web3 frontend libraries to connect to blockchain node RPCs interacting with smart contracts written in specialized languages compiled to blockchain-specific virtual machines, developer should be able use Next.js or whatever else is the industry standard for developing apps. They, then, don’t need a custom block explorer that shows the app’s state as it is represented in a blockchain’s VM—instead they can store the app’s state in an industry standard tool like PostgreSQL (PG), and visualize it using industry standard PG visualization tools.

And so, Chopin Framework was born—an adapter that converts regular web apps to run on top of blockchains.

We will discuss more about Chopin Framework in other posts. But here our plan is to enumerate Modular Cloud’s mission and values as a company.

A Software 2.0 Company

Although pivoting from crypto to AI is a meme at this point, we would argue that it’s no coincidence that they both have been two of the most hyped categories of tech over the past decade. Both are two wings of the same bird.

“Crypto is Libertarian, AI is Communist” ~ Peter Thiel

Jokes and hot takes aside, there is a very real way in which this is true. Both crypto and AI are a new form of software, called Software 2.0.

What is Software 2.0?

In his legendary November 2017 blog post, Andrej Karpathy coined the term Software 2.0.

Around this time, the landmark paper Attention Is All You Need was published—which later became the basis for the LLM revolution. Crypto was also just finishing up its first supercycle and one year later Mustafa Al-Bassam and Vitalik Buterin would publish their paper on Fraud and Data Availability Proofs, an important contribution to blockchain scaling that would later provide the basis for Modular Cloud’s big bet on crypto.

The idea that Karpathy put forth was ingenious. He first drew a comparison between traditional software (Software 1.0) and Software 2.0. Software 1.0 is written by hand, whereas Software 2.0 is discovered by an automated process that could create much more complex and powerful software than human could ever write.

He visualized it like this.

To give a concrete example of how Software 2.0 works, he cited an example from his work at Tesla.

It would be impossible to code all of the rules for self-driving cars by hand. However, machine learning provides a method to create software that does just that. At Tesla, he led a team that trained a neural network to drive a car. A neural network is, at the end of the day, is just a piece of software. But its implementation is discovered through a process of optimization, which shifts the implementation incrementally during each training cycle to get closer and closer to the desired implementation.

In the space of all possible programs (depicted in the circle above), the Software 2.0 process systematically finds the point in that program space has the developer’s desired behavior. When constructing Software 2.0, you are not contributing to that implementation directly, but rather architecting an automated search process that discovers a working implementation.

To draw a rough analogy, Software 1.0 is like artisanally assembling a product by hand. Software 2.0 is like designing a factory for building a product. Ultimately, a factory will have much great production capacity than what one person can do themselves.

Vibecoding is Software 2.0

We have another write-up planned on this specific topic, so we won’t go too deep on this point. With that said, Karpathy has called vibecoding Software 3.0. Respectfully, we disagree.

Properly vibecoding software requires giving the AI success criteria it can check its work against. This could entail running a ralph loop that continuously checks its work against a spec. Or it could be providing clear acceptance criteria to an agent like Claude Code, which will compile and test its code prior to halting.

As a basic example, let’s say you want a functioning Hello World program written in Rust. If you ask Claude Code to build it, it will write the code and then attempt to compile it. The models are so good that I will almost certainly do it properly in one-shot, but if compilation were to fail it would attempt to fix the errors and then try again.

Building off of his original visualization. Imagine the initial state of the program as being located in the center of the circle, then the first implementation would be a point further from the center. After the failed compilation attempt, it would alter the implementation again and find yet another point in program space.

Web 3.0 is Software 2.0

Back in 2022, Modular Cloud’s founder gave a talk at Modular Summit about this topic.

He argued that blockchains run a similar optimization process to neural networks—using market incentives instead of gradient descent and back propagation. In other words, instead of minimizing loss, nodes in a blockchains network are maximizing profit.

By creating a single node implementation that runs on every participant’s computer, emergent behaviors arise as participants seek to accumulate tokens in the network.

For example, a single Bitcoin node is not highly available or particularly useful. However, the incentives drive miners to contribute hash power based on market dynamics and ultimately create a highly available and robust network for processing payments.

Ethereum, by itself, doesn’t have much functionality. But Ether’s liquidity and Ethereum security incentivize developers to create smart contracts that encode more useful behavior onto the platform.

These examples are subtle, but sometimes the searching process is more overt.

• Automated Market Makers allow users to swap tokens without a central limit order book. Facilitating transfers between anyone who wants to directly swap 2 things is very difficult, in fact that’s why money overtook barter. But AMMs solved this by incentivizing liquidity providers (LPs) to participate in their network. LPs are actively finding ways to allocate funds to these markets in order to make a profit—which ultimately is what makes AMMs work.

• Block building is not a straightforward process. There are large amounts of transactions incoming at any moment, and a blockchain needs to determine which order they should be in. Cloud and Internet providers face the same challenges when trying to prioritize traffic for customers. However, modern block building systems incentivize participants to search for the most efficient and profitable way to order transactions in blocks—which overall improves the efficiency of the network.

• Intents make complex transactions more efficient. Intent networks have “solvers” that search for the best way to route and fulfill a trade.

Blocks will be built via software. Trades will be routed via software too. The question is what software and how did it get built?

Crypto enables programmers to build “designer markets” that optimize for a certain outcomes. This means that they don’t necessarily need to hard-code the best trade routing algorithm into the protocol, instead they can incentivize a network to provide a superior version of this software through an optimization process.

In other words, they aren’t writing the behavior they want by hand. They are building the system from which these behaviors can emerge. And in doing so, they are able to build systems more complex and efficient than they could have implemented themselves.

This viewpoint was one of the precipitating factors for the creation of Modular Cloud, and remains a core thesis to this day. It just so happens that ChatGPT launched after this talk and Modular Cloud’s founding—and now that agentic software development is as big as it is today, we are officially broadening our focus to encompass both crypto and AI.

Crypto x AI

With all of that theory behind us, we also must acknowledge an important fact: crypto and AI work exceptionally well together.

Crypto is fully verifiable and programmatic. It is a fully and natively digital system, ultimately serving as a backend and infrastructure for user facing systems. All behaviors of crypto protocols are defined by specs and implemented in code.

This just so happens to be exactly the domain in which AI excels.

AI is great at turning specs into code. It does its best work when it can verify and run everything end-to-end.

The extent to which AI fails is the extent to which it cannot check its own work. It does less well if human taste comes into the equation, or if meatspace operations need to be executed.

In fact, if there is anything AI was meant to do, it is to build and audit crypto protocols. After all, the specs, code, infrastructure, and usage data is all open source and publicly available.

At Modular Cloud, we are going to continue building Chopin Framework and other decentralized systems using AI. In doing so, we are attempting to push AI further than it has ever gone. We will also be actively sharing these AI development methods with others and building products around our workflows.

Our Values

Our vision is larger, but our values remain unchanged. If we could distill down everything we believe into two principles here is what they would be:

1. We stand against corruption. Bitcoin’s original promise is to disrupt government and corporate corruption on Wall Street. We will forever carry that cypherpunk ethos with us. We are building crypto systems that guarantee us a more fair, transparent, human rights respecting (including privacy), and honest world. AI not only accelerates the development of these system, but also democratizes the flow of information.

2. We stand for global meritocracy. Many people around the world are victims of their circumstances. As a result, so much human potential is wasted. Our goal is to build systems that allow all people to be their best selves and to provide them opportunities according to their true ability. Crypto has a long history of giving financial infrastructure to those who need it most and AI democratizes education and information like nothing ever has in history.

If these values resonate with you, please get in touch.

Months ago (decades in AI-years), Anthropic released an official Ralph plugin. However, many people found that using a traditional bash loop worked better.

While AI enthusiasts are working to invent agent orchestration tools with the best developer experience imaginable, a lot of us just want to quickly spin up custom workflows in the simplest way imaginable.

That’s why we created Loop Extender.

Basic Example

Loop Extender is simple. You give it a bash (or TS/JS) script and it runs it in a loop.

While traditional ralph loops look like this

Run command:

while :; do cat PROMPT.md | claude --dangerously-skip-permissions -p ; done

Loop Extender is a simple wrapper around a bash script that does the same thing.

Create file → .loopx/ralph/index.sh:

cat PROMPT.md | claude --dangerously-skip-permissions -p

Run command:

loopx run ralph

While this basic example seems a bit more complex than the traditional one-liner, this small amount of additional boilerplate allows the developer to create complex AI workflows with ease. Keep reading to find out how.

A Real Example

At Modular Cloud, we have a workflow which we will write about more in-depth at a later time. But for the sake of this example, the idea is that we have SPEC.md that lays out the spec for the project we are working on and TEST-SPEC.md which lays out the plan for the tests. We use GPT 5.4 Pro to review both files together holistically and Claude Code to apply the changes found in the review to the specs. Sometimes questions arise as a result of these reviews and we let Claude Code ask us to manually clarify the answers after we have fed in GPT 5.4 Pro’s feedback. We have found that looping this many times in a row greatly improves our specs and tests.

Although it is not too difficult to do manually, we wanted to automate this as much as possible. Furthermore, we wanted to utilize our ChatGPT Pro subscription, since it would be very expensive to run all of these queries through the OpenAI’s API.

Using Loop Extender, we created this workflow:

This provides us a phenomenal agent experience. By keeping this running, Loop Extender would sends us the prompt that we need to feed into the ChatGPT app. We copy and paste it from Telegram into ChatGPT on our phone—and then copy and paste ChatGPT’s response back into Telegram when it’s done (20-30 minutes later). Then it applies the feedback (which takes 10-15 minutes), chats with us on Telegram to clarify any questions it has, and starts another round of review when it is done.

This allows us to refine our specs while on-the-go with minimal effort.

Maybe this exact workflow is not for you. But Loop Extender can easily adapt to anything else that you want to do instead.

Usage

Loop Extender is open source and MIT licensed.

To get started install the CLI

npm install -g loop-extender

If you want to fully understand how it works, you can read the comprehensive spec here. But honestly, don’t worry about it.

Instead, use the Claude Code plugin to generate your desired workflow. Open Claude Code and run this:

/plugin marketplace add modularcloud/loop-extender
/plugin install loopx@loop-extender

Or, if you prefer another agent harness like Codex, use skills.sh:

npx skills add modularcloud/loop-extender

Then invoke the skill (/loopx in Claude Code) and describe the flow you would like to build for you repo. This will create the scripts for you and install it in the .loopx directory in your project root.

What’s Next

We have been doing complex agent loops for a while and tried to come up with the simplest tool that could automate our work. But some of our initial assumptions were wrong and now that we have been dogfooding Loop Extender internally, we have a lot of changes planned.

What worked:

• The core looping mechanism

• Using skills to vibe orchestrate

• Built-in environment variable management (for example, you can set your Telegram API key without committing it to your repo)

What we need to improve (update on April 17, 2026 - these are both done):

• Workflow invocation UX could be better. Right now you run loopx <script-name> but a better mental model is loopx <workflow-name>

• Remote script installation. You can run loopx install <script-url> to clone a remote script into your .loopx directory. However, workflows typically contain multiple scripts—and we need a mechanism to download all of them in a bundle. Further, we need a setup mechanism that configures scripts to the specifics of your project and machine.

What we overlooked:

• We didn’t put enough thought into optimizing parallelism.

• We didn’t consider the importance of workflow visualization.

• There are a few common primitives that are core to many workflows (such as messaging, temporary files, etc.) that we initially thought should just live inside of scripts but now are considering adding to Loop Extender’s core to prevent users from reinventing the wheel.

What we planned to add after the initial release:

• Sandboxing

• Remote sessions

• Session state

• Improved observability

Why this? Why now?

We aren’t an AI company. We are a blockchain company. But we heavily use AI in our development process.

In the coming weeks, we will release our entire agentic software development process. This has allowed us to correctly one-shot (as in one ralph loop) a re-write of complex software that we previously took months to build.

When documenting our process, we realized that we needed some way for people to install our workflows so they can replicate our method with little-to-no effort. Our coming release will be fully automated with Loop Extender, so that it can be adopted with ease.

If you have a use for Loop Extender today, great! If not, stay tuned and subscribe to our mailing list so that we can notify you when we publish our full agentic development system.

Prologue

After our company went through a substantial pivot, we started to revamp our social media presence. We were once a verified business on X, and wanted to get reverified after allowing that expensive subscription to lapse. But when we re-applied, we were rejected.

Ugh, our main website modular.cloud was just a redirect to our main product’s website, chopin.sh.

So, we decided to quickly spin up a website using Claude Code.

The Design

Right now, we don’t have designers on payroll. So we had to improvise. Normally, when working with designers, we like to find inspiration on platforms like X, Dribbble, etc. And ideally we also find other examples of good website designs in the wild to base our work off of.

We followed the same technique here—and decided to take inspiration from OpenAI’s amazing website.

Simple and clean 👌

Making a website similar to this has three components: (1) colors (2) fonts and (3) layouts. Let’s go through each one.

The Colors

Black and white. It doesn’t take an GPT-5.4 Pro with Extended Thinking to figure that out. The next parts are more difficult.

The Font

Upon inspection, it we could see that OpenAI uses a beautifully crafted proprietary font called OpenAI Sans. This font is available to download from their website, but we don’t have a license to use it, so we needed to find an alternative.

So we asked ChatGPT what the most similar publicly available alternative font to OpenAI Sans would be and it pointed us to ABC Diatype, made by the same design shop that created OpenAI Sans.

The Layout

We happened to be doing a lot of work in Claude Code at the time of building this website. So, we first asked it to build a blog similar to OpenAI’s.

But OpenAI blocked it. Probably because we were using Claude. So, we simply saved the webpage locally and asked ChatGPT to use the source instead of accessing it on the web.

And it worked! Look at what it produced. Note: We subsequently made some additional modifications that are also depicted here, but it basically one-shotted this.

And with that, the frontend was complete. Later in this post, we will share some more of the details for how exactly we configured Claude code to do this well.

The Blog Backend

After creating a nice blog UI, we needed to figure how to write and publish posts to the blog. We considered several options:

1. Statically generate from markdown using Fumadocs. We decided that we didn’t prefer to work that way. That model works better for living documents, such as product documentation, not time series posts that are basically final once published.

2. Use a headless blog like Ghost. We decided not to do that because we didn’t want to manage a separate Ghost deployment. It’s possible that we could have used free Ghost hosting, but we didn’t look into that. We certainly didn’t want to pay for premium Ghost hosting.

3. Vibecode a custom blog backend. Although this is easy, it’s still too much work.

So instead, we decided to use Substack as a blog backend. This is a social platform we already wanted to use, as we are revamping our social media presence. Publishing on Substack gets us additional distribution through the Substack app, so it makes perfect sense to mirror it on our main website’s blog.

Building on Substack

Unfortunately, Substack is not meant to be used this way. Their API does not support retrieving all posts.

Don’t ask us what Substack has to do with LinkedIn… but apparently this is the only thing you can do with their API.

However, they do have an RSS feed, which includes the HTML content of all the posts on a given Substack.

So, we were able to basically one-shot a Substack backend with the following prompt

I want to use substack as the backend for the blog. At build time, fetch the RSS feed from https://modularcloud.substack.com/feed and populate posts with the content from this. To be clear, I want the nextjs site to be statically generated from this content source

There were a few minor issues with how the post was rendered that were easily resolved.

It’s Almost Perfect…

But not quite. Substack also doesn’t support programmatic subscriptions, so we are maintaining a separate mailing list using Resend for those that subscribe on modular.cloud. We could link people to Substack to subscribe, but thought it would be a better UX for them to be able to subscribe without leaving the page.

What’s Next

From here, we still have a lot of improvements to make. We will trigger rebuilds whenever a Substack post is published (probably by listening for a Substack email. We will also find a way to automatically mirror the Substack emails to the Resend list. Lastly, we will likely modify the design to be less similar to OpenAI’s blog, which provided great inspiration for a starting place that got up and running quickly.

The Takeaway

In summary, AI excels at turning comprehensive specs into working code. AI also is great at assisting in generating specs. But this only works well for backend work. Frontend is a different story.

Working with AI agents on frontend design is made much easier by providing concrete inspiration—ideally from existing websites and apps that have inspectable implementations. This allows the agent to get concrete design inspiration instead of inferring it from an image.

We also think that others might consider using Substack as a backend for their blog, as it is a powerful and growing platform with a great track record.

Context Engineering Tips

This was a relatively easy task. Usually, we put a lot of effort into creating specs and ralph loops, but in this case it was not needed. It’s just a static site with minimal complexity.

We did, however, use the following skills, MCP servers, and plugins.

Skills

• next-best-practices

• vercel-react-best-practices

• vercel-composition-patterns

• web-design-guidelines

• resend (only needed if working with Resend)

• shadcn (probably wasn’t needed for this tbh)

Also, we used Figma skills (see below).

MCP

Resend MCP and Figma MCP (see below).

Plugins

We used the Figma Claude Code plugin to automatically enable the Figma skills and MCP. This was only used to fetch our logo from Figma.