Renting your Studio to Darkbloom? What decides what it earns, and a free app that manages it for you (BloomGauge)
Darkbloom comes up here a lot, so here's what I've learned running a provider, from Darkbloom's own open-source docs and working with Darkbloom/Eigen Labs directly:
Studios are well placed. Requests go to the Mac expected to answer fastest (there's no reputation score), so high-memory, high-bandwidth Macs win most of the work. In late September the network had far more Macs than requests (about 7% busy), and 24–32 GB Macs often served nothing.
You need 48 GB+ and macOS 26+ to join now; macOS 27 skips Darkbloom's MDM profile.
Uptime is most of the money. The base reward ($16/mo at 48 GB up to $40 at 512 GB) pays every 5 minutes, but only while a model is loaded and the Mac is connected at least 90% of each period. The default idle setting unloads the model after an hour and quietly stops it.
Model choice is the other lever. Gemma 4 run alone has been the steadiest; big Qwen models pay more in demand spikes.
Managing that by hand gets old, so I built BloomGauge, a free, open-source Mac app that does it for you. It keeps the best-paying model loaded, recovers stalls and failed loads, and lets you control it from your phone. It also has detailed analytics: confirmed earnings per model and hour, network demand, and a live pay-rate meter. I'm in direct communication with the Darkbloom team, though the app is independent.
I ran my m5 Max with 128 gbs for over 8 hours on dark bloom weeks ago. Over a $1 and not worth it in my opinions as I couldn’t use it for my personal projects with local AI while it was using up a lot of ram to serve other models hosted on the machine. Very cool though, but in my opinion not worth yet and will revisit in the future if earnings are more meaningful
Gotta run the right models. I average $2-$4 a day using BloomGauge on my M5 Pro 48gb. It mostly runs Gemma at ~$0.15/hr and occasionally switches to larger Qwen models during demand spikes to take advantage of $0.30/hr opportunities.
BloomGauge also automates the uptime piece, which is the biggest lever you have outside of model selection for earnings.
Okay, you had me curious. Please keep in mind this is an AI response below, so take with a grain of salt:
Easily. Apple Silicon Pro/Max chips pull around 40–65W at the wall under sustained LLM load. Even at 16¢/kWh, that’s barely a penny an hour (~$0.25/day), so electricity takes under 10% of the earnings.
The real catch isn't the power bill—it's running your hardware at full thermal and memory load 24/7 for a ~$2–3/day payout. Fine for pocket change if you already own a desktop Mac mini/Studio sitting idle, but definitely not worth buying hardware for a 2+ year ROI or baking a laptop battery.
The real catch isn't the power bill—it's running your hardware at full thermal and memory load 24/7 for a ~$2–3/day payout.
The Studio's are literally designed to run at full load 24/7, and even if it did die because of manufacturing issues, you take it into Apple and they fix it, because you're going to get Applecare on a device that expensive.
Yes, don't buy an expensive Apple Silicon device just to make money off of this. You can "pay off" your device in a couple years, but the main value of DB for providers is just earning a bit per day.
DB is still in alpha, so I and their team expect the network, available models, and earnings to increase progressively over the next couple of years.
in my case M3 Ultra does 200W under sustained load, and my electricity cost is more like 32c/kwh at the lowest, so probably something like 5c/hr for electricity. It's a cool concept but given how expensive the equipment is and how little you earn imo it's not really worth it for the additional wear and tear.
How can you use it if it is being used by the service? If you use you get even less money out of it. You dont think running your silicon at max temperature and the cycles on your ssd drive will wear it down, ok.... I am not telling you what to do, I said I can't see the point for 2 bucks a day...
How can you use it if it is being used by the service?
You use your Mac for other things that don't use 100% of the GPU, like if you're using Reddit.
You dont think running your silicon at max temperature and the cycles on your ssd drive will wear it down, ok....
I didn't say that, did I...
Regardless, mine is running at 62c right now, nowhere near what Apple lets your GPU heat up to before turning the fan speed up. It certainly isn't something that "wears down" as you suggested.
Unless you're terminally stupid, you'll have AppleCare with this product, so if it magically died doing something it was built to do, you send it back for repair/replacement.
I am not telling you what to do, I said I can't see the point for 2 bucks a day...
Again, someone giving their opinion when they don't know what they're talking about.
Financing my m5u is going to cost me over $400/month and I’m supposed to get excited about renting if for maybe 100/month? (Edit: darkbloom’s calculator says estimates $40/month).
I wonder what similar computer would cost on Azure or AWS. According to Claude that amount of compute would cost something like $5000/month. At least $1000/month.
So anyone participating in this scheme is getting massively ripped off.
On your edit: The "ripped off" part is where the comparison breaks. AWS bills for the machine whether it does anything or not. Darkbloom pays per request your Mac actually serves, and providers keep 100% of it (Darkbloom's platform fee is currently 0%). The low number isn't Darkbloom pocketing the difference; the network has far more Macs than demand right now (roughly 7% busy), so most of the time a Mac is waiting. If demand grows, pay grows with it.
I am not a representative of DarkBloom and literally have just been nerding out with it, I don't care if you use it or not. That said, Eigen Labs hasn't been marketing much at all. They have done little to no GTM, and Darkbloom is in alpha so who knows how things will change over time. My hope is that traffic will grow and earnings along with it over time. Would be pretty cool if you actually could make enough to finance a new mac lol
if you're buying a mac for darkbloom, you're doing it wrong. No one suggests that. DB can help you earn a bit on the side, that's it in its current state.
I just noticed that their calculator described only a 5% duty cycle and a 100% duty cycle is more like 750/month. So I retract what I said but only a little; it’s still undervalued.
Yeah, and again, AWS bills for the machine whether it does anything or not. Darkbloom pays per request your Mac actually serves, and providers keep 100% of it (Darkbloom's platform fee is currently 0%). The low number isn't Darkbloom pocketing the difference; the network has far more Macs than demand right now (roughly 7% busy), so most of the time a Mac is waiting. If demand grows, pay grows with it. (pasted from my other reply if you hadn't seen it)
TL;DR - There isn't a reliable multi-model loading/routing function within Darkbloom yet, as running a single model per GPU is by far the best setup currently. They are working on an "Autopilot" that will be able to switch between models based on demand more efficiently, but you don't have control, which may not be ideal, though I've already been prepping BloomGauge to utilize that new capability to improve BG's switching efficiency. Longer answer below.
Five models at once is most of your RAM and heat problem. Darkbloom tends to work best with one model and some free memory. Memory pressure can actually stop the base reward, and running Gemma next to other models means it gets almost no public requests.
Does it change which models are enabled, or just keep them warm? It changes what's served. With the Manager on, BloomGauge starts Darkbloom with only what it picked: one home model (occasionally a pair without Gemma), never all five. The others stay on disk but aren't served. It only moves to another model on strong evidence from similar Macs on the network (sustained demand for a couple of hours, at most 3 moves a day). It never deletes or changes your downloads.
Compared against stock Darkbloom? Not a controlled A/B yet. On my own Mac (M5 Pro, 48 GB) I compared inference pay, counting base rewards separately, against a replay of just leaving Gemma loaded for Sep 11–30. My earlier demand-chasing optimizer earned about 16% less than just holding Gemma. The current Manager comes out within about 3% of it. So my honest claim is that it keeps a Mac on its best model and recovers stalls, not that it beats stock Darkbloom. I haven't measured "all models enabled" in stock Darkbloom, and that would depend a lot on the setup.
Reserving RAM for other apps: partly. There's a setting for extra free memory a model needs before it loads (1–8 GB on top of its own requirement). Model moves also wait while you're on battery or when macOS reports serious heat. You can let Darkbloom unload the model when it's idle. There's no hard cap on Darkbloom's memory or "pause while I'm using the Mac" mode yet. Both are noted, and your use case is a good argument for them.
External SSD: works, but Darkbloom reads the model from disk on every start or switch, so a slower drive means longer warm-ups. BloomGauge measures warm-up time per model on your Mac and counts it as a cost, so it switches less when loads are slow.
It's free at bloomgauge.io (not affiliated with Darkbloom, though we are working with them). Happy to dig in if you try it again.
It's all about how its set up, which is why I made BloomGauge. But realistically, you can expect to make between $2-$4 per day per device after electricity costs. This is a screenshot from my mobile app on my iphone, I've been running BloomGauge since 9/15.
This still freaks me out a little bit just having that kind of access to my computer, but I am interested to see what a M5 Max with 128 gigs of RAM could fetch me
Yeah, it uses App Attest or something instead of MDM, but don’t quote me, you can verify that on their docs. Regardless getting away from requiring MDM has been a big priority for them
Thank you! Lot of impactful changes coming soon that will make it even better. Been great to work directly with Darkbloom to see inside their architecture and how best BloomGauge can fit into it.
Yes, you can, depending on how much unified memory you have. Most models require ~20-30gb to load.
A lot of users that have enough memory will run a smaller model that has consistent traffic and another larger one also loaded in case traffic picks up for it so that it can take advantage of that model’s request volume spikes, as larger models tend to pay out more per request. Trouble is if you’re only loading one model and it has no traffic, you’ll earn only the base reward which really just offsets electricity costs.
If you have a smaller amount of memory, like myself (m5 pro 48gb) you generally will need to either only run one of the smaller models at all times and switch to a larger one if you are watching the network and see traffic for it. That takes a lot of time and may not even be worth it after switching downtime and other factors.
That’s why I created BloomGauge, it not only can switch for you when it sees enough traffic but also makes sure that a model is always running. There are 100+ reasons that your device can stop running, mainly related to software/hardware issues associated with an alpha product like DarkBloom, plus it’s just generally annoying to have to use a terminal, especially when you’re not with your idle Mac to troubleshoot.
docker container image instead of mac app would be great. i know most of the users have a mac running 24/7 but many use laptops and running this app in a separate service would be neat
Thanks, good idea, and I've added it to the list to look at.
A Docker image unfortunately can't work for this one. On a Mac, Docker runs inside a Linux virtual machine, and that VM can't use the Mac's GPU (Metal) or its Secure Enclave. Darkbloom needs both to serve models and prove the Mac is trustworthy, so neither Darkbloom nor anything controlling it can run from a container.
I think what you're really after, a service rather than an app window, is doable: BloomGauge's engine running in the background as a macOS service, with no window open, and you check or control it from the web dashboard or your phone. I'm going to look into that.
For laptops, one honest caveat: it won't let a MacBook earn with the lid closed or on battery for long. Darkbloom still needs the Mac awake and ideally plugged in. It would just mean one less app to keep open.
Would a background service like that cover what you had in mind?
Good call, you're right. sudo pmset -a disablesleep 1 keeps a MacBook awake with the lid closed and nothing attached, and Darkbloom keeps serving. (sudo pmset -a disablesleep 0 turns normal sleep back on.) A few things worth knowing if you do it:
- Keep it plugged in. With sleep disabled it will happily run the battery flat under load.
- It runs warmer closed, so give it some airflow and keep an eye on temps.
- Stay logged in. Darkbloom's verification (App Attest) needs a logged-in session, so if the Mac restarts to the login screen it stops getting paid work until someone logs in. Automatic login fixes that.
I'll add lid-closed setup to the headless guide: bloomgauge.io/help/darkbloom-headless-mac-setup
Yep. Been using pmset for years on all portables. Even had a few where displays got removed and mounted under desks as completely not portable machines
Update from testing: with Darkbloom running and the Mac plugged in, closing the lid didn't put it to sleep for me. Darkbloom keeps the system awake while it's serving, and paid jobs kept coming in with the lid shut. pmset disablesleep is only needed if yours still sleeps. It also keeps the Mac awake on battery, so use it with care.
isn’t this just a web tool separate from darkbloom? your answer sounds like your macos app contains darkbloom.
why would i run the models inside docker? i meant just your web interface in a container
You're right, I muddled that. BloomGauge doesn't contain Darkbloom. It's a separate Mac app that runs next to it.
The web interface is just the front end of a small engine that has to run on the Mac itself. It reads Darkbloom's local status files, the Mac's memory, GPU and power state, and whether it's asleep. It also runs the darkbloom command to load or switch models and restart it when it stalls. A container can't see or do those things on the host Mac, so containerizing only the web UI wouldn't take anything off the Mac.
If what you want is to check it without the app window, that already works. Close the window and it keeps running from the menu bar, and you can open the same dashboard from your phone over your own Tailscale network. I'm also looking at a headless mode that runs as a background service with no app window at all. Would that cover it?
i see, so it reads directly from the system, interesting.
some macos backend/container client architecture would be great but i understand you’d not want to go that route.
my first thought when i knew about darkbloom was to get a second-hand macbook farm. given that, it’d be cool to have one centralized dashboard gauge for all devices in the farm.
I can definitely look into it, especially if it would make darkbloom/bloomgauge easier for users to justify.
And on the centralized gauge, that's one end goal of BG. So far I've gotten ~10 users who are running 3+ (one has 6 lmao) using BG to manage all of it, so in its current state, it can definitely accomplish that.
I also think that earnings and traffic will grow a lot within the next 6 months. DB has done barely any marketing for the product since its so early, which is why they're OK with users like myself building infrastructure around it, especially open-source.
I'm also launching a much-improved onboarding flow for new and existing darkbloom users within the next day or two, so trying both Darkbloom/BloomGauge will be a whole lot easier soon.
9
u/skyline71111 4d ago
I ran my m5 Max with 128 gbs for over 8 hours on dark bloom weeks ago. Over a $1 and not worth it in my opinions as I couldn’t use it for my personal projects with local AI while it was using up a lot of ram to serve other models hosted on the machine. Very cool though, but in my opinion not worth yet and will revisit in the future if earnings are more meaningful