CommonCompute
Get startedDownload the Mac app
← All posts
May 13, 2026·6 min·Common Compute

Why we run on idle Macs, not data centers

The economics of consumer Apple Silicon are weird in a useful way.

There are roughly 100 million Apple Silicon Macs in the wild. The average one is idle 18 hours a day. The active hours are mostly light tasks: a Slack message, a Notion edit, a few browser tabs. The dedicated machine learning hardware on every M-series chip — a 16–18 TOPS Neural Engine on a base M3, 38 TOPS on M4, plus a Metal GPU that can run inference at competitive throughput — sits unused for the overwhelming majority of those clock cycles.

That's the asset we run on.

The pitch in one paragraph

You install Common Compute on your Mac. It enrolls as a provider on our network. When your Mac is awake, on power, and inside your settings, it picks up small AI workloads from a queue — audio transcription, embeddings, image upscaling, a 1B-parameter language model — runs them in a native runner, and records eligible earnings through Stripe Connect. Balanced mode backs off when your Mac is hot, on battery, heavily loaded, or manually paused.

On the customer side, you hit a single API with a task type and inputs. We dispatch it across the network at a per-task locked price set at 30% below the cheapest named competitor for that workload — a flat, published rule rather than a per-workload negotiation. (An earlier version of this post said "5–50× cheaper"; pricing moved to the uniform 30%-below rule in July 2026.)

Why not just use hyperscale GPUs?

Three problems with the obvious path:

  • Cost. A pre-loaded base-M3 Mac running Whisper Large at a comfortable thermal envelope serves audio transcription at roughly 1/30th the marginal cost of an A100 doing the same work. Apple Silicon's unified memory architecture is the right shape for the inference workloads the catalog actually serves. The hyperscaler is paying for hardware optimised for training, then renting it out for inference at a markup.
  • Cold start. A serverless GPU function on the major clouds takes 10–60 seconds to wake a container. Our providers are already up. Dispatch latency is around 50 milliseconds.
  • Honest cost surfaces. Cloud GPU pricing is per-second; you pay during cold start, model load, queue waits, and the request itself. We quote the price before you submit and lock it. If the task fails, you don't pay. If it succeeds, you pay exactly what the quote said.

Why not just use your own Mac mini fleet?

For some shops, that's actually the right call — and we'd happily lose a customer to a well-run self-hosted fleet. The tradeoff is the operational tail: replacing the M2 that died last week, finding a colo that lets you stack 50 Mac minis, dealing with the wall of power-cycling questions when one randomly throttles.

Common Compute is the answer when you want the Apple-Silicon economics without owning hardware. We're the answer to "I want the unit economics of dedicated Apple Silicon without the unit operations of dedicated Apple Silicon."

Where this doesn't work

Some workloads are genuinely the wrong shape for our network. We've said this on our pricing page FAQ and on the comparison pages — for the same reason it goes here:

  • Frontier chat / instruct LLMs at scale. Apple Silicon serves a 70B-parameter Llama model at maybe 1/100th the throughput of an H100. We won't pretend otherwise. If chat is the bulk of your bill, route it to Together or Fireworks and use us for the rest.
  • Workloads that require >36 GB of unified memory. Our supply distribution is a long tail of consumer-grade Macs (base M2, M3 16GB) plus a thinner head of M-Max/Ultra rigs. The fat-model jobs route to the head but the supply is genuinely smaller.
  • Sub-second interactive workloads. We do realtime dispatch but it's measured in tens of milliseconds, not sub-five. If you need a sub-five-ms inference response, you need a colocated GPU, not a marketplace.

Why providers do it

I'd love to say "to fund their next Apple purchase" but the real answer is messier. The providers I talk to fall into three groups:

1. People who like the idea. "My idle MacBook earning $50 a month is just... cool." The economics are decent but not life-changing for an individual Mac. 2. Small studios and design shops. They have 4–20 Macs across the team. The dollars matter at the studio level and the operational burden is roughly zero. 3. Capacity speculators. A handful of operators stack 30–60 Mac minis in a colo or basement and run us like a small hosting business. The unit economics work out well above 10 machines because Mac mini hardware is durable, draws ~15W average at our workload, and resells for ~70% of cost after three years.

Providers are paid per completed task, weekly, through Stripe Connect — real dollars to a real bank account, with an itemized ledger behind every payout. Our job is to keep those payouts steady and predictable; a provider earning a consistent amount every week is worth more to the network than one swinging between feast and famine.

What we're building toward

The catalog is small on purpose: audio (Whisper), embeddings, image upscale, SDXL, small LLM inference. We'd rather serve five workloads brilliantly than fifty mediocre-ly. The roadmap shows what's next — reserved-capacity tiers, real-time dispatch mode, Python and TypeScript SDKs with the same surface as our LangChain integration.

If this resonates, the easiest way to engage is to sign up and run a workload — every job is quoted before it runs, you only pay for successful work, and a real evaluation costs pennies. The runtime tells you more than any blog post.

Common Compute is a marketplace for AI workloads on Apple Silicon Macs. Providers are paid through Stripe Connect, customers are charged per-task with locked quotes, and we try to be honest about where we don't compete.

Common Compute is a marketplace for AI workloads on Apple Silicon Macs. Provider payouts use Stripe Connect and quote customers a locked per-task price. Sign up — every job is quoted before it runs, billed only on success.
More from the blog