In a recent Slate interview, science fiction author and journalist Cory Doctorow offers an optimistic view of a post-AI world. Not post-AI in the sense that we stop using AI technologies, but post-AI in the sense that we are no longer paying today’s prices to use ChatGPT, Claude, or Gemini.
You know, when AI crashes, we’ll have GPUs at ten cents on the dollar. We’ll have an army of skilled workers who know how to make those GPUs do really interesting and cool things. We’ll have these open-source models that have barely been touched and optimized. [...] I think we’ll have open-source models. I think they’ll do really interesting things. I think we’ll have a lot of cheap hardware, and I think we’ll have a lot of people who know how to use it.
Doctorow calls this the productive residue of the bubble. I wanna know more about that productive residue. I want to jump ahead to the sustainable part. But, augh, I don’t want to erase the crash itself. The pensions, jobs, public services, and household savings exposed to the bubble belong mostly to people who did not create it. Doctorow suggests that if the crash is followed by austerity, as recent financial crises have been, its costs will be imposed downward while many of the people who inflated the bubble leave with their wealth intact.
So the question isn’t how to make the crash arrive faster. It is how to start building the post-bubble settlement before it arrives. It’s not X, it’s Y, of course.
One way to read the current stage of LLM development is as unnecessary production. A few-days-old preprint applies the European Union’s waste hierarchy to language models: prevention, reuse, recycling, recovery, and disposal. A model can become waste when enormous resources go into training it, it is used briefly, and then it is displaced by another model trained from scratch. Fine-tuning, model merging, and other adaptations can extend a model’s useful life. And sometimes the least wasteful choice is not to use an LLM at all.
After the speculative demand for constant replacement dries up, models don’t need to vanish. We can keep using, adapting, combining, and eventually retiring them. That cultural and technical capacity to maintain the parts of this system that we need can live in public, in individuals and organizations that don’t think of themselves as representing an AI industry.
Interactive planning has a technique called Idealized Design. You plan for what should come next by assuming that the current system failed last night. “Gentlemen, the telephone system of the United States was destroyed last night” is the opening premise in a fun story about Bell Labs redesigning the telephone system. Continuing the design exercise, two constraints:
First, technological feasibility. This means we cannot use any but currently available knowledge. No science fiction. We can’t replace the phone with mental telepathy. The second constraint, the system we design must be operationally viable. [...] The system must be able to function and survive in the current environment. For example, it will have to obey current laws and regulations.
Let’s run with it. Gentlepersons, the centralized generative AI service system was destroyed last night. ChatGPT, Claude, Gemini, and their commercial API endpoints are gone. Neoclouds, wrapper apps, and a good slice of the hardware design and manufacturing industry was destroyed too, why not? The rest of the environment remains: snapshots of open-weight models, already manufactured hardware, public research, open-source software, and people who know how to work with all of it. This is cleaner than Doctorow’s crash, but it’s a design exercise for asking what we could build from the residue without quietly assuming that the existing service providers will return.
If you want LLM services, you might run them for yourself or your organization on what is now cheap hardware. Small-ish models are already pretty good. We could get several years of useful work from models whose knowledge stops in 2026, especially when skill documents and retrieval tools can supply current context and people can continue adapting the models at the level of parameters or architectural adapters. Or we might pool hardware through universities, libraries, cooperatives, or an actually-open successor to today’s inference marketplaces. Access would probably be slower and less uniform. It would also be less dependent on a few firms subsidizing usage while trying to capture a market.
You would still need a harness: a place to keep conversations and files, connect models to other systems, and decide what context they can act on. We already have a healthy range of free, open-source harnesses. Even if the commercial support behind like tools like Open WebUI, OpenCode, and OpenChamber is lost in the crash, their snapshotted sources can be inspected, forked, and maintained or even cloned and rebooted without the permission their current industry backers.
Now onto human knowledge and cultural practice. How do millions of people (is it more than a billion now? whatever) move from services that hides nearly every technical decision to systems they can understand and control? We should probably start to build the offramps now, document them, and give people routine opportunities to practice using them.
I recently added a skill to the Basic agent on BayLeaf Chat, and I called it offramp. This one gives the agent a few key tips to help someone stop using BayLeaf Chat. It explicitly says that using BayLeaf Chat to get help leaving BayLeaf Chat is legitimate.
The skill is configured to trigger under two conditions. First, if the user is explicitly asking how to grow beyond BayLeaf Chat, sure, help them grow. Second, if the user is discussing a particularly sensitive subject for which they might benefit from enhanced privacy protections, they might need this advice too. Are you asking for financial advice, personal health advice, or career advice laced with talk of self-harm? I think LLMs can be useful in some of those scenarios, but not here. Not on the record, not in a database some professor can browse when they are curious. Let’s take this conversation onto your personal device so that you own the terms and scope of data retention.
The first level of offramp is to move the harness onto the user’s own device. The skill currently suggests OpenChamber, a desktop interface for the OpenCode agent harness, connected to the BayLeaf API for inference. Conversation history then stays on the device and is no longer available to the BayLeaf Chat administrator (that’s me). It’s a meaningful step, but it still leaves you partially dependent on BayLeaf’s inference service.
Offramps, the blog post title is plural for a reason. A user can take further offramps from BayLeaf inference to an individual zero-data-retention service, maybe ordinary pay-per-month subscription like OpenCode Go or high-security pay-per-token inference service like Tinfoil. Or maybe they could dabble in disconnecting from cloud services altogether by model running on hardware they control. It’ll cost them some in time and/or money, but the end of the ramp leads to a productive life even in a world where BayLeaf is destroyed alongside ChatGPT in our idealized design exercise.
The offramp skill is part of BayLeaf’s counterfoil research strategy. In Illich’s sense, counterfoil research is inquiry conducted against the grain of institutional self-interest: research that questions the necessity of an institution’s expansion rather than continually finding reasons for it to grow. For BayLeaf, that means operating a useful campus service that helps us develop to a level where we don’t need BayLeaf any more.
In the moment when someone turning to a robot buddy is stressed, exposed, or frightened, that is when I want them to see the offramp. Withholding it at precisely that moment is a kind of invitation to dependence. I don’t want people to practice comfortable dependence on something shaped almost like ChatGPT. I want them to become comfortable carrying their own practices, context, and judgment from one system to another, including into whatever we can build from the residue.

