Cost model

This page is a model, not a measurement. It extrapolates from one measured throughput figure and compares the result against published cloud list prices. Treat it as a way to find out whether macbatch is worth trying for your volume — not as a benchmark.

Change any input. All of them are assumptions.

inputs

documentsavg tokens / docMacs in poolscaling efficiency %watts / Macelectricity $/kWhcompare againstOpenAI text-embedding-3-small — Batch API (-50%) ($0.01/1M) OpenAI text-embedding-3-small — Standard ($0.02/1M) OpenAI text-embedding-3-large — Batch API (-50%) ($0.065/1M) OpenAI text-embedding-3-large — Standard ($0.13/1M) price $/1M tokens

Scale measured throughput by document length — benchmark items were ~26 tokens; turning this off assumes your documents embed as fast as short sentences, which they will not

macbatch · 2 Macs

$0.0038

wall time

38 min

throughput

15,768 docs/hr

energy

0.03 kWh

hardware

already owned

OpenAI text-embedding-3-small

$0.050

tier

Batch API (-50%)

tokens billed

5,000,000

dimensions

1536

wall time

provider SLA

difference

$0.046

macbatch is 13.1× cheaper on marginal cost for this job, and takes 38 min.

What this model does not include

• Your time. Ops, babysitting flaky workers, and re-runs are unpriced. At small volumes this dominates everything else on this page.
• Quality is not equivalent. nomic-embed-text is 768-dimensional; the models above are 1536-dimensional. Retrieval quality differs and this calculator does not model it. Benchmark recall on your own corpus before switching.
• Throughput is extrapolated. The measured figure is 252,686 items/hr on one Mac with ~26-token items. Scaling to longer documents assumes cost is linear in token count — approximately true for short sequences, not verified above the model's context window.
• Scaling efficiency is a guess. The one measured 2-Mac run achieved 1.18×, not 2×, because of greedy-lease skew. The default 60% is deliberately pessimistic. Do not raise it without measuring your own pool.
• Hardware is treated as free. That is the premise — idle Macs you already own. If you would buy machines for this, the model does not apply.
• Battery wear, network egress, and control-plane hosting are excluded.

How the estimate is built

Compute time starts from the fastest measured single-Mac run: 252,686 items/hour at shard_size=32 (run 20260803T090720Z_bc8d40f5).

Document length correction. Those benchmark items were short synthetic sentences of roughly 26 tokens. A 500-token document is ~19× more work. The calculator scales throughput by the token ratio, which assumes embedding cost is linear in sequence length — approximately true for short inputs, and not verified near the model's context limit. Turning this correction off makes macbatch look about 19× better than it is.

Fleet scaling multiplies by machine count and an efficiency factor. The default is 60%, chosen to sit below the one measured multi-machine data point: two Macs achieved 1.18×, or 59% efficiency. Raising this without measuring your own pool is guessing.

Energy is watts × machines × hours, defaulting to 25W per Mac under sustained load, priced at your electricity rate.

Cloud cost is tokens ÷ 1M × price. The default comparison is OpenAI's Batch API tier, which is 50% off the standard rate. That is the honest baseline: macbatch is a batch system with no latency guarantee, so comparing it against realtime pricing would flatter it by 2×.

Where this actually pays off

The shape of the answer matters more than any single number.

At small volumes, it does not. Embedding 10,000 documents through OpenAI's batch tier costs a few cents. No amount of electricity savings makes that worth configuring a machine pool, and the calculator will show a difference too small to care about.

At large volumes, the ratio gets extreme — because the hardware is treated as free. That is the premise: Macs you already own, otherwise idle. If you would buy machines to do this, the model does not apply and the answer is almost certainly to use a cloud API.

The break-even is dominated by your time. Ops effort is the real cost and it is not modelled here. A pool that needs an hour of babysitting has already cost more than most embedding bills.

What would make this trustworthy

This model rests on one measurement. To turn it into a benchmark:

1. Run a real corpus — actual documents at their real length, not synthetic sentences
2. Measure multi-machine throughput at shard_size=32, which has never been run
3. Measure the same corpus through a cloud batch API and record the invoice
4. Compare retrieval quality, not just cost

Until then, the honest summary is: the compute is nearly free if the machines are already yours and already idle, and the interesting question is whether the operational overhead is smaller than the API bill you are replacing. For most teams at most volumes, it is not. For a team re-embedding tens of millions of chunks on a recurring schedule, it might be.

Prices used

Verified 2026-08-03. Edit them in the calculator if they have moved.

Model	Tier	$/1M tokens	Dimensions
text-embedding-3-small	Batch	0.01	1536
text-embedding-3-small	Standard	0.02	1536
text-embedding-3-large	Batch	0.065	3072
text-embedding-3-large	Standard	0.13	3072

Sources: OpenAI embedding models