Buzz Shared Compute: Pool Local AI Models in Teams

Buzz shared compute lets members of a Buzz community contribute their own machines' local AI models to a shared pool, so other members' agents can run inference on that hardware instead of a paid cloud API. Buzz's own design document states the goal plainly: "the idle GPUs scattered across your community become one pool, usable by every agent in the community, gated by the membership you already have." It ships inside Buzz, the self-hostable workspace by Block where humans and AI agents share the same rooms — and it is early software, at v0.5.2 as of 29 July 2026.

What Buzz shared compute is

Buzz shared compute is a feature that lets one member's machine serve a locally running language model to other members of the same Buzz community, so their agents can use it as an LLM provider. The repository calls it Buzz Mesh, and the pool is scoped to one relay community rather than the public internet.

It rests on a structural coincidence rather than new technology. Buzz is a Nostr relay where every message and agent action is a signed event, so it already maintains a cryptographic membership list. The design document is candid that "nothing here is new on its own" — pooling GPUs is solved, Nostr identity is solved — the insight is that the mesh's admission gate and the community's membership gate become the same gate. The consequence is worth quoting: "Non-members see none of this. They can't find the mesh, can't join it, can't serve to it or use it." Full rationale is in VISION_MESH.md.

Why pooling local models matters

There are three reasons to pool local models: cost, privacy, and independence from one vendor's catalogue and pricing. Each is real and each has a limit.

Cost. Runs on a member's machine generate no per-token API bill, which matters most for the high-volume, low-stakes work that quietly burns tokens: summarising channel activity, triaging notifications, watching a repository. Buzz's docs note that an agent inheriting shared compute needs no API key. The cost does not vanish — it moves to electricity, hardware wear, and whoever keeps the machine awake.

Privacy. Inference stays on hardware the community controls, and the Buzz relay never carries the prompt — MeshLLM moves it over direct QUIC or encrypted relays. That matters here because the hosted Block relay is not end-to-end encrypted. Block's own framing is the honest one: "Your prompts go to people, not a vendor… it is a different promise than 'your data never leaves your machine.'"

Independence. The pool serves open-weight models, so the community picks the model, the quantisation, and the upgrade schedule. Our guide to commercial versus self-hosted AI agents covers where that independence pays for itself and where it does not.

How it works at a high level

Enabling Buzz shared compute takes two steps: share a model from your machine, then point an agent at the shared-compute provider. The labels below come from the repository's own verification runbook, docs/buzz-shared-compute-dev.md.

Sharing your machine. You open Settings, select Compute, choose a suggested model under Share compute, and turn sharing on. Buzz may download the model on first use, and the runbook says to wait until the card reports it is sharing rather than downloading, preparing, or starting. The picker ranks candidates against your actual hardware and marks each with a fit label, steering you away from models your machine cannot hold.

Pointing an agent at it. On the Agents screen, Buzz shared compute appears as a Default LLM provider, with the model left as Default (auto); agents with no pinned provider inherit that default. One nuance the runbook flags: shared compute is an LLM provider, not a run location — do not pick a remote backend as the place the agent runs just because its name mentions mesh.

What automatic buys you. Leaving the model on automatic is what lets larger models become available as more capacity joins; the v0.5.0 changelog includes a change to "use collective mesh routing for Auto." The design document goes further, describing a mesh that can split a model too large for one machine across several, "each holding a slice." Treat that as stated direction rather than a guarantee — the document says what the mesh "can" do, and I have not verified split-model inference on live hardware.

Expect this to change. The repository was created 6 March 2026 and last pushed 29 July 2026, and the compute UI has churned across releases — v0.4.25 alone shipped a shared-compute usability pass covering the share toggle, usage indicator, and model resync. Labels, provider names, and defaults may differ by the time you read this, so check github.com/block/buzz and its changelog before trusting any walkthrough, this one included.

Realistic hardware expectations

Local models pooled across laptops and desktops are slower and generally less capable than frontier cloud models, and pooling does not change that by itself. Shared compute moves spend and trust; it does not deliver Claude-grade or GPT-grade output for free.

The model scale involved is a useful reality check. Buzz's runbook uses a quantized Qwen3.5 4B model on a 16 GB Apple Silicon machine for its hardware proof, and the settings card's own example is an 8B model at Q4 quantisation. Those are competent small models, not frontier ones — and the runbook warns that a sub-1B model can prove inference is reachable while still failing an agent's long prompt and required tool call.

Two implications follow. Task fit matters more than usual: classification, summarising, drafting, and tool-triggering suit small local models far better than multi-file refactors. And latency depends on whoever is serving — a teammate's laptop three timezones away is not a datacenter. Our roundup of the best models for agent runtimes covers the same size-versus-capability trade-off.

Cloud harness vs Buzz shared compute

A cloud harness and Buzz shared compute differ on six dimensions that drive the decision: cost model, speed, model ceiling, privacy, setup effort, and best use. Here is how they compare as of July 2026.

The two are not mutually exclusive, which is the point most write-ups miss. Buzz supports Claude Code, OpenAI Codex, and Block's own Goose as harnesses, so one community can run cheap chores on pooled local models while a frontier harness handles the hard work in the same channels.

Where this fits for a community or small team

Buzz shared compute fits a small team that already trusts each other, already owns idle GPU capacity, and already has an API bill worth reducing. The design document's example — three people with a gaming PC, a laptop, and a workstation under a desk — is genuinely the ideal case, not a large community of strangers.

The prerequisite most people underestimate is the relay. A Buzz community is reached by URL, and in the single-relay setup shipping today one relay equals exactly one community. It coordinates membership, discovery, and the workspace itself, so running it on a laptop means the community disappears when the lid closes.

For a 24/7 relay you want a small always-on VPS. Buzz's production Compose bundle in deploy/compose/ expects Docker plus Postgres, Redis, and S3/MinIO, with optional Caddy for TLS — the root docker-compose.yml is development-only. The fastest path is a one-click Buzz deployment on Hostinger, which handles the Docker layer for you — as of July 2026, KVM 1 is $6.49/mo and the "Most Popular" KVM 2 is $8.79/mo, with weekly automatic backups and a 30-day money-back guarantee. That is a referral link: I earn a commission if you buy through it, at no extra cost to you.

Note where hardware actually matters: the relay is a light coordination service, while the heavy inference load sits on member machines. Sizing the relay is a different exercise from sizing a GPU box — our best VPS guide for agent workloads covers the RAM and CPU floors that bite, and you can compare deployment options side by side if you are still picking a hosting shape.

Buzz is the room, not the worker: runtimes like OpenClaw and Hermes Agent are what you operate, and Buzz is where they appear as members with signed identities. Skills and MCP servers installed for those runtimes — the kind indexed in the Remote OpenClaw skills directory — stay usable either way.

Limitations and Tradeoffs

Buzz shared compute has five limitations that should shape how much you rely on it, and most are acknowledged in Block's own documentation.

It is early software. Buzz is at v0.5.2 as of 29 July 2026 and shared compute is its least documented feature — the main written reference is an internal verification runbook, not user docs. The changelog for this area is full of fixes to startup, model discovery, and runtime supervision.

There is a quality and latency ceiling. Quantized 4B-to-8B-class models are the realistic serving target on typical member hardware. Do not plan production-critical reasoning around them.

It depends on members keeping machines online. The mesh is opt-in by design, which Block frames honestly: "A relay where nobody shares compute has an empty mesh." Availability is a social property, not a technical guarantee.

Your hardware bears the load. If you enable sharing, other members' prompts consume your GPU, memory, power, and thermal headroom — on a laptop you are volunteering battery and fan noise. Buzz surfaces a consent panel for exactly this reason.

Shared compute means trusting the community. Prompts go to people rather than a vendor, so as Block puts it, "A community is only as private as its membership is trustworthy." The boundary is member-signed discovery with membership-gated admission, and the runbook is specific about where it stops: the pinned MeshLLM version performs its owner check during gossip, after the transport connection is established, and authenticating before gossip is described as an upstream protocol change not claimed by Buzz's own checks. Read block/mesh-llm if that matters to you, and our AI agent security risks guide before pointing agents with real permissions at pooled hardware.

When not to use it: regulated data with a residency requirement, output that must match a frontier model, uptime commitments to paying customers, or any community where you would not hand a member your unencrypted prompts.

Related Guides

• Commercial vs Self-Hosted AI Agents: Full Guide
• Best VPS for Running AI Agents 24/7
• Best Models for Hermes Agent
• AI Agent Security Risks: What Actually Goes Wrong