Sphere Upgrades Calculator

Optimal upgrade ordering to maximize sphere/day · paste $bonus, $shop, $mmsz=z!
Mode:
Paste your $bonus output
Run $bonus in Mudae, copy the reply, paste it here.
A few other details
Sets $dk uses/day, daily $oc/$oq, extra rolls, extra spheres
Base character pool size
How to find pool size
Standard ($wa/$ha/$wg/$hg)
$limroul
1. Run $left — note the total roulette size.
2. Run $dld or $dl — note how many are disabled.
3. Run $adl — note antidisabled count.
4. Enter: (total from $left) − (disabled) + (antidisabled)
1. Run $limroul — note the value.
2. Find antidisabled for your roulette type:
$wa → $adltwg-   $ha → $adlthg-
$wg → $adltwg   $hg → $adlthg
3. The number in parentheses at the top is antidisabled size.
4. Enter: (limroul) + (antidisabled)
Characters currently on your wishlist
If you know how many you've claimed (from $left), enter it here — overrides the dropdown.
Your upgrades ranking
How to use this calculator
1
Run $bonus in Discord and paste the bot reply into the left box. This auto-fills your roll rate, wish bonus, double chance, flat bonus, max power, and react cost.
2
Run $shop and paste into the middle box. This auto-fills your SP1/SP2/SP5/SP9/SP10 levels.
3
Run $mmsz=z! and paste into the right box. This auto-fills your OP1/OP2/OP5/OP9/OP10 character counts and fully-upgraded count.
4
Fill in Pool size, Wishlist max, Wishlist used, and Claim rate % under Manual inputs, then click Calculate.
Tip: Both copy methods work — select the message text and copy (Ctrl+C), or right-click the Discord message → Copy Text. Extra lines (timestamps, username) are ignored.

1. Inputs

From $bonus
Bonus rolls from $bonus (after $bw/$bk deductions)
Spawn bonus for wishes from $bonus
Chance to get twice the sphere value
Additional spheres per click
Kakera max power from $bonus
Power cost per kakera button (net)
From $shop
Character counts (from $mmsz=z!)
Chars with OP5 lv4 + OP8 (not yet lv6)
Chars with OP5 lv6 AND OP8
Chars with all 10 perks maxed (for SP10)
Base character pool size
Number of claimed characters in your roulette. Toggle to Rate % to enter the claimed fraction directly. Estimate from $left.
Total wishlist slot capacity (auto-filled from $bonus)
Characters currently on your wishlist. Free = max − used.
Base rolls set by server admin via $setrolls
Sets $dk uses/day, daily $oc/$oq, extra rolls, extra spheres
How to find pool size
Standard ($wa/$ha/$wg/$hg)
$limroul
1. Run $left — note the total roulette size.
2. Run $dld or $dl — note how many are disabled.
3. Run $adl — note antidisabled count.
4. Enter: (total from $left) − (disabled) + (antidisabled)
1. Run $limroul — note the value.
2. Find antidisabled for your roulette type:
$wa → $adltwg-   $ha → $adlthg-
$wg → $adltwg   $hg → $adlthg
3. The number in parentheses at the top is antidisabled size.
4. Enter: (limroul) + (antidisabled)

2. Review Current Stats

Fill out inputs to review current stats

3. Calculate

Override the computed OP9 sphere button spawns/day (op9 chars × p_roll). Empty = use rolls + wishlist model.
Override power-based react budget for OP5+OP8 clicks. Empty = use max_power + $dk model.
How many days of results to display.
Assumes that account stats do not change, so be careful of long time horizons
Check this to compute the upgrade ordering.
Save inputs and steps

Save your inputs, paste texts, and computed upgrade plan so you can pick up where you left off on any device. Mark steps as done to track your progress.

How it works
1 Income sources where your sp/day comes from

The model treats your sphere income as the sum of a few independent sources — daily minigames ($oh, $oc, $oq), OP9 sphere buttons, OP5+OP8 kakera buttons, SP2 megaspheres, OP10 passive income, SP5 $ot procs, and SP10 $ot procs — each boosted by specific upgrades. It adds them up, then searches for the upgrade order that maximizes your long-term discounted income.

Total sp/day sp/day = base_daily
         + OP9_sp + OP5_OP8_sp
         + OP10_sp + SP2_sp
         + SP5_sp + SP10_sp

← base_daily = 4×$oh + PP×$oc + PP×$oq
1.1 OP9 sphere buttons EV of one OP9 click

Each OP9 character is modeled as spawning one button per day, multiplied by the probability of rolling at least one wish that day. (If you can roll all your wishes each day, use the checkbox in simple mode to bypass this.) The click cap is 10 + SP9 level/day, shared across all OP9 chars.

The model applies your double chance, flat bonus, and SP9 (+10%/level) to each color's base value. When spawns exceed the cap, a dynamic program picks which colors to click — see the perk-9 calculator for details. OP9 clicks can also give an extra $oq.

Expected value per click EV(color) = (base × (1 + double_chance) + flat_bonus)
                 × (1 + SP9_level × 0.10)

EV(click) = Σ freq(color) × EV(color)

OP9 sp/day
spawns/day = OP9_chars × P(≥1 wish today)
click_budget = 10 + SP9_level

V(r, c) = Σ freq(color) × max[EV(color) + V(r1, c1), V(r1, c)]
V(0, c) = V(r, 0) = 0
OP9_sp/day = V(spawns, click_budget)

OP9_oq = expected_clicks × P($oq proc) × EV($oq)
1.2 OP5+OP8 kakera clicks power-limited react budget

The model assumes every OP5+OP8 character spawns 4 kakera buttons/day, limited only by react power. OP8 halves the cost for the first 40 clicks/day (soulmate halves again). The budget is max_power × (1 + num_dk), where num_dk depends on premium (PP0=1, PP1/PP2=2, PP3=3).

Clicks 1–40 cost react_cost/4 with OP5 at face value; 41+ cost react_cost/2 but OP5 is doubled. Lv6 chars are clicked first (19 vs 12 sp/click). Non-soulmate chars aren't modeled.

OP5+OP8 sp/day total_power = max_power × (1 + num_dk)
← num_dk = [1, 2, 2, 3] by player premium

pre = min(40, ...) ← react_cost/4 each, OP5 not doubled
post = ... ← react_cost/2 each, OP5 ×2

OP5_OP8_sp = pre×12or19 + post×12or19×2
            + clicks × pp3_bonus
1.3 SP5 $ot procs extra $ot from OP5 clicks

SP5 gives a chance for each sphere earned from an OP5 click to give an extra $ot. The chance is 0.014% per SP5 level per sphere — so a character giving 19 sp/click at SP5 lv3 has 19 × 0.042% = 0.798% chance of $ot per react. The model applies this across all OP5 clicks, weighted by the sp/click in each pre/post tier.

SP5 sp/day
SP5_chance = SP5_level × 0.00014 ← per sphere per click
SP5_sp = Σ clicks × SP5_chance × sp_per_click × EV($ot)
← sp_per_click = 12 (lv4) or 19 (lv6), per tier
← EV($ot) = 834.65 × (1 + d) + 21 × f
1.4 SP2 megaspheres bonus spheres from claimed rolls

SP2 gives megaspheres — bonus spheres triggered by rolling claimed characters. Each claimed roll has a 1/50 chance of spawning one; the more claimed rolls/day, the likelier you are to spawn at least one (capped at 5/day via chaining). Each megasphere can chain up to 5 times, and OP2 increases the free-chain chance (every 100 OP2 lv5+ chars guarantees one free continuation).

Each megasphere contains 3 × SP2 level component spheres. Most are regular colors (not affected by double chance/flat bonus); a small fraction give special rewards ($oh/$oc/$oq/$ot) that do.

SP2 sp/day
p_spawn = 1 (49/50)claimed_rolls/day
free(k) = clamp((OP2_chars 100×(k1)) / 100, 0, 1)
E[mg/day] = Σk=1..5 p_spawnk × Π free(j)
SP2_sp = E[mg/day] × 3 × SP2_level × EV(component)
← EV(component) = regular colors + uFreq × special reward EV
1.5 OP10 passive income per-character tiered income

OP10 gives passive sphere income per character, tiered by how many OP10 chars you have. The model uses a decreasing marginal rate: first 100 chars give 20 sp/day each, next 100 give 8, next 100 give 4, and beyond 300 give 2 each. OP10 also gives a chance at bonus $oq minigames, modeled with the same tiered percentage.

OP10 sp/day
sp = min(n,100)×20 + min(n100,100)×8
    + min(n200,100)×4 + min(n300,200)×2 + max(n500,0)×2

OP10_oq = oq_pct × EV($oq)
← oq_pct = min(n,100)×1.0 + min(n−100,400)×0.5 (as %)
1.6 Base daily minigames $oh, $oc, $oq

The model includes a fixed daily income from minigames: 4× $oh per day, plus $oc and $oq counts that depend on player premium. Each minigame's EV is its base reward scaled by your double chance, plus a flat bonus per click. These aren't upgradeable but contribute to your total rate.

Base daily sp
base = 4 × EV($oh) + PP × EV($oc) + PP × EV($oq)
EV(reward) = base × (1 + double_chance) + clicks × flat_bonus
← PP = [1, 2, 2, 2] for $oc, [0, 0, 1, 1] for $oq by premium
1.7 SP10 $ot procs once-daily on first $oh

SP10 gives a once-daily chance to give an extra $ot on your first $oh of the day. The chance is 0.25% per SP10 level per fully-upgraded character (capped at 120 chars). Each proc is worth the $ot special reward EV.

SP10 sp/day
SP10_sp = SP10_level × 0.0025 × min(fully_upgraded, 120) × EV($ot)
← EV($ot) = 834.65 × (1 + d) + 21 × f
← once per day, on first $oh
2 The time problem why a discounted objective

A naive greedy optimizer picks the most efficient upgrade (Δrate/cost) at each step, but ignores how long you have to save to afford that upgrade. A slightly less efficient but cheaper upgrade you can buy now and start earning from immediately can beat a more efficient but expensive upgrade that requires days of saving, during which you earn nothing extra.

The optimizer fixes this by using a discounted infinite-horizon valuation to account for spheres now being more useful than spheres later, and optimizes an ordering of upgrades based on the total income earned along the way plus a measure of the final sp/day reached. This way upgrades that require long waits are properly compared while still valuing total efficiency.

Discounted income objective V = Σ rate_i × (eδ·t_i eδ·t_{i+1})/δ
    + final_rate × eδ·t_end/δ

δ = 1 / discount_days ← default 365

← near-term income counts more than far-future
← perpetuity keeps the long-run rate relevant
3 The synergy problem why a DP, not just greedy

A naive greedy optimizer only considers each upgrade's value in isolation, but some upgrades synergize with each other to be worth much more together: SP9 is worthless without any OP9 characters, OP2 is worthless without SP2. A greedy optimizer might delay something for a long time when it'd be better to take the small hit and unlock two things together.

The optimizer fixes this by considering all orderings within each set of related upgrades, and then interleaves those orderings together for the full upgrade ordering, using dynamic programming to find the exact best orderings. (For full details or ideas on how to do better ping me, this got more complicated than I'd like)

Greedy (ROI) — the fast fallback each step: argmax Δrate_i / cost_i
← instant, but evaluates upgrades in isolation

Optimize (cost-DP) — handles synergies exact Bellman DP per coupled cluster
  + rolling-window merge
← OP9+SP9, OP2+SP2, OP5+OP8 evaluated jointly