backend/app/services/pricing/supply_demand.py and partly post-launch work. Where a dashboard surface doesn't exist yet, this chapter says so.
Reading the marketplace: when demand is high
A device owner doesn't set prices. The marketplace does. Your earnings are a function of:
- Your supply — how many capability-hours your fleet offers.
- The platform's demand — how many job-hours B2B customers are buying.
Hero-user operators read demand. They schedule heavy maintenance and reboots during low-demand windows, and they keep their highest-earning devices online during the spikes.
What is exposed today
[VERIFY: device-owner-facing demand dashboard — the backend service at backend/app/services/pricing/supply_demand.py computes supply/demand ratios; the B2B customer view shows pricing signals. A device-owner-side "demand explorer" is on the post-launch roadmap.]
At launch you will have:
- Per-device fill-rate history — what percentage of your available hours actually ran a job. Already in the dashboard at Devices → [device] → Earnings.
- Per-capability-tier marketplace status — high / normal / low demand bands, refreshed hourly. UI surface pending.
- Regional demand markers — green/amber/red by macro-region. UI surface pending.
What you will not have at launch:
- A real-time price feed (we keep the per-device-hour rate stable at $0.08 for Pro customers, verified in
backend/app/services/pricing_engine.py; device-owner payouts are smoothed, not spot-priced). - Per-job-type demand breakdown beyond the broad GPU/CPU/RAM-heavy tiers.
We expect more surfaces in the 6 months after launch as data accumulates.
The supply/demand framing
When B2B customers buy more compute than the fleet supplies:
- Fill rates rise.
- Job-dispatch latency drops.
- Capability-tier mix shifts — higher tiers fill first.
When supply exceeds demand:
- Fill rates drop. A 24-hour-available device might earn only 6 hours.
- Higher-tier devices still fill first; consumer-tier devices may sit idle.
- Your dashboard will say "low demand" but your device is still working when it can.
This is normal. It is also why earnings vary month to month and why anyone promising "guaranteed earnings" is selling something untrue.
Historical hourly fill rate
The first signal you should look at. Your fill rate per hour-of-day, averaged over the last 30 days. Patterns that show up consistently:
- Weekday business hours (09:00-18:00 local) in each major region tend to fill highest for general CPU jobs.
- Overnight (22:00-06:00 local) fills best for batch GPU jobs and rendering — customers schedule overnight runs.
- Weekend afternoons are unpredictable; lots of ML hobbyist activity globally.
Read your fleet's curve. Schedule maintenance into the trough.
Geographic demand patterns
- US-East / EU-Central carry the bulk of B2B traffic, usually amber-to-green.
- APAC demand concentrated in business hours UTC+8 (Singapore, Hong Kong, Tokyo).
- South America / Africa are emerging; demand grows but currently lower than developed regions.
Low-demand regions can still earn — jobs route by capability and latency tolerance, not strictly by region — but expect a slightly lower fill rate. [VERIFY: latency-tolerance routing rules in placement/scorers.py.]
Capability-tier demand mix
- GPU prosumer (RTX 4090 / A4000 etc.) — consistently highest-demand tier. ML training and inference jobs land here.
- High-core CPU (16+ cores) — strong demand for batch processing, data crunching, CI builds.
- RAM-heavy (64GB+) general devices — solid demand for large-dataset jobs.
- Mid-tier consumer (8-16 GB RAM, 6-8 cores, no GPU) — variable. Often fallback dispatch.
- Low-end consumer — limited use, mostly very small jobs or community-tier offerings.
If you're planning a hardware purchase, the prosumer GPU tier has the most consistent demand right now. That may change.
Seasonal patterns
Conference and model-release cycles
ML conferences (NeurIPS, ICML, CVPR) cluster compute demand in the weeks before submission deadlines and again right after major model releases. December and June are routinely busier than they "should be" by calendar logic.
Quarter-end batch processing
Enterprise customers run reports, render decks, and crunch year-end data in the last two weeks of each fiscal quarter. March, June, September, December tend to have a 5-10 day demand spike.
Holiday troughs
Late December / first week of January is a global trough. So is European August. So is the week around Lunar New Year for APAC. Plan maintenance windows for these.
Tax-season and rendering crunch
March-April for US tax season — accounting and audit firms run heavy batch jobs. Late October / early November for film/VFX rendering runs leading into release seasons.
[VERIFY: above patterns are common-knowledge from the broader cloud-compute market; Zyra's launch-fleet data will tell us which actually apply. We'll publish a "marketplace report" annually once we have data to base it on.]
What you should actually do with this
- Schedule maintenance into the demand trough. OS updates, hardware swaps, BIOS flashes — into the lowest-demand window for your region.
- Keep highest-tier devices online during spikes. Don't take your RTX 4090 offline for a "quick reboot" during a Tuesday 14:00 EST window if your data shows that's a peak hour.
- Don't overreact to a slow week. If demand drops platform-wide, every operator's earnings drop — it's not you. Avoid panic-reconfiguring the fleet.
Honest disclaimer
Marketplace demand is the variable we control least. We can build the matching engine, set the price-per-device-hour ($0.08, verified in pricing_engine.py), recruit B2B customers, and publish demand signals — but on any given Tuesday the actual jobs are what customers actually buy. Your earnings will fluctuate week-to-week. The yearly average is what matters; the weekly noise is noise.
Cross-links
- Stage 3 chapter 2: Maximize your earnings — dashboard-level optimization basics
- Stage 4 chapter 2: Advanced earnings strategies — capability-tier targeting, time-zone arbitrage
- Stage 4 chapter 6: Running a Zyra business — treating variable revenue as a real business
What's next
4. Privacy and security on your machine →
Last reviewed: 2026-05-21