Where Lattice Cloud fits
If you're evaluating Lattice Cloud, you've probably seen LM Studio's LM Link and Darkbloom. They overlap. They are not the same thing. Picking the right one saves you a migration later.
The short version
| Pick | When |
|---|---|
| LM Link | You want remote access to your own LM Studio instances from tools already pointed at localhost:1234. One person, one fleet. |
| Darkbloom | You want a private OpenAI-compatible endpoint over a pool of GPUs you or your team operate. Centralized model catalog, centralized billing. |
| Lattice Cloud | You're building an app and need a single API that covers your users' own compute, other users' compute, and Lovelace-run compute — with auth, billing, and a catalog that isn't tied to one runtime. |
LM Link — the closest analogue
LM Link ships with LM Studio. It pairs your own LM Studio instances
into a mesh over Tailscale's WireGuard primitives; tools already
pointed at localhost:1234 transparently reach remote instances. It's
well-built and solves a specific problem well: remote access to your
own fleet, for tools you already use.
The things LM Link is explicitly good at, Lattice Cloud does not try to compete on:
- Mesh VPN setup with no port forwarding, no DynDNS. Tailscale handles it. We don't out-engineer Tailscale on transport.
- Zero-change integration with every existing local-LLM tool via the
localhost:1234drop-in.
Where it stops:
- Runtime: LM Studio on both ends. If you use Ollama, vLLM, MLX outside LM Studio, llama.cpp directly, or cloud-bridged models — LM Link doesn't see them.
- Scale: Free tier is 2 users × 5 devices. Paid tier is "coming soon" and has been for a while. Enterprise is contact-form.
- Coordination: No routing, no tier, no failover, no marketplace. You pick the device manually.
- App integration: There's no SDK for third-party apps to consume.
From an app's perspective, it looks like
localhost:1234— so it sees one user's fleet, not a distributed compute platform. - Attribution: Permission keys scope a single host. There's no end-user identity, no per-user billing, no OAuth for third-party apps.
If the product you're building is "LM Studio power-user tools," LM Link is already perfect. If the product you're building is "an AI-enhanced app that should Just Work on my user's hardware when they have it and on rented hardware when they don't," you need the layer above LM Link.
Darkbloom — private OpenAI gateway
Darkbloom puts an OpenAI-compatible gateway in front of your own GPU pool. It centralizes the model catalog, centralizes billing, and gives you one key for teams to share. Good product for a team that has already bought the hardware and wants a gateway without writing one.
Where Lattice Cloud diverges:
- Whose hardware: Darkbloom assumes you own or lease the hardware and you're gating who can use it. Lattice Cloud assumes the interesting compute is on your users' devices — the Mac Studio sitting idle in their other room — and the marketplace fills the gap. Workspace-pool requests don't cross our infrastructure at all once the token is minted.
- Identity: Darkbloom is an internal gateway. Lattice Cloud is a public, OAuth-gated platform with "Sign in with Lovelace" so third- party apps can use their users' compute pools without the developer paying for inference.
- Coordination surface: Darkbloom routes to GPUs you provisioned. Lattice Cloud routes to a heterogeneous mesh with provider reputation tiers, mid-stream failover across providers, and capability-declared devices.
What Lattice Cloud is, stated plainly
Lattice Cloud is the placement and coordination layer for AI compute. An app calls one endpoint. The gateway figures out which device serves it — your user's Mac Studio, a peer device in a paid marketplace, or Lovelace-run hardware if neither is available — authenticates with existing Lovelace identity primitives, meters the call, and gets out of the way. The inference happens on hardware we do not own; we own the layer that decides where it goes and who pays for it.
It's a strict subset of the Agent Cloud surface: where Agent Cloud is the full agentic environment (tools, sessions, memory), Lattice Cloud is the compute primitive beneath it. Agent Cloud will be built on top of it.
The load-bearing differences
| Dimension | LM Link | Darkbloom | Lattice Cloud |
|---|---|---|---|
| Runtime | LM Studio | Self-hosted GPU pool | Ollama · MLX · llama.cpp · vLLM · cloud bridges |
| User cap | 2 users free | Team-sized | No cap |
| Third-party app SDK | None | None | TypeScript · Swift · Python |
| End-user identity | None | Internal | Sign in with Lovelace (OAuth 2.1) |
| Cross-user sharing | None | None | Marketplace, reputation-gated |
| Realtime sessions | No | No | WebSocket sessions, task-class-pluralist |
| Billing modes | One (key) | One (internal) | Developer-pays · end-user-pays |
| Catalog source | Static | Self-maintained | Database-backed, upstream-polled, cloud-bridged |
If you want the one-sentence version
LM Link gives you remote access to one runtime on one user's fleet. Darkbloom puts an OpenAI gateway in front of your own GPUs. Lattice Cloud gives you a coordination layer over many runtimes, many fleets, and many users — with the auth, billing, and observability primitives a real product needs.
Neither of these things is a criticism of LM Link or Darkbloom. If your problem is the problem they solve, use them. The differentiator here lives above the transport — not at it.