The strongest objection to self-hosting is that it is theatre: you still sit on CUDA, on weights handed down by an oligopoly, on a rented edge. It is correct, and it is not the end of the argument. Essay two of a series on sovereignty.

I Moved the Dependency, I Didn't Remove It

The strongest objection to everything this site argues is not that self-hosting is hard, or expensive, or slower than the frontier. It is that self-hosting is a costume. You did not escape dependence by moving your model onto a box in your office. You still run on NVIDIA’s CUDA, a stack one company controls. Your open weights were handed down by a small oligopoly of labs whose training data you cannot audit and whose next release you cannot compel. Your site still sits on a rented server in someone else’s datacenter. An analyst piece this year put it cleanly when it called most sovereign-AI strategy “sovereignty as relabeled dependency”. The shape of your dependency graph changed. The fact of it did not.

I think that objection is correct. I also think it is not the end of the argument, and the work of this essay is the narrow space between those two sentences.

The dependencies I did not remove

Let me name them, because refusing to name them is how this kind of essay usually cheats.

I run on CUDA. If NVIDIA decides my Blackwell chip should behave differently, or prices the next one out of reach, I have no recourse except to rebuild on a worse substrate. That is a structural dependency and I cannot self-host my way out of it. The weights I serve, an open Qwen checkpoint, came from a lab I do not control, trained on data I cannot inspect, under a license that is permissive today and is not guaranteed to stay that way. The live question “is Qwen going closed?” is exactly the kind of tap that can be turned off above my head. And the edge that serves this very page is a rented VPS, which the host could revoke on a whim, the same way a cloud tunnel I used to depend on could have.

When I ran the six-dimension audit I use to test the word sovereign, the honest result was not 6 out of 6 owned. It was 6 out of 6 named, with several of those marked “rented, and I know it.” Custody of keys: owned. Identity: owned. Data path for inference: owned. Control plane, supply chain, and parts of the revenue path: rented, and written down as rented. Anyone who tells you their stack is fully sovereign is either running on hardware they fabricated themselves, which I doubt, or has not finished the audit.

So the costume objection lands. Now watch what it does not touch.

Franklin’s distinction

Ursula Franklin, in The Real World of Technology, drew a line that is more useful here than the word independence. She split technologies into the holistic and the prescriptive. A holistic technology is one where the person doing the work controls the whole process and can revise it as they go; the craft and the judgment stay with the worker. A prescriptive technology breaks the work into externally specified steps that must be followed exactly, and what it produces, beyond the product, is a culture of compliance: people trained to do as they are told and to accept that the process is not theirs to question.

A rented API is a prescriptive technology in the purest form. You send input, you receive output, and every step in between, the weights, the sampling, the refusals, the logging, the silent updates, is specified by someone else and is not yours to revise. You are not ignorant because you are stupid. You are ignorant by design, because the design is a sealed box and your role is compliance with whatever comes back.

A model you run end to end is a holistic technology on the axes that matter. You can read the weights, change the sampler, rewrite the system prompt, see exactly where the data goes, and refuse the update that the vendor would otherwise have pushed while you slept. Franklin’s word for what that buys is not independence. It is reciprocity: a relationship in which you can talk back, in which the tool answers to you rather than only the other way around. You have not removed the dependency. You have changed it from one that issues commands into one that holds a conversation.

The journeyman carried his tools

This is not a new fight. In the medieval craft and guild era, a journeyman owned the tools of his trade and carried them from one workshop to the next. Owning the tools is what made his skill portable. He still depended on a master for a bench and a wage, but the dependence was bounded, because the thing that produced the value stayed in his own bag. He could walk, and the walking is what kept any single master honest.

The factory system of the industrial revolution closed that bag. The worker’s owned tools were replaced by the owner’s machines, fixed to the owner’s floor, and the worker’s dependence did not vanish. It relocated. It moved from a craft and a set of tools he controlled to a wage and a machine he did not, and it became harder to see, because a regular wage looks like security right up until the floor is sold. The dependence was always there. Industrialization just moved it somewhere the worker could no longer inspect or carry.

That is “I moved the dependency, I didn’t remove it” three centuries early, and it tells you which question was always the real one. Not whether you depend on something, because everyone always has. The question is whether the dependency sits in a bag you carry or on a floor someone else owns. A rented API is the owner’s machine: it does the work, but you cannot pick it up and leave. The weights on my disk are the journeyman’s tools. They are heavier to carry than I would like, and I carry them anyway, because a dependency you can pack into a bag is the only kind you can ever walk away from.

Why a relocated dependency is still a real gain

Here is the move the costume objection skips. It treats all dependencies as equivalent, so that relocating one is just rearranging the furniture in your cell. But dependencies are not equivalent, and the difference is the entire game.

There is a dependency you can see, inspect, fork, and plan around, and there is a dependency you cannot. CUDA is structural and I am stuck with it, but the Qwen weights on my disk are not a tap that can be retroactively shut: if the lab goes closed tomorrow, the checkpoint I already hold keeps running, and the gap between open and closed has narrowed enough that a replacement is usually a quarter away, not a decade. By Stanford’s AI Index, the quality gap between the best closed and best open models on one public benchmark fell from about 8.0% to roughly 1.7% across a single year, 2024 into 2025. That convergence is the reason a forkable weight is a real hedge and not a slogan: the substitute is close, and it is getting closer. I have switched the model under my stack before, kept the same served name and port, and the rest of the system did not notice. That is what a forkable dependency buys: not freedom from the dependency, but the ability to absorb its betrayal.

Compare that to the rented API, where the dependency is structural and invisible and unforkable all at once. When the price corrects, you find out by getting a bill. When the model changes, you find out by getting different answers. When the terms change, you find out by being cut off. The relocated dependency is worse on convenience and better on exactly one thing, which happens to be the thing this whole site is about: you can keep operating after the other party changes its mind, because you can see the change coming and you have somewhere to stand.

The honest caveat is that this is a spectrum, not a victory. I am less captured than a pure API renter and more captured than a fantasy of total self-sufficiency that does not exist for anyone. The claim is comparative, and comparative is the only honest register here.

Naming is the first sovereign act

If the dependencies cannot all be removed, then the discipline that matters is naming them, and naming turns out to be the load-bearing act.

The reason is mechanical, not poetic. An unnamed dependency is the one that takes you down, because it is the one you did not build a fallback for, did not monitor, did not price into the plan. The dependency you have written down as “rented, revocable, here is what I do when it goes” is already half-defused. This is why my audit measures named versus unnamed rather than owned versus rented. A stack that is 4 out of 6 owned and fully named is more sovereign in practice than one that is 6 out of 6 owned in the owner’s imagination and never audited, because the second one is carrying unnamed dependencies it will discover at the worst possible time. The comparison table at the top of this essay is that single distinction, unrolled.

The marketing version of sovereignty sells you a destination: own everything, depend on no one. It does not exist, and chasing it makes you dishonest, because at some point you have to start pretending the rented parts are not rented. The engineering version sells you a practice: name every dependency, own the ones worth owning, and for the rest, know exactly what you do when each one changes its mind. Simon Willison’s writeup of the same DGX Spark this blog runs on is refreshing precisely because he keeps cataloguing what he has not solved yet, the CUDA versions he has not untangled, the wheels he could not build, ending on the line that it is too early for him to give a confident recommendation. That is the practice, and it is the opposite of selling a finished fortress. The admission is the sovereignty.

What I am actually claiming

I have not escaped dependence. Nobody has, and an essay that told you otherwise would be the exact authority theatre this site exists to refuse. CUDA is under me, the weights came from above me, the edge is rented beside me, and the consulting invoices clear through a payment rail that knows my legal name.

What I am claiming is that I moved the dependencies I could move from the dark into the light, from prescriptive to holistic, from unnamed to named, and that this is a smaller and more defensible thing than the word sovereign usually promises. It is also the only version of the word that survives contact with the strongest objection to it. You cannot own your way out of dependence. You can only choose whether your dependencies live in a bag you carry or on a floor you rent, and that single choice is the whole of what sovereignty ever meant.

This is essay two of a series. The first was about the radical monopoly that the rented model has become. The series spine, and why each essay concedes its strongest objection before it answers it, is on the philosophy page; the structured, complete version is the forthcoming book, for which these essays are the public workshop. The next one is about the day my own machine sat idle and I argued that the waste was the point.

Comparison

The only distinction that survives the objection

Not owned versus rented. Named versus unnamed.

An unnamed dependency
A named dependency
When it changes its terms
You find out by breaking.
You saw it coming and had a plan.
Can you inspect it
You never looked.
You read it, you can fork or swap it.
Your posture
Captured, and calling it convenience.
Exposed, and calling it by its name.
Where it breaks first
Here. Always here.
Somewhere you are already watching.

Was this worth it? Zap the article.

Value for value, no signup. Sats go straight to the writer.