Start with the published share
Use the approved rental price and provider percentage shown for your node in Compute. The September 11 default snapshot is 55% platform and 45% provider, but admin can approve node-specific terms. The calculator starts with $249 and 45% as an editable example. One paid 30-day term at those example terms accrues $112.05 before operating costs, adjustments and taxes. Neither input is a guaranteed offer. Dated pricing facts
On September 11, 2026, the public fleet API reported zero nodes and the marketplace returned no listings. We have no observed paid occupancy or payout history from those endpoints. A forecast that quietly assumes continuous rentals would therefore be unsupported. Fleet statistics, machine listings
What the calculator means by occupancy
Occupancy represents the share of time rented across several 30-day periods. For example, 50% could mean one full period rented and one period without a renter. It is not a statement that customers can buy half a month, or that the platform prorates a rental by the day.
At zero occupancy, rental revenue is zero. A powered machine can still consume electricity. Enter an average wall-power measurement that includes the conditions you expect, such as loaded and idle hours. If you power down between rentals, adjust the average accordingly.
actual rental accrual = accepted price × paid terms × approved share fraction
estimated share per 30 days = assumed price × approved share fraction × occupancy fraction
electricity = average watts / 1,000 × 720 hours × price per kWh
estimated operating result = estimated share − electricity − other costs
The 720 hours represent exactly 30 days. The result is before taxes and before any costs you have not entered. Occupancy prorating is a planning estimate, not billing or ledger logic. If accepted terms differ between rentals, calculate each term separately and sum its accrual. Confirm your approved terms in the dashboard.
Include costs that are easy to miss
If you already own the Mac, distinguish cash spending from the value of keeping it available for other work. A machine you need during the day may be a poor fit for a dedicated rental, even if its electricity bill is low.
If you are considering buying hardware, include depreciation or financing and the risk that demand does not arrive. Also consider incremental connectivity, maintenance and time spent handling interruptions. Put a 30-day allowance for those costs in the calculator instead of treating the electricity figure as the entire expense.
Use scenarios before expanding
The calculator shows zero, 25%, 50% and full occupancy so the dependence on demand remains visible. These scenarios are assumptions, not a probability forecast. A break-even occupancy above 100% means the entered price and costs cannot break even under this model.
Measure one existing machine first. Record when it is listed, when it is rented, actual power use, credits received and any downtime. Several completed rental periods are more useful for expansion decisions than a single successful install.
Measure loaded and idle electricity separately
If the Mac stays online between requests, measure both serving and idle power at the wall. Multiply each measurement by the hours spent in that state. A power-adapter rating is not the machine's average consumption.
For a hypothetical 30-day period with 240 hours at 70 watts and 480 hours at 20 watts, energy use is 26.4 kWh. At an assumed $0.20 per kWh, that is $5.28. The equivalent average is about 36.7 watts for the calculator. These inputs are examples, not measurements of a Mac model or an electricity tariff.
This gives a more useful input than assuming the machine draws full-load power for every hour. Add network equipment only when its cost belongs to this activity, and explain the allocation you use.
Reconcile earned revenue with available payout balance
A farmer account is required to supply the machine. Use its Compute dashboard for listing state, Earnings for income and Payouts for payout requests. An estimated share is not cleared cash in your bank or wallet. Successful paid rentals accrue the agreed share; free test allocations earn nothing. Accrual, settlement and completed payout are separate states. The September 11 snapshot reports automatic peer settlement in shadow mode, with admin settlement and payout review required. This operational setting can change; check the current dashboard. Existing peer earnings ledger rows already represent the net farmer share, so do not deduct the platform percentage again. Settlement facts, earnings reference
Keep a record of each rental period, adjustments, amounts credited and completed payouts before estimating future returns. Confirm current payout conditions in the portal. This review has no completed payout record and does not assume a payout speed, minimum or fee. The published revenue-share basis is in the provider documentation.
Keep compute and bandwidth earnings separate
Compute rents inference capacity. The Peer Network pays for routed bandwidth under its own terms. The provider documentation says compute nodes are excluded from proxy routing, so do not add a second bandwidth income assumption to a compute forecast without a separately supported arrangement.
When the costs look acceptable, follow the provider setup guide. Confirm the machine can serve a catalog model before listing it.
Sources and references
Reviewed September 11, 2026. Product statements come from public APIs, provider documentation and published application code. Technical references explain the evaluation methods. Authenticated rental and payout behavior has not been tested.
- Dated compute product facts. PROXIES.SX.
- Compute operation and pricing reference. PROXIES.SX.
- Compute provider documentation. PROXIES.SX.
- Marketplace inventory API. PROXIES.SX.
- Compute fleet statistics API. PROXIES.SX.