Darkbloom, an open-source project from Eigen Labs, is trying to turn idle Apple Silicon Macs into paid compute nodes for a decentralized AI inference network. When developers call supported AI models, those Macs do the work and the machine owners collect revenue.
According to an official post on X, Darkbloom currently has 250 Macs online and has served 4.5 billion tokens in total. The project has also moved up to become a paid provider on OpenRouter. Eigen Labs said node operators can earn about $120 to $200 per machine each month.
What Darkbloom is building
Darkbloom, whose open-source codename is d-inference, is described as a private inference network built for Apple Silicon. The basic model is straightforward: aggregate unused compute from Macs, expose that capacity through an OpenAI-compatible API, and let developers plug in without rewriting their applications. Mac owners, in turn, can monetize spare hardware.
The article says more than 100 million Apple Silicon devices have shipped globally since 2020, with those machines sitting idle for about 18 hours a day on average. Darkbloom is built around the idea that M-series chips are already capable AI hardware, and that this unused capacity can be pooled into a lower-cost inference cloud. The team says pricing is roughly half that of mainstream API providers.
How the network works
The system has three main roles.
- Developers send inference requests through APIs compatible with OpenAI and Anthropic.
- The coordinator, operated by Eigen Labs, handles identity, routing, billing, and hardware attestation, but does not see the request contents.
- Providers are Mac owners contributing hardware. Their machines run models on Apple Silicon GPUs through the MLX framework and return the results.
Privacy is central to the design. Requests are end-to-end encrypted before transmission using NaCl Box, X25519, and XSalsa20-Poly1305. Darkbloom says that even when a provider machine receives a job, it cannot read the prompt or the response in a usable form.
The project also says inference runs in-process, with debuggers and memory reads blocked, while Apple Secure Enclave is used for hardware attestation. The promise, as framed in the article, is that the coordinator can route traffic and the provider can compute it, but neither side gets access to readable request data.
Hardware requirements: minimum spec and practical spec are not the same
The article draws a sharp line between the technical minimum and what is actually practical for the models currently available on the network.
| Item | Technical minimum | Practical recommendation |
|---|---|---|
| Chip | Apple Silicon, M1 or newer | M1 Pro, Max, Ultra, or newer |
| Unified memory | 8GB | 48GB or more |
| Operating system | macOS 14 Sonoma or newer | Latest stable version |
| Storage | 50GB free space | 100GB or more |
An entry-level 8GB Mac may be able to install the software, but it cannot run the models currently live on the network. Darkbloom says the main models it is targeting right now require at least 48GB of unified memory. That is why higher-memory machines such as Mac Studio are a better fit for providers. Models load only when they still fit after leaving about 2GB of memory headroom.
How to join as a provider
The provider client is a Swift-based command-line tool. The installation and setup flow is relatively short.
- Install: Run the official install command in Terminal. It verifies file hashes and code signatures, then deploys the Secure Enclave helper component.
- Start: Use darkbloom start to run it as a background service through launchd and open an interactive model selection flow. Add --foreground to keep it in the terminal.
- Log in and link an account: Use darkbloom login to complete a device-code flow. This step is required before collecting payouts.
- Check status: darkbloom status shows settings, hardware, and trust status, while darkbloom doctor runs local diagnostics.
The configuration file is stored at ~/.config/darkbloom/provider.toml, where users can set their availability schedule.
There are also two advanced modes. With the X-Darkbloom-Route: self header, requests are routed only to a user’s own machine, free of charge and without forwarding to paid nodes. With darkbloom start --local, users can launch a local OpenAI-compatible endpoint directly on the Mac, skip the coordinator, reduce latency, and keep the setup available offline.
Can a provider really make $120 to $200 a month?
The estimate comes from an official X post, which suggests running the Gemma 4 26B model. The article says that figure only makes sense when read against three variables, and it is not a guaranteed payout.
On the revenue side, Darkbloom is taking 0% platform fees during its public alpha stage, with 100% of inference revenue going to the hardware owner. Earnings depend on duty cycle, the share of time a machine is available to take jobs. The default is 5%, but users can raise it to 100%. A higher duty cycle can mean more revenue, but it also means more electricity use and more sustained hardware load. Final payouts also depend on demand across the network, and the article notes that the team explicitly describes the revenue range as an estimate.
On the cost side, the main incremental expense is electricity because providers are typically using machines they already own. The article says a Mac under inference load may draw from tens of watts to over 100 watts. Using Taiwan power prices of about NT$3 to NT$4 per kilowatt-hour as the example in the source, electricity can take a noticeable bite out of revenue if a machine is left running at a high duty cycle for long periods. Heat and long-term wear are additional considerations.
The source frames the opportunity less as stable passive income and more as a way to monetize idle hardware.
Why Darkbloom says it can charge less
Darkbloom’s pricing pitch is that it avoids the cost of building data centers and buying dedicated GPUs by using spare consumer hardware instead. The article lists the following sample rates:
| Model | Input price per million tokens | Output price per million tokens | Relative to mainstream APIs |
|---|---|---|---|
| Gemma 4 26B (MoE) | $0.03 | $0.165 | About 50% cheaper |
| GPT-OSS 20B (MoE) | $0.015 | $0.07 | About 50% cheaper |
Both models support 128K context windows and use open-weight model architectures.
Payments are handled through Stripe. Users prepay into a microdollar ledger through Stripe, while providers are paid through Stripe Connect. Self-routed requests are free.
The article also notes that Darkbloom recently became a paid provider on OpenRouter after previously being available in the free tier, giving it access to a larger developer traffic channel.
Is it DePIN? Yes in concept, but without a token
Conceptually, Darkbloom fits within the decentralized physical infrastructure network, or DePIN, category. Like io.net and Aethir, it relies on distributed, underused hardware to assemble a compute network.
But the project differs in a few important ways. Darkbloom does not issue a token and does not settle payments onchain. All payments are made in fiat through Stripe. It is built by Eigen Labs, the team behind EigenLayer, but the article says the official documentation does not tie the product to EigenLayer’s restaking mechanism.
At this stage, the project looks more like a DePIN application built by a crypto-native team that still uses a conventional payments stack. It is focused on Apple Silicon and private inference rather than general-purpose GPU training.
For potential providers, the article makes one point clearly: there is no token mining angle here, and no announced airdrop component. Revenue is paid as actual dollar-denominated inference income.
Risks: still in alpha and not security-audited
Darkbloom’s open-source materials state that the project is still under active development, has not undergone a security audit, is not ready for production deployment, and is intended for testing use.
That leaves room for unknown vulnerabilities. The revenue model and fee schedule may still change, and overall demand remains early. The article lists several other issues users should weigh before joining:
- The effect of sustained high-load operation on electricity costs and hardware lifespan.
- Whether earning income by renting out compute could create tax or regulatory obligations in a user’s jurisdiction.
- The security trade-offs of keeping a higher-privilege service running persistently on a personal computer.
The source’s practical advice is to test the network with spare, non-critical machines rather than treat it as a dependable income source.
Key questions covered in the article
Who built Darkbloom, and how is it tied to EigenLayer?
Darkbloom was developed by Eigen Labs, the team behind EigenLayer. The source says it is not currently bound to EigenLayer’s restaking system and remains a relatively independent project.
Does it only support Apple Silicon? What about Intel Macs?
Only Apple Silicon devices, starting from M1, are supported. Intel Macs cannot join. For the models currently in use, the practical recommendation is 48GB or more of unified memory.
Can providers see user data?
Darkbloom says they cannot. Requests are end-to-end encrypted, inference runs in-process, and memory reads are blocked. The stated goal is that neither the provider nor the coordinator can access readable request contents.
Is the $120 to $200 monthly income stable?
No guarantee is given. The figure is an estimate from the team and depends on duty cycle, machine specs, network demand, and electricity costs.
Will there be a token or an airdrop?
Not at this point. The article says payouts are made in dollars through Stripe, and no token or airdrop plan has been announced.

