A fleet of Macs. One endpoint.

1. The problem

Frontier inference runs in a handful of data centers owned by a handful of companies. That concentration sets the price, decides which models you may call, and puts your data on someone else's hardware.

The hardware already exists. Apple Silicon puts a capable GPU next to a large pool of unified memory, which is what large models need most, and most of these machines spend their day idle. The gap is coordination, not silicon.

2. The system

Five parts, each with one job.

• Engine. Runs on each Mac. It loads open models (Llama, Qwen, DeepSeek, GLM, gpt-oss and others) with MLX and shards a model too large for one machine across Macs on the same local network: pipeline parallel over an ordinary LAN, tensor parallel over Thunderbolt 5 with RDMA. Its port is never exposed to the internet.
• Gateway. The only public entry point, api.siliconnetwork.io. It admits each request, routes it to a Mac, streams the answer back, and counts the tokens.
• Control plane. Accounts, teams, keys, prices, balances, the node registry, the scheduler and the ledger. The system of record, in Postgres.
• Relay. A Mac behind NAT opens one outbound WebSocket over port 443 and the gateway reaches it through the relay. No open port, no tunnel to configure. The relay counts tokens in transit, a second source the control plane reconciles against.
• Trusted engine. An engine the platform runs itself. Verification re-scores sampled responses on it, and moderation, when on, screens prompts with it. Today it is one Mac.

The API covers OpenAI Chat Completions and Responses, Claude Messages, Ollama chat and generate, embeddings, rerank, audio transcription and speech, image generation and edits, and the Files and Batch APIs. Existing clients switch by changing a base URL.

One limit shapes the design. A model is sharded only inside one local network, where links are fast. A Mac reached over the internet serves the models it holds whole, and the scheduler routes whole requests between clusters. Sharding one model across regions is planned, not built.

3. A request, end to end

A streaming chat completion crosses every part, in six steps.

1. Admission. The gateway checks the key with the control plane (cached for 15 seconds, so a short control plane outage does not stop known keys), then the key's scope, IP allowlist, rate limit, credit and spend caps. A refused request costs nothing.
2. Moderation. When enabled, Llama Guard on the trusted engine screens the prompt before routing, so a refused prompt never reaches an operator's Mac. It is off by default.
3. Routing. The scheduler picks an online Mac that holds the model, ranked by trust and filtered by the key's pins (regions, operators, attested nodes only). A prompt that shares a prefix with an earlier one goes back to the Mac that has it in cache; the match uses a keyed hash per organization, never text. A request can name a quantization (llama-3.1-8b@8bit) or a quality tier, a long prompt goes only to Macs that report enough context, and a list of models acts as a fallback chain.
4. Serving. The engine batches requests continuously, can decode speculatively, holds output to a JSON schema when asked, and applies LoRA adapters per request on a shared base model, so a fine-tune costs its own few megabytes rather than a copy of the model. Inside a cluster, a long prompt can be prefilled on one Mac and decoded on another.
5. Metering. The gateway counts tokens from the stream it relayed and sends a usage event, which the control plane prices. If the control plane is down, the event waits on disk and is replayed; duplicates are dropped by request id. A Mac's own count is bounded by what the gateway saw, so a node cannot inflate a caller's bill.
6. Receipt. On request, the Mac signs a receipt with its attestation key: hashes of the request and the response, the model's hash and the token counts. The gateway checks it and countersigns, and the SDKs verify both signatures against published keys. This is software attestation, not a hardware root of trust.

Routing does not yet weigh latency or distance between caller and Mac. That is planned.

4. Verification and trust

A distributed network raises a fair question: how do you know a Mac ran the model you asked for? Our answer today is statistical, not cryptographic.

The gateway samples a share of live requests on every surface that can earn and checks each against the trusted engine. For text the check is DiFR: the trusted engine scores the tokens the node actually served, in one teacher-forced pass, under the node's own sampler settings. An honest node's tokens score where the trusted model expects them, at any temperature; a node running a smaller model drifts. Embeddings are compared by cosine similarity, rerank and transcription by re-execution, tool calls by a replay at temperature 0. Canary probes cover idle nodes.

One sample proves little, so verdicts pool per node and model. The pool is tested against a bound on the false-accuse rate: 0.5 percent to withhold an earning, one in a million to slash. A failure can slash only when the node runs the same engine version, weights and model card as the trusted engine; anything else only lowers the node's rank. Quorum, which compares one request across several nodes, never slashes, since a colluding majority could otherwise outvote an honest node.

Earnings sit in escrow per node and model through a 72 hour holdback. The sweeper releases them only when live samples landed and, for chat, the pool passes. A failure beyond doubt forfeits the escrow and docks the operator's bond. A bond refund waits out an unbonding period of at least 168 hours, and the bond stays slashable until it ends. All of this is built; none of it moves money while payouts are off.

Limits

This is not a proof. Calibration so far covers one model family, small Llama 3.2 models, in process: no honest pool failed, and a 1B model served as 3B was caught by pools of ten samples in 98 to 100 percent of trials at temperatures up to 1.0. Above 1.0, detection drops sharply. Speech and image checks are built and stay off until they are calibrated.

Nodes also sign the hashes of the weights they run (ed25519), and a key can require attested nodes, but that attestation is software. Hardware attestation and a cryptographic proof of inference are planned research, and need hardware the current supply does not have.

5. Money

Callers prepay. A balance is credit in US dollars, topped up with stablecoins: USDT or USDC on Arbitrum One, USDC on Base, or USDT on Tron. A card works too: Privy's checkout buys USDC on Base into an embedded wallet, which then pays like any other. A watcher credits each transfer once its block is final, after a second RPC provider re-reads it from the chain. A platform fee applies to top-ups, and the dashboard shows the exact credit before you pay.

Spend is per token and per model, with a lower rate for cached prompt tokens, per-unit prices for images and audio, a discount for batch work, and a higher rate for the long-context tier. Organizations and individual keys can carry spend caps. The cost explorer breaks spend down by day, key, model and project tag, and exports it.

Operators who contribute Macs would earn a share of what callers paid for the work their nodes served, as credits spendable on inference. There is no cash-out, and none is being built. The earning path is built, escrow and bond included, and switched off. A published go/no-go checklist names what must be true first: verification deployed, calibration per model family on real traffic, bond and slash sized for real prices, and an external audit. Today it reads no-go.

There is no token in any of this. Inference is paid in stablecoins or by card, and nothing in the network reads or requires a token.

6. Operating it

Joining

An operator signs in from the menu bar app or the engine's dashboard with a one-time code, approves it on the web, and the Mac joins. Behind NAT it joins through the relay and opens no port. The operator chooses which running models to offer.

Updates

Engine releases are signed with ed25519 over a manifest that pins the hash of every file, roll out to a percentage of nodes, and install automatically where the operator opts in. The menu bar app updates through Sparkle with its own signature. No release key is pinned yet, so no release has shipped this way.

Keys

Keys carry a checksum, so a leaked one can be recognized in public code; the endpoint for GitHub's secret scanning revokes or flags a reported key (registration with GitHub is pending). A key can be limited to IP ranges, and unusual use (a spike, many new addresses, a new country, an unusual model mix) notifies the organization's owners or suspends the key.

Privacy

A request marked no-retention is never re-executed for verification, and the Mac is told to keep it out of its logs and caches. The control plane stores no API prompt content; the chat app keeps a user's conversations for the retention they choose. An operator can still see the prompts its Mac serves, so keys can be pinned to vetted operators. Confidential compute is planned.

Visibility

A public status page shows 90 days of uptime and incidents, with RSS and JSON feeds. A monitor watches the services and the billing watcher and alerts by email, Slack, Telegram or a signed webhook.

Building on it

A chat app at /chat runs on the same endpoint. TypeScript and Python SDKs (both verify receipts) and integrations for LangChain, LlamaIndex, the Vercel AI SDK, Continue, Open WebUI, LiteLLM, n8n and Zapier are written and tested, and will be published once inference is live.

7. What is built, what is not

Deployed

The gateway, the control plane, the relay and the billing watcher, and this site with its dashboard.

Built, not yet switched on

• Inference through production: no engine is connected yet.
• Top-up crediting on chain, and card payments.
• Verification sampling, and moderation.
• Operator payouts, behind the go/no-go checklist.
• Signed releases and engine auto-update, until a release key is pinned.
• The SDKs and integrations, until they are published.
• Linux nodes with CUDA: packaged, not yet run on a GPU.

Planned, not built

• Sharding one model across regions.
• Latency-aware routing.
• Hardware attestation and a cryptographic proof of inference.
• Confidential compute.
• A second trusted engine, so verification does not rest on one Mac.

Decided against

Cash-out of operator earnings. Operators earn credits for inference, nothing else.

We will update this paper as these change, and will not claim any of them before they are real.