LastBrowser Proposes VolksAI: A Shared Pool Concept for Local Models

The LastBrowser team recently floated an idea called VolksAI: letting users with idle compute share their local models so that users with insufficient hardware can call them. This is not a shipped feature — not even code has been written yet. In the author's words, it's just a "rough sketch" meant to test how the community reacts to this direction.

Why this idea exists

LastBrowser is a browser for Windows and Linux (the Linux version is currently in preview), with built-in vertical tabs, Spaces, a terminal, and a local model runner called Sidekick. Sidekick can run local models or connect to remote services using the user's own API key.

There's a mismatch here: many Sidekick users have capable machines whose local models sit idle most of the day, while another group of users simply doesn't have hardware powerful enough to run a good model. There's an obvious supply-demand gap between these two groups, with no channel to bridge it. What VolksAI intends to do is build a shared pool that matches idle compute with compute demand.

The starting point is simple — not to build a new product, but first to ask a question: is this the right shape?

When we say "local models" here, we usually mean open-weight models with parameter counts in the single-digit billions, runnable on a consumer-grade GPU or a reasonably modern CPU. Ollama, llama.cpp, and LM Studio are three common local inference runtimes: llama.cpp implements quantized inference in C/C++, running GGUF-format weights on CPU and GPU; Ollama builds model pulling and a persistent service on top of it; LM Studio offers a GUI to download and load models and exposes a local port compatible with the OpenAI protocol. What they share is that model weights live on the user's own disk and inference requests go through a local HTTP endpoint — which makes them naturally suited to being reused by a "join the pool" model, as long as a proxy layer forwards external requests to the corresponding local endpoint.

How the mechanism roughly works

In settings, a user can pick a local model from Ollama, llama.cpp, or LM Studio and click "join the pool." A broker service handles pairing pending requests with idle hosts, and the actual computation happens on the host's own machine. This broker could run on Cloudflare-like infrastructure.

The broker is deliberately designed to be "dumb." It doesn't store prompts and can't read prompt content; it only gets enough information to route: that a request at some trust level is waiting, and which host is idle. It can see metadata — trust level, model name, approximate length — but not a copy of the prompt. There are three roles in the system:

• User: issues the request and selects the highest trust level allowed for that request
• Host: provides the model and compute time
• Broker: connects the two ends but doesn't touch the content

One point the author states bluntly, because it's easy to gloss over: the payload is encrypted in transit between user and host, and the broker only forwards it; but the host can see the prompt, because the model has to read it to answer. Encryption protects the transport link, not the GPU. Any claim that describes such a pool as "fully private" is dishonest.

The four-level trust model

Not every request requires the same degree of exposure. The concept splits trust into four tiers:

1. Your own devices — limited to machines under the same account
2. Friends and teams — joined via invitation, no public entry point
3. Verified hosts — LastBrowser has checked the host (how exactly, the article explicitly says, "is a problem for later, not defined here")
4. Public pool — any host that opts into this level

There's also a separate private organization pool: schools, universities, and companies can run a closed pool on their own machines, accessed via their own API address or endpoint, with prompts never leaving the intranet. Admins control who can join and can choose to connect this pool to the broader LastBrowser pool or keep it fully closed. It's not a fifth public tier, but an organization-owned pool that stands apart from the four levels.

Requests can only land on levels the user has already allowed. Sensitive content — credentials, private documents, Space context marked confidential — never goes through level four. Before sending, the interface warns in plain language: the host can see the prompt, the broker cannot. This sentence is displayed, not buried in a policy page.

Beyond trust levels, the distinction between "end-to-end encryption" and "end-to-end privacy" is key to understanding the whole design. So-called transport encryption usually means TLS: data is ciphertext on the network link, and intermediary nodes can't peek in transit; but once a request reaches the host that actually runs inference, it must be decrypted into plaintext for the model to read it. So what the system can promise is "the broker can't see the prompt," not "no one can see the prompt." Keeping it secret from the host too would require trusted execution environments (such as TEE-based confidential computing) or fully homomorphic encryption — neither of which is practical on consumer GPUs, which is also why the author refuses to call the scheme fully private.

Credits and contribution balance

Sharing compute can earn credits. Considering not everyone has a GPU, users without a graphics card can contribute CPU work instead: running tests, benchmarks, or embeddings. Another option is providing free quota plus a waiting queue.

Either way, credits are just internal accounting units within LastBrowser — not cash, with no right to withdraw. The author is clear about this to avoid user misunderstanding.

Abuse, quality, and responsibility

A pool where anyone can offer a model will naturally attract people offering cheap or even shell models. The concept includes spot-check mechanisms: is this host really serving the model it claims, or just returning blank or irrelevant answers? Rate limits would constrain each host's request volume and shared task volume. Hosts that repeatedly fail spot checks get downgraded until someone takes a look. Specific thresholds are likewise left undefined.

On responsibility, the author's honest position is: the host is responsible for the content it receives on its machine and the content it produces. LastBrowser is only responsible for matching and level rules, not for the model's computation. Hosts in the public pool are not LastBrowser employees. Specific contract wording falls under later legal review.

How it differs from existing approaches

Because similar things already exist, the author takes care to distinguish:

• AI Horde distributes image and text tasks to volunteers, settles contributions through credit accounts, and workers can see task content.
• Petals splits a large model into multiple layers and spreads them across multiple volunteer machines.
• Exo is mainly about packaging your own devices into a local cluster.
• NVIDIA PAIR (Personal AI Router) connects Ollama, llama.cpp, and LM Studio across explicitly paired devices within a network; one request runs entirely on one device, pairing is bidirectional, and inter-device traffic is encrypted. A public pool and credit system are not its model.

LastBrowser's pool wants to borrow from PAIR the idea of "one local model, one complete request, one selected host," and borrow from Horde voluntary participation and credit accounts, but won't split one model across multiple strangers like Petals does.

If it's ever actually built, this pool could serve as a provider behind Sidekick's automatic router, but only when the request's trust level allows the router to choose it. Sensitive requests always stay on your own device or within your team.

The approaches mentioned in the article represent different technical paths for distributed AI compute. Petals is a form of model-parallel sharing: a large model is split by layer, different volunteers each hold a portion, and one inference pass chains together multiple machines — if any layer drops, it breaks, so it typically only works on homogeneous, well-connected nodes, and for privacy each machine sees only intermediate activations rather than the full prompt. AI Horde is task-level crowdsourcing: an entire task is assigned to a single volunteer, who can see all inputs and outputs, with credits incentivizing continued contribution. Exo relies on a user's own multiple devices (laptops, phones, desktops) forming a LAN cluster, with no stranger compute involved. VolksAI's choice is task-level crowdsourcing plus complete single-machine inference, balancing implementation simplicity and controllable latency — at the cost that the host inevitably comes into contact with the plaintext prompt.

Feedback the author wants to hear

The article ends with a set of questions and a fairly open attitude:

• Privacy: "The host sees your prompt, the broker doesn't" — can you accept that trade-off, or is any remote computation unacceptable?
• Fairness: Does sharing compute for credits seem fair, and does the CPU work path just make people without GPUs "feel included" without real benefit?
• Abuse: What stops the pool from being filled with hosts offering junk models, and who should police it?
• Would you use it: As a host, as a user, both, or neither — "neither" is also a valuable answer.
• Organizational scenarios: Would your school, university, or team use a private pool like this? What would admins need to trust it?

The author reiterates at the end: this is just an idea, not in the app, not part of any current release plan, and not a promise or timeline. The discussion itself is the point.

For developers following local AI deployment and edge compute sharing, this concept's trust tiers and its honest disclosure that "host can see prompt" deserve closer attention than many comparable proposals.

One-line Summary

LastBrowser proposes the VolksAI draft: match idle local model compute, while admitting hosts can see prompts.

Paragraph Summary

VolksAI is an undeveloped concept from the LastBrowser team that aims to share idle local model compute from Ollama, llama.cpp, and LM Studio users with users lacking hardware, via a broker that only routes and doesn't read prompts. The design includes a four-tier trust model (own devices, friends and teams, verified hosts, public pool) plus organization-owned private intranet pools, with sensitive content never routed through the public pool. The author explicitly admits encryption only protects the transport link and that hosts inevitably see prompts, refusing to package it as fully private. Shared compute earns non-withdrawable internal credits, and users without GPUs can contribute CPU work. The article also proactively compares the idea to AI Horde, Petals, Exo, and NVIDIA PAIR, and lists questions on privacy, fairness, abuse, and organizational scenarios to seek feedback.