What a sub-cent embedding actually costs to run

Pricing update, July 2026. This post was written when embeddings were

$0.0088 per million tokens. Pricing has since moved to a single published

rule — **every workload is priced 30% below the cheapest named competitor,

with a flat 20% platform take — which puts `coreml_embed` at $0.014 per

million tokens** against OpenAI's $0.02. The cost analysis below is unchanged

and still shows what the work actually costs to run on idle Apple Silicon;

only the price we charge on top of it has moved. Current prices are always on

/pricing.

We originally charged customers $0.0088 per million tokens for text embeddings (coreml_embed) — about 56% under OpenAI's text-embedding-3-small at $0.02/M (OpenAI pricing, list price June 2026). The question every prospective customer asks is whether a price that low is sustainable or a temporary loss-leader.

This post pulls the curtain back, and it ends with a recipe so you can reproduce the number yourself rather than take our word for it. Our pricing is bottoms-up from what already-bought consumer hardware actually costs to run — not topped-down from a data-center bill. The unit economics are mechanical and inspectable. Here they are.

The hardware baseline

We run embeddings on Apple's Neural Engine via Core ML. The dispatcher prefers base-M2, base-M3, and base-M4 Macs (16 GB unified memory, single-cluster ANE); M-Pro and M-Max devices win on per-token latency but waste unified-memory headroom that could serve a fatter model, so we route them elsewhere. (Today the production default is Apple's on-device Core ML embedding; larger Core ML embedding models — EmbeddingGemma-class — are rolling out. This post is about cost, not quality — bring your own eval set; the free benchmark below is there for exactly that.)

On a typical base-M3 16 GB Mac, plugged in and thermally stable, for a ~300M-parameter Core ML embedding model. Treat the throughput as a bench estimate pending fleet telemetry — the method is the point, not the third decimal:

• ANE throughput: ~17,000 tokens/second sustained (burst touches ~22k; we plan around sustained).
• Active power draw: ~18 W at the wall, measured with a Kill-A-Watt across five provider Macs. Idle is ~7 W, so marginal power during inference is ~11 W.
• Effective utilization: ~78%. The other 22% is dispatch overhead, first-request model load, and the inter-task wait for the next assignment.

So the marginal cost of a million tokens, at sustained throughput and effective utilization:

1,000,000 tokens / 17,000 tok/s / 0.78 utilization
  = 75.4 active seconds per million tokens
  = 75.4s × 11W = 829 watt-seconds = 0.23 watt-hours

At a US residential rate of $0.16/kWh, that's $0.000037 per million tokens in electricity. Round up generously if you're somewhere expensive; it's still rounding error. The marginal cost of an embedding on a Mac that's already powered on is essentially zero.

Why we charge a fraction of a cent, not zero

Three reasons the price isn't six orders of magnitude below where it is now.

Dispatch overhead is real. Every task carries fixed costs that don't scale with token count: the WebSocket message, the assignment-signature verification, the result-envelope round-trip, the ledger write at the coordinator. Roughly 280 ms of provider wall time plus ~4 KB of traffic per task. In aggregate that's a non-trivial slice of operational load — and it's why micro-jobs aren't worth anyone's time (more below).

Hardware amortization. Providers bought a Mac. "What should the Mac earn per active hour to be worth it" is what determines whether supply exists at any price. Our earnings estimator targets cost-recovery for a base M3; at embedding throughput that lands the price floor right around where it sits.

Coordination cost. The platform's share of the price has to cover Workers, D1, R2 bandwidth, Stripe processing on both charges and payouts, the Apple Developer Program fee, notarization, the marketing site, the support inbox, and the people running it. Our orchestration runs on Cloudflare's edge, so this cost stays low and roughly flat with volume — which is a structural reason the price can stay where it is.

Why the price is sustainable

Per million tokens at the $0.0088 price this post analyses: the customer pays a quote locked before submission (rejected if max_spend_usd isn't set), the provider who ran the job is paid per completed task via Stripe Connect at a rate set to make running an already-bought Mac worthwhile, and the remainder covers payment processing and coordination. Every layer of that stack is cheap because none of it involves building or cooling a data center.

One honest wrinkle: payment processing carries fixed per-charge fees, which is why micro-volume doesn't pencil out — a one-million-token job once a day spreads those fixed cents too thin. The quote stays locked — we eat that — but it's why embeddings are a batch workload.

Where this breaks (honest caveats)

• Very low volume: per-task fixed costs dominate; effective cost climbs well above the per-million figure quoted here. Batch your embeddings.
• Very high volume: more than a single base-M3 can sustainably absorb, so we fan out across a wider pool — fine for throughput, but per-Mac thermal cycling becomes the constraint, managed with longer cool-downs.
• Non-US providers: electricity varies 4–6× (Germany ~30¢/kWh, Spain ~20¢, much of Asia ~10¢). The quote can't be conditional on which provider takes it, so expensive-grid providers self-select out or run off-peak. (We're US-only for now anyway.)

How we measured it — and how you can

The hardware numbers above came from a wall meter and a stopwatch, not a model:

1. Throughput: time an N-token batch on a thermally stable base-M3; tokens ÷ seconds. Repeat until stable. 2. Power: a Kill-A-Watt (or any wall meter). active watts − idle watts = marginal watts. 3. Cost: tokens ÷ tok_per_s ÷ utilization × marginal_W = watt-seconds → ÷ 3.6M = kWh × your $/kWh.

Plug in your own hardware and rate — the method travels.

And you can reproduce the price directly, which matters more than our bench:

# sign up at /signup — every job is quoted before it runs
import requests
r = requests.post("https://api.commoncompute.ai/v1/embeddings",
                  headers={"Authorization": f"Bearer {KEY}"},
                  json={"model": "coreml_embed", "input": open("corpus.jsonl").read()})
job = r.json()
print(job["price"], job["usage"])   # locked quote ÷ tokens = your real $/M

The quote is locked before the job runs and you aren't billed on failure, so the number you see is the number you pay.

The benchmark table (every comparison sourced)

List prices as of June 2026 — follow each link and check us against your own invoice. The "Common Compute" column below is the June 2026 snapshot and is no longer current: under the July 2026 rule every row is now priced exactly 30% under its reference. Our live prices are at /pricing and the `/v1/workloads` API — those are the numbers to check, not this table.

The gap exists because the hyperscaler rents hardware optimised for training, pays for a data center, cooling, and margin, and amortises GPUs bought at ~$30k apiece. Our network rents hardware that was already bought, in homes and offices already powered. That gap is the entire pitch.

What this doesn't say

This is about cost, not quality, and about a catalog of specific workloads — not frontier chat. Apple Silicon is the wrong hardware for 70B-parameter decoding throughput, and our chat pricing says so honestly: if chat is the bulk of your bill, route it to Together or Fireworks and use Common Compute for the workloads where the unit economics line up.

If your workload is on this catalog, apply for the design-partner program or just sign up and run a real benchmark on your own data — a serious evaluation costs pennies, and you only pay for jobs that succeed. We'd rather you verify than trust us.