Reading cluster profit per hour

At a glance

A cluster profit estimate needs an expected item value, craft cost, base cost, throughput and divine exchange rate. Downtime and other overhead determine how an active-crafting estimate translates into an elapsed-hour scenario.

This guide's worked example uses an Allflame trade snapshot from 30 August 2026 and undated checked-in material cost settings. The current calculator was run offline on 20 October 2026 with those frozen inputs. It produces about 81.49 div per elapsed hour with an assumed 20% downtime. This historical scenario establishes arithmetic and model behavior. A current return requires current inputs and measured outcomes.

Download the exact example inputs and calculator outputs with sensitivity results to inspect every value used below.

Read the quantities separately

The model's revenue starts from listing observations and any catalog estimates. An asking price is evidence of supply at that price. It provides no sale receipt or guarantee that all crafted stock clears.

The app can discount and round a price when preparing a listing. The calculator's accepted-item value uses the catalog outcome model. Actual listings, discounts, sale delays and unsold stock need their own records.

The formula

Use chaos as the working unit, then divide by the chaos price of one Divine Orb:

profit per item = expected item value - craft cost - base cost
active items/hour = 3,600 / modeled seconds per accepted item
elapsed items/hour = active items/hour * (1 - additional downtime fraction)
div/hour = (profit per item * elapsed items/hour - extra chaos overhead/hour)
           / chaos per divine

The calculator's displayed Profit / hour uses its modeled active duration. The extra downtime adjustment in this guide is a separate scenario. Add only time beyond the handling already included in the calculator, or you will count the same delay twice.

Historical example: Medium Damage Over Time

The evidence fixture contains one cluster's 45 catalog combinations, the base price and exact material settings. It retains pricing provenance fields and removes trade URLs and unrelated scan bookkeeping. It contains no seller identities or private app data.

The material settings have no acquisition date. Combining them with the dated trade snapshot creates a historical teaching scenario with mixed input provenance. It does not reconstruct a verified trading session from that date.

What the calculator returned

The four rows are the current calculator's outputs under one fixed snapshot. Missing finite cost or profit values mean that row cannot support a profit comparison. Displayed numbers are rounded, so subtracting rounded cells can differ by 0.01c from the reported profit.

Harvest's 409.52c is a weighted average across accepted outcomes. It is not an instruction to list every jewel for 409.52c. For context, the input catalog values Flow of Life + Student of Decay at 30c, Flow of Life + Wasting Affliction at 100c, Brush with Death + Wasting Affliction at 690.6c, and Brush with Death + Flow of Life at 1,151c. The acceptance rules, outcome probabilities and price preparation determine the resulting average.

From crafts to throughput

The selected result expects about 88.51 reforges per accepted item. Its reconstructed duration is:

88.51 reforges * 0.285 seconds = 25.22535 seconds
shared item setup             = 14.00000 seconds
listing allowance             =  2.24000 seconds
total                         = 41.46535 seconds/item
active throughput             = 3,600 / 41.46535
                              = 86.819477 items/hour

This example reports no additional continuation exalt or annul usage. Other results can include those costs and times. The craft count exposed by the calculator is rounded; the reconstructed duration and its rate can therefore differ slightly from the calculator's internally computed rate.

The time model uses 0.250 seconds per Magic Roll or Rare Roll orb application, 0.285 seconds per Harvest reforge, and 2.200 seconds per fossil resonator use. It adds 14 seconds of shared setup and 2.240 seconds for listing per accepted item. Harvest or fossil continuation adds modeled exalt and annul time when forecast. These constants are based on older workflow measurements and assumptions; they are not a measurement of the reader's machine or layout.

From throughput to the hourly scenario

profit/item = 409.52c - 138.42c - 1c = 270.10c

calculator active rate = 23,450.56c/hour / 230.2c/div
                       = about 101.87 div/hour

elapsed throughput = 86.819477 * 0.80 = 69.455582 items/hour
elapsed scenario = (270.10c * 69.455582 - 0c) / 230.2c/div
                 = about 81.49 div/hour

Here, 20% downtime means twelve minutes outside modeled activity in an elapsed hour. It is an explicit assumption. Base restocking, trade failures, inventory management, gold acquisition, interruptions and unsold inventory can create different results. Gold and the time needed to obtain it have no chaos conversion in this calculation.

Sensitivity: change one input by 20%

The table holds the selected method, accepted outcome mix, divine rate, base cost and 20% downtime fixed. Each row changes only its named input.

A 20% price decline reduces expected item value by 81.904c per item while costs stay fixed in this arithmetic. Profit therefore falls by more than 20%. That is why an attractive hourly figure can be sensitive to asking prices.

This is a fixed-policy sensitivity check. In the app, changed prices can alter which combinations pass the threshold, which continuation actions win and which method leads. Refresh inputs and rerun the calculator to evaluate those decisions. Additional downside from weak demand or unsold stock remains outside this table.

Live price check on and off

With Live price check enabled, a qualifying candidate can be checked even when finished items go to a dump stash. A successful check updates the active catalog and can change the item's keep decision. With it off, a dump-only run relies on catalog values. A listing path can still perform its own live confirmation.

The effect has two parts: a new price can change expected item value, and requests add time. The calculator does not publish a separate throughput forecast for the toggle. If extra checks reduce measured active throughput by 20%, the fixed-price arithmetic in this example moves from 81.49 to 65.20 div per elapsed hour. That row illustrates a time change; it does not measure a live-check penalty.

A check returning no usable price, or an unavailable trade service, can fall back to the catalog. Use the resolved price and fallback messages in the run log to establish which price a decision used. A refreshed asking price still needs a completed sale before it becomes realized revenue.

Reproduce and replace the inputs

In the app

1. Open AI Cluster, Plan, then Trade Scan. Select the intended league and inspect the active snapshot. Refresh the scan when a current decision needs new prices.
2. In Best Method, set the chaos threshold and choose Profit / hour under Optimize for. Use Run calculation. Compare the four methods in the expanded result.
3. Record the selected method, named reforge or fossils, expected value, craft cost, base cost, divine rate and hourly result. Keep the input timestamp with them.
4. In Run, record quantities, destination, Live price check and Exalt 4th mod. A different destination or filler option changes the workflow represented by a timing comparison.
5. Measure a small batch's total elapsed time and actual material and base spending. Keep listed values and completed sale receipts in separate columns. Use those records to replace the example's timing and price assumptions.

Current app prices will differ from this historical fixture. Read Cluster crafting: how the planner chooses for the threshold, method and continuation rules.

Audit the frozen example

The downloadable input JSON contains the exact single-cluster trade evidence and material prices. The output JSON contains the selected result, all four method metrics, reconstructed durations and every sensitivity row. A reader can reproduce the formula directly from selected and sensitivity in those files.

Maintainers with the source checkout can run:

node scripts/guide-cluster-metrics.js --audit-only
node scripts/guide-cluster-metrics.js

The first command verifies stored arithmetic. The second checks source hashes, runs the exact calculator against the frozen local inputs and compares its results with the saved evidence. It makes no network requests. Temporary calculator files are removed after the result is checked; the local calculator log is retained. A source-hash failure means the captured code or data changed and the example needs a deliberate review.

Source notes

The evidence includes SHA-256 hashes for the input data and calculator sources used on 20 October 2026. Maintainer references:

For the app and licenses, join the official Discord and DM PathOfRolling. Check the name carefully and keep keys private.