Darkbloom Turns Idle Macs Into an AI Cloud

The strangest AI provider on OpenRouter may be a Mac mini sitting under somebody else’s monitor.

That is the proposition behind Darkbloom, a distributed inference network from Eigen Labs. Developers pay to run open-weight AI models. Instead of sending every request to a conventional GPU data centre, Darkbloom routes it to an available Apple Silicon Mac. The Mac owner supplies the hardware and electricity, then receives the inference revenue.

It is not crypto mining. The machine is doing a specific job for a paying customer: loading an AI model, processing a prompt, and returning generated tokens.

The project drew attention after creator Gajesh Naik said on August 21 that Darkbloom had moved from OpenRouter’s free tier to paid usage, served close to 4.5 billion tokens, reached a $102,000 annual recurring revenue run rate, and had 250 Macs online. He also said operators were earning $120-$200 per month per machine.

Those are exciting numbers. They also need careful labels. They are founder-reported, a run rate is not the same as contracted annual revenue, and a young network’s supply and demand can change by the hour.

The product is moving unusually fast. When we checked Darkbloom’s live stats endpoint on August 25, it reported roughly 1,016 active providers, 827 code-attested providers, and 8.5 billion tokens in the previous 24 hours. These are useful live operating signals, but they remain Darkbloom’s own measurements rather than an independent audit.

The short version

• Darkbloom is a real, working inference network. It has a public code repository, live APIs, public provider-attestation records, Stripe-based billing and payouts, and a listing on OpenRouter.
• Apple Silicon is a sensible target. Unified memory lets higher-memory Macs hold open-weight models that would exceed a normal consumer GPU’s VRAM, while mixture-of-experts models only activate part of their total weights for each token.
• Privacy is the hard and interesting part. Darkbloom tries to prevent the Mac owner from inspecting customer prompts by running inference inside one signed, hardened Swift process and verifying the device’s security state.
• “Private” does not mean nobody handles plaintext. Darkbloom’s coordinator decrypts requests transiently inside a confidential virtual machine before re-encrypting them to the selected provider. OpenRouter is an additional intermediary when that route is used.
• The income is not guaranteed. Darkbloom’s own calculator currently shows materially lower numbers than the founder’s post for many machines, and adding providers faster than demand can dilute paid work per Mac.
• It is explicitly an evaluation product. Darkbloom says the public alpha is unaudited, may break, has no uptime or support commitment, and should not be used in production.

What Darkbloom actually does

There are three parties in a normal request:

1. The developer calls an OpenAI-compatible API directly or selects Darkbloom as a provider through OpenRouter.
2. The coordinator authenticates the request, checks available capacity, selects an eligible Mac, meters usage, and handles billing.
3. The provider Mac decrypts the assigned request inside the Darkbloom process, runs the model locally through Apple’s MLX framework, and streams an encrypted response back through the coordinator.

Providers make outbound WebSocket connections, so a Mac owner does not need to open an inbound port or configure a home router. For a developer, Darkbloom’s direct API is designed to work by changing the base URL in an existing OpenAI client. The project also documents an Anthropic-compatible Messages endpoint and an OpenAI-style Responses endpoint.

Darkbloom currently focuses on open-weight mixture-of-experts models. Its live model catalog includes GPT-OSS 20B, Qwen3.6 35B A3B, and several Gemma 4 26B builds. The OpenRouter provider page listed Qwen3.6 35B A3B and Gemma 4 26B when we checked. Availability can differ between Darkbloom’s own network and the subset exposed through an aggregator.

Why a Mac can be useful AI infrastructure

Most consumer GPUs have fast memory but relatively little of it. A 24GB graphics card may be powerful, yet it cannot hold a model that needs 30GB or 60GB without offloading weights and losing speed.

Apple Silicon uses unified memory shared by the CPU and GPU. A Mac Studio can therefore give a local model access to 64GB, 128GB, 192GB, or more without copying every tensor between separate system and graphics memory pools. That makes a high-memory Mac unusually good at fitting large models into one quiet machine.

Darkbloom’s economic case is strongest for mixture-of-experts, or MoE, models. A model may contain 26 billion or 35 billion total parameters while activating only 3-4 billion for each token. The full model still needs to fit in memory, but the active weights moving through the memory bus per generated token can be much smaller than the headline parameter count suggests.

This does not make a Mac universally cheaper or faster than a cloud GPU. Dense large models still benefit from the enormous bandwidth and batching of data-centre accelerators. Consumer networks also add latency, uneven hardware, home-internet failures, and availability changes. Darkbloom is making a narrower bet: already-purchased unified-memory Macs can serve selected MoE models cheaply enough to undercut conventional APIs.

That is a credible wedge. It is not yet proof that idle consumer computers can replace a reliable inference fleet.

How Darkbloom tries to hide your prompt from the Mac owner

The provider operator is the unusual adversary here. They own the computer, may have administrator access, and physically control the hardware processing somebody else’s prompt.

Apple Silicon does not expose a general-purpose trusted execution environment that lets a third-party app encrypt its working memory from the machine owner. Darkbloom instead tries to remove the normal software paths into that memory:

• In-process inference: the network client, decryption, tokenizer, model and MLX generation engine run inside one Swift process. There is no local Ollama server, subprocess, pipe, or localhost API for an operator to tap.
• Debugger and memory-read blocking: the signed app invokes PT_DENY_ATTACH and uses Apple’s Hardened Runtime without the entitlement that would permit debugger access.
• System Integrity Protection: SIP makes those controls difficult to bypass while the process is alive. Disabling SIP normally requires restarting into Recovery, which terminates the inference process and clears its working memory.
• Hardware-bound identity: a Secure Enclave key identifies the provider, while Apple’s Managed Device Attestation can provide Apple-signed evidence about a genuine device and selected security properties. Apple describes MDA as a cryptographic declaration for trust decisions, not a complete guarantee that every application action is safe.
• Code-identity checks: Darkbloom says APNs challenges help prove that the provider is running a genuine team-provisioned build rather than an operator-modified binary that logs prompts.

The public provider-attestation endpoint exposes trust level, chip, memory, SIP, Secure Boot, Secure Enclave and MDA status. Publishing the chain is a strong transparency choice because a client does not have to accept a single “verified” badge with no underlying record.

The design is technically ambitious, but it is still a project security claim, not an audited guarantee. Darkbloom’s April technical paper assumes there is no unpatched macOS kernel vulnerability capable of bypassing the protections. It also acknowledges observable timing metadata, a physical-memory attack, reliance on Apple infrastructure, and unfinished enforcement around hypervisor isolation for RDMA-capable systems.

Its repository adds the most important warning: Darkbloom has not been audited and is for testing, not production.

“End-to-end encrypted” needs a footnote

Darkbloom’s marketing says requests are encrypted before transmission and prompts remain hidden from operators. The narrower claim—hidden from the owner of the provider Mac through ordinary software access paths—is the one the architecture is designed to support.

The complete request path is more complicated:

Stage	What happens to the request	Trust boundary
Developer to Darkbloom	TLS by default; optional sender-side NaCl Box encryption	The coordinator decrypts inside confidential-VM memory
Inside the coordinator	Plaintext is used transiently for compatibility, routing and billing	Darkbloom says content is not logged or retained in ordinary request logs
Coordinator to provider	Re-encrypted with a fresh key to the selected provider	Only the provider’s hardened process should decrypt it
Through OpenRouter	OpenRouter terminates its own TLS connection before forwarding	OpenRouter becomes another party with technical access in transit

Darkbloom’s own privacy policy is refreshingly precise: the current coordinator processes payloads in plaintext transiently and users should not treat every service path as making coordinator access technically impossible. It also says the privacy architecture only covers Darkbloom’s part of the path when a third-party router is involved.

OpenRouter’s provider directory currently labels Darkbloom “Retains prompts” and not zero-data-retention. That classification is more conservative than Darkbloom’s statement that ordinary coordinator logs omit prompt content. The two may reflect different policy definitions or a stale provider declaration, but a customer should not resolve that ambiguity in the product’s favour.

If a workload contains customer records, private source code, legal material, health data, unreleased financial information, or secrets, wait for an independent audit and clear contractual data terms. “The operator cannot attach a debugger” is valuable; it is not a substitute for a complete production security programme.

Can an idle Mac really earn $120-$200 a month?

Possibly for some early, well-matched providers. It is not the number a new operator should put into a purchasing spreadsheet.

Darkbloom’s own earnings calculator currently estimates roughly $16-$100 per month for a 48GB Mac. Its illustrated upper case assumes the machine serves requests 60% of the time it is online, averages 2.5 concurrent requests while active, pays $0.15/kWh, and draws about 30W of incremental power during inference. The example combines around $84 of usage income with a $16 base reward.

That estimate contains several moving parts:

• Demand: revenue exists only when customers choose a model your Mac can serve.
• Memory: the live catalog lists minimum memory around 24GB for GPT-OSS, 32GB for Qwen3.6, and 36GB for current Gemma builds. An 8GB or 16GB Mac may run smaller local models but has little access to today’s paid catalog.
• Competition: the scheduler can choose among many machines. If provider supply grows faster than requests, utilization per operator falls.
• Uptime: base rewards require an attested, healthy machine online for at least 90% of each settlement period and come from a fixed monthly pool.
• Power and disruption: electricity may be modest, but heat, fan noise, memory pressure, model downloads, network use and reduced availability for the owner’s own work still have value.
• Policy: Darkbloom’s terms say alpha earnings can be interrupted, reduced or suspended as the service changes.

The founder’s $120-$200 figure may describe machines with larger memory, favourable model demand, high availability, or early-network economics. Without a distribution of settled payouts by chip, memory, model and online hours, it should be treated as an anecdote.

The $102,000 ARR claim needs the same discipline. Annual recurring revenue usually describes durable subscription contracts. Darkbloom had only just switched from free to paid OpenRouter traffic, so this appears to be an annualized run rate based on a short operating window. It shows that paid traffic existed; it does not show that $102,000 has been collected or will recur for twelve months.

What providers are paid from

Darkbloom’s live pricing endpoint showed the following direct rates on August 25, per million tokens:

Model	Input	Output
GPT-OSS 20B	$0.020	$0.100
Gemma 4 26B	$0.042	$0.220
Qwen3.6 35B A3B	$0.070	$0.700

During public alpha, Darkbloom says the hardware operator keeps 100% of inference revenue and the platform takes no fee. Customers fund an internal ledger through Stripe, and provider payouts use Stripe Connect. The economics are therefore closer to a tiny cloud-compute marketplace than a token-reward scheme.

Zero platform fee is a launch incentive, not a permanent business model. A responsible payback calculation should allow for future fees, lower prices, additional providers, changing model popularity and taxes.

What installing Darkbloom changes on a Mac

The current provider is a command-line tool for Apple Silicon. Darkbloom documents macOS 14 or later, 50GB of free disk as a minimum, a stable outbound connection, and 32GB or more of memory as the practical recommendation.

The installer downloads a signed and notarized bundle, verifies hashes and the Apple Developer ID signature, and configures a background launchd service. Darkbloom says it needs no sudo. The provider can schedule availability windows, reserve memory, choose downloaded models, benchmark locally, and unload idle models.

Full hardware trust can also involve an MDM enrollment profile. Darkbloom’s terms say its requested MDM permissions are limited to device and security-status queries and exclude remote erase, lock, app installation, app removal, and user-content access. That is better than asking for broad device-management control, but an MDM profile is still a consequential trust decision.

Do not paste a curl | bash command into a primary work machine because a social post said it earns money. On a spare Mac:

1. Read the installation documentation and inspect the installer URL before running it.
2. Verify the downloaded signature and the MDM permissions shown by macOS.
3. Back up the machine and remove unrelated credentials or sensitive local data.
4. Start with local benchmarking or Darkbloom’s free self-route mode.
5. Measure actual settled income, wall power, heat, network use and lost availability before enabling an always-on schedule.

Buying a new Mac to join the network reverses the project’s best economic argument. Darkbloom is compelling because the hardware is already paid for. Once a provider must recover thousands of dollars of new capital expenditure, the payback becomes speculative.

Who should try Darkbloom now?

A tinkerer with a spare 32GB-or-larger Mac: yes, cautiously. The system is technically interesting, the operator setup is transparent enough to inspect, and local/self-routed inference is useful even if public demand disappoints.

A developer evaluating cheap open-weight models: maybe. Use non-sensitive workloads, pin the provider deliberately, measure quality and latency, and keep a reliable fallback. OpenRouter makes comparison convenient, but its current data-retention label matters.

A company sending confidential production data: not yet. The project itself says evaluation only. Wait for an audit, stable privacy declarations, incident-response commitments, a data-processing agreement where relevant, reliable availability, and a clear zero-retention route.

Someone considering buying hardware for passive income: no—not from today’s evidence. Run the exact hardware you already own, collect settled payouts over time, and calculate a downside case before spending money.

The real experiment is bigger than passive income

Darkbloom is interesting because it connects three ideas that normally live apart: the enormous installed base of Apple Silicon, open-weight MoE models that fit unified memory unusually well, and hardware-backed device verification intended to make strangers’ computers usable for private inference.

If the privacy controls survive scrutiny and customer demand stays ahead of provider growth, idle Macs could become a meaningful second tier of AI infrastructure: slower and messier than a hyperscale GPU fleet, but cheap, geographically distributed and already sitting on desks.

If demand fades, the same network becomes a familiar marketplace problem—many providers competing for too few paid jobs. If the security design fails, low prices will not save it. And if the coordinator or aggregator remains inside the plaintext trust boundary, Darkbloom should be described as operator-resistant inference, not magic privacy.

That is why it is worth watching. The product does not need to replace the cloud to matter. It only needs to prove that a verified spare Mac can complete useful AI work, protect the customer’s content well enough for its stated use case, and earn more than it costs to keep online.

Sources

• Gajesh Naik’s August 21 Darkbloom update on X
• Darkbloom product, pricing and earnings estimator
• Darkbloom source repository and public-alpha warning
• Private Distributed Inference on Consumer Hardware technical paper
• Darkbloom live network statistics
• Darkbloom live model catalog
• Darkbloom live pricing
• Darkbloom privacy policy
• Darkbloom terms of service
• OpenRouter’s Darkbloom provider page
• OpenRouter provider data-practice directory
• Apple: Managed Device Attestation for Apple devices

Put this to work

Evaluate distributed inference as a complete system: model fit, demand, routing, operator privacy, coordinator trust, uptime, power, payouts, and failure conditions.

Try

Use a spare 32GB-or-larger Mac for local benchmarks or self-routed, non-sensitive workloads before allowing public jobs. Inspect the installer and MDM profile first.

Prove it worked

Record wall power, tokens per second, online time, paid utilization, gross payout, electricity cost, thermal behavior, and any disruption to your normal work for at least a week.

Where it can pay

Treat any payout as variable capacity revenue. Do not buy a Mac from an annualized estimate until your own settled earnings cover hardware, power, downtime, and tax obligations.

Keep in view

• Darkbloom routes paid AI inference to Apple Silicon Macs and is already available as a provider on OpenRouter.
• The founder reported 250 machines and a $102,000 ARR run rate on August 21; Darkbloom's own API showed roughly 1,016 active providers four days later, but neither figure is an audit.
• Darkbloom's estimator puts a 48GB Mac at roughly $16-$100 per month under stated assumptions, below the founder's $120-$200 claim.
• The privacy design blocks ordinary Mac-operator access, but the coordinator still processes plaintext transiently and the project explicitly says not to use it in production.

Learn the workflow: choosing between hosted and open-weight AI models →