The loopback bridge

Editor's note: as of publication, the first Store release of the Abliteration desktop app is in Microsoft's review queue. The bridge described below - the local HTTP endpoint the app opens, and the plate at the top of /models that reads it - goes live within days of this piece. We're publishing now because the argument for the pattern stands on its own.

If you've spent any time on Hugging Face or a model catalog, you've had this moment. A model with a beautiful description, promising numbers, exactly the kind of behaviour you were after. You download six gigabytes over Wi-Fi and open it. Loading. Loading. A swap file the size of a hard drive. Then either a crash or a token-per-minute crawl. You close it, delete the file, and go looking for something smaller.

The problem isn't the model. The problem is that no catalog can tell you what will fit on your machine until you try it. A browser has no idea what you're running on. navigator.deviceMemory reports a value bucketed to powers of two and capped at 8 GB, so a Chromebook and a workstation with 128 GB of RAM look identical to any JavaScript that asks. And even if the browser had the number, it would tell you total memory, not how much is free right now, which is the number that actually decides whether the model loads.

We wanted the abliteration.org catalog to be honest about this. If a model won't run on your machine today, we should say so. If a model will run but slowly, we should say that too. If we can't tell, we should be up front that we can't tell.

That means the site needs to see your hardware. Not once, not over an account you have to create, but every time you look at a model card. From inside the browser tab. Without asking you for anything.

The bridge

The trick we settled on is this. The Abliteration desktop app runs a tiny read-only HTTP server on 127.0.0.1:47821 while it's open. Two endpoints. GET /health returns a hundred bytes of "yes, I'm here". GET /rig returns a JSON description of your CPU, your RAM, your GPU, and how much of the RAM is free right now.

When you open the catalog in your browser, a script runs. It fires a request at that port. If nothing answers within about a second and a half, the site shrugs, falls back to whatever coarse hints the browser can offer, and paints a yellow plate on the page that says "rough estimate". If something does answer, the plate flips to green and reads the exact numbers back at you. From there, every model card recolors: green means it'll run now, yellow means it's a tight fit, orange means it'll swap heavily, red means it won't load.

The bridge is bound to the loopback address, which means nothing outside your machine can reach it. Your neighbour on the coffee-shop Wi-Fi can't probe it. Your ISP can't probe it. We can't probe it. The only thing that can reach the endpoint is a browser running on the same machine, and even then only from the specific site domain we allow in the Access-Control-Allow-Origin header. There are no tokens, no passwords, no cookies. The security model is one line: loopback plus an origin whitelist.

The endpoints return hardware description and nothing else. Not your chat history, not the models on your disk, not filenames, not usernames. They exist to answer a single question - "will this thing run here?" - and nothing about them lets the site ask anything else. For the complete endpoint spec, port fallback and CORS policy, see the Local HTTP bridge reference in the app docs.

Not a new pattern

This isn't invention on our part. Spotify's open.spotify.com quietly checks whether your desktop client is running so it can hand off playback; Discord's web client does the same to route you into an installed desktop version when one is present; 1Password's browser extension speaks to the local app over the same channel to unlock without a round-trip through their servers. The pattern is old enough that modern browsers cut it special slack: an HTTPS page is allowed to talk to a plain HTTP loopback endpoint without the mixed-content warnings that would otherwise fire on any other host.

What we're doing is the same shape applied to a problem the local-LLM ecosystem hasn't solved. Local desktop apps and web catalogs have coexisted for years by ignoring each other. The catalog can't see the app. The app can't see the catalog. The user ends up alt-tabbing between the two, copying repository paths by hand, guessing at whether the file will load. That doesn't have to be the shape of things.

Why not Ollama, LM Studio, or the extension route

Alternatives exist. We looked at them.

Ollama runs entirely on your machine but ignores the web. Its "catalog" is a list of ollama pull commands published on a static page, not a place a stranger can browse. There's no way for a Google visitor to see what's available filtered by their rig, because there's no reciprocity - Ollama is a CLI wrapped in a background service, and its social interface is a shell prompt.

LM Studio put its catalog inside the app, so the app knows your rig, but only for its own listings. Nobody outside LM Studio sees what fits your machine. If someone links you to a model on the LM Studio hub, you'd have to install LM Studio first to know whether the model will load - which is the loop we're trying to break.

A browser extension would put us in an extension-store review queue every release, ask visitors for a permission that reads scarier than what it does, and centralise a moving target on Google's and Mozilla's review policies. Detection from user-agent and IP geolocation is 2010 thinking - it doesn't work. Running the model in the browser via WebGPU to feel it out means you'd have to download the model to check whether the model will download, which is exactly the problem.

A loopback HTTP endpoint has none of those problems. It's a technology every developer already understands, uses tooling every operating system already ships with, needs no elevated permission, and can be curl'd from a shell if you want to see what the site sees. Run curl http://127.0.0.1:47821/rig on your own machine and you get the exact same JSON we do. Nothing hidden.

What you actually see

The visitor experience follows the same two-state pattern everywhere on the site.

If you don't have Abliteration installed, or you have it installed but not running, you get the yellow plate. The plate tells you it's a guess, gives you a broad "likely fits models up to about 7 GB" line, and offers you the app in a single button. Every model card shows a compatibility chip based on the browser guess, which is coarse but not useless.

If Abliteration is running, the plate flips to green. Your CPU model is on the plate. Your RAM totals are on the plate. Your free RAM is on the plate, refreshing as things move on your machine. The compatibility chips on every card become real: they match what the app's fit-check dialog would tell you if you tried to add that model in-app. The catalog's sidebar grows a Compatibility filter with four rows - runs now, tight fit, slow, won't fit - and clicking one queries the whole 17,000-model catalog for what your rig can actually handle, in the same popular-first order you were already reading.

Close the app halfway through browsing? The plate goes yellow again within 30 seconds. Open it back up? Green inside another half-minute, without reloading the page. The bridge is the app; the app is the bridge. There's no separate service to manage, nothing to configure, nothing that runs when you don't want it to.

Where the pattern earns itself

Local desktop apps and web catalogs have coexisted for years by ignoring each other. A tiny local service that the site can politely ask a single question, over a well-known port, with a security model that fits on one line, closes a real gap without asking the visitor to trust anything they can't verify. The whole visible payoff is a green plate at the top of the page and a catalog that tells you the truth. The whole invisible payoff is that the visitor gets to walk into a catalog of 17,000 abliterated models and see, in one glance, which quarter of that catalog is available to them today - not which quarter would be, if they had different hardware, or would be, if their disk had different free space, but what actually loads on their machine right now.

If you're building a site that could benefit from knowing what's on the visitor's machine, this pattern is worth a look. And if you're already on abliteration.org, this pattern is why every colour on every card means what it says.

Where this leaves us

The bridge ships with the desktop app's first Store release; the catalog side of the plumbing is live and running against the browser-heuristic fallback until then. When the Store approval lands, you'll notice - the plate at the top of /models will flip from yellow to green the first time you open the catalog in a tab with the app running. Nothing about the catalog changes; every card is where it was. The verdicts on the cards get truthful.

For the docs, the formal reference lives at Local HTTP bridge - how the site sees your rig exactly. If you're curious about the endpoint schema, the port fallback, the CORS whitelist, or the refresh cadence, that page is the machine-readable version of this essay.

If you have questions we should be answering - a case the essay doesn't cover, a concern about the pattern we should address, a comparable pattern you've seen elsewhere - write us.