Advanced earnings strategies
Stage 3 chapter 2 covered the basics — keep the device online, set a good schedule, opt into GPU jobs if you have one. This chapter is the next layer: deliberate specialization, network-aware tuning, and time-zone tactics. Returns are marginal. If you haven't already maxed out the basics, do those first.
Time: Ongoing — these are habits, not a one-time setup. Prerequisites: Stage 3 chapter 2 already implemented.
Honest framing
Pro/Business jobs settle at $0.08 per device-hour at the platform level. The device owner share of that — and any GPU/capability multiplier on top — is set by the platform fee schedule, not by you. Optimization shifts you a few percent at best. Track your actual numbers before and after every change so you know what worked.
GPU specialization
If you have a GPU and you've opted in (Stage 2 chapter 6), you're already getting routed GPU-eligible jobs. To specialize further:
- Cap CPU-only job acceptance. Reserve the device for GPU work. Fewer jobs, but each one earns more. Trade-off: idle gaps between GPU jobs when demand dips.
[VERIFY: GPU-only filter at device level — capability filter UI shape TBD; backend supports task-type routing via supported_task_types] - Keep drivers current. A stale CUDA/Metal driver silently drops your capability score and you lose jobs without knowing why.
- Sustained thermal headroom matters more than peak. Stage 3 chapter 4 covered why.
Bandwidth-optimization
Many ML and data-processing jobs are network-bound: pulling a model checkpoint, uploading a result. If your upload is constrained:
- Run a sustained upload test (
iperf3to a known server) and record peak vs sustained. - If sustained upload < 25 Mbps, expect to lose network-heavy jobs to faster-uplink devices.
- Wired ethernet beats wifi on consistency, which the scheduler rewards.
Time-zone arbitrage
Demand is not flat across 24 hours. Organization customers tend to run jobs during their working day. A device in Helsinki idles less if it offers wide hours covering US daytime; a US device that runs overnight catches the EU morning load.
Practical setup: split your fleet schedules so devices in the same physical location stagger their availability windows, smoothing the household power draw and catching demand peaks in multiple zones.
[VERIFY: time-zone demand-pattern data — internal data exists, public demand heatmap not shipped yet]
Capability-tier targeting
A high-end device can specialize for ML; a mid-range device is better as a general-purpose worker. Forcing a mid-range CPU to compete for ML inference jobs gets you stuck in the long tail of the queue.
| Device profile | Best target |
|---|---|
| 16+ cores, 32+ GB RAM, recent GPU | ML inference, batch training |
| 8 cores, 16 GB RAM, no GPU | General compute, data processing |
| 4 cores, 8 GB RAM | Light tasks, build agents, test runners |
Match your supported_task_types and capability score to the realistic tier.
Diminishing returns
After GPU opt-in, a clean schedule, current drivers, and wired ethernet, further gains are 1-3 percent each. Track actual earnings for two weeks before and after a change. If the delta is inside the natural week-to-week noise, the change didn't help — revert.
Troubleshooting
- Earnings dropped after a "tuning" change. Revert and wait a full week before judging. Day-to-day noise is real.
- GPU device underperforming. Check driver version, thermal headroom, and that GPU opt-in is still on after the last agent update.
What's next
Last reviewed: 2026-05-21