← Back to index

Kakeraloot Calculator

Luck analysis and reward forecasts from your $lk display

How to use this calculator
1
Run $lk in Discord and copy the reply.
2
Paste the full display text into the box below.
3
Your luck percentile and forecast for the next N loots fill in automatically. Optionally enter a Desired +N per reward to see how many loots it'd take to get there.
Tip: Your submission also helps improve the calculator's predictions over time. Fill in the Submit for data analysis section with your guild ID and survey answers, then click Submit.
Inputs
Submit for data analysis
If you're the owner of a Mudae server that's willing to let me scrape message history for kakeraloots data, please contact colblitz in Discord!
Luck Analysis
Your counts vs similar user state; model estimates if not enough data. Not ranked: RT cooldown (capped) and rolls / kakera / mudapins (no cumulative count).
Reward Current Loots to get target
p5 Median p95 Mean P(≥1) Desired +N Est. loots
Important — accuracy & uncertainty
  • Forecasts are averages, not guarantees. Every loot is an independent random draw — your actual results will vary, sometimes a lot.
  • Mean vs Median: the mean (average) is often higher than the median (typical outcome) because a few lucky streaks pull it up. If mean > median, expect most loots to give less than the mean, with occasional big wins.
  • The p5–p95 range shows where your actual results will land about 90% of the time. About 1 in 10 times you'll fall outside it — usually above p95 on a lucky streak.
  • Forecasts far into the future (millions of loots) rely on a mathematical model and are less precise — the spread of estimates increases accordingly. Short-term forecasts are more reliable.
  • Forecasts beyond 12,000 loots assume you buy loots in batches of 12,000 (Mudae's max per purchase). This matters for stacked rolls: the rate tier is locked in per purchase, so each later batch uses the tier mix at your loot count when that batch starts.
  • Disablelist counts are extra noisy because $lk mixes in $kt contributions, so its spread is wider than other rewards.
  • All counts shown are what you'd actually receive (doubled by quantity), not raw spawn counts. For kakera, make sure to enter your server's $klvalue so the amounts are right.

For more information on the models used by this calculator, refer to the full writeup of the investigation.

How it works
1 Two rate estimators

The calculator estimates your per-loot spawn rate two ways and blends them:

  • Empirical — a cell table keyed on (reward type, kakeraloot-usage bin, cumulative-count bin, quality bin). Each cell stores an observed spawn rate, an effective sample size (N_eff), and a bootstrap confidence interval, built from real $lk snapshots submitted by players.
  • Parametric — a gen-hyperbolic decay fit that captures how spawn rates drop as your kakeraloot usage grows. It smooths and extrapolates sparse or unseen cells.

The two are blended by sample size: trust the empirical table where N_eff is high, fall back to the parametric model where it is low. The blend constant κ is tuned by calibration.

Blended rate rate = w · empirical + (1 − w) · parametric
w = N_eff / (N_eff + κ)

Parametric decay parametric = A · (1 + q/100) · (1 + kl/k)−α
← A, k, α fitted per reward type; q = quality
2 Two-part uncertainty

Every estimate has two independent sources of uncertainty:

  • Aleatoric (outcome randomness) — each loot is an independent draw from a negative-binomial distribution with Var = r · mean, where r is a per-type over-dispersion parameter. This is the natural variance you'd see even with a perfect rate estimate, and it's what makes a single loot's result unpredictable.
  • Epistemic (rate uncertainty) — the empirical cell's bootstrap rate confidence interval, widened toward the parametric point for sparse cells. This models "we don't know the true spawn rate exactly" — the less data behind a cell, the wider this band.

Both combine into the forecast and inverse bands you see in the results.

Aleatoric (per-loot outcome) count ~ NegBin(mean, r)
Var(count) = r · mean
← r fitted per reward type (over-dispersion)

Epistemic (rate CI) [ci_lo, ci_hi] = w · [emp_ci_lo, emp_ci_hi]
                       + (1 − w) · parametric
← widens toward parametric as N_eff falls
3 The three queries

Luck ranks your observed cumulative count against players in a similar state. Peer snapshots near your loot count, at compatible quality and quantity, are projected to your exact loot count and your count is ranked among the projections — so the percentile measures how you compare to typical players at your state, not where you sit inside a bin. When too few peers exist, a negative-binomial model at your state is used instead ("modeled"). This peer-based comparison is what shows as "empirical" in the results. >50% means you're luckier than a typical player at your stage.

Forecast is a Monte Carlo simulation: it draws thousands of negative-binomial outcomes at your blended rate, each scaled by an epistemic rate-CI sample, then takes percentiles for the band.

Inverse works backwards from a target: "how many loots until I get N more of this reward?" It bisects on the decay integral to find the smallest horizon X where the expected count reaches your target. The band comes from the rate CI — optimistic (high rate) needs fewer loots, pessimistic (low rate) needs more.

Forecast (Monte Carlo) for i in 1..N:
  s_i ~ Normal(1, rel_sd) ← epistemic scale
  d_i ~ NegBin(mean · s_i, r) ← aleatoric draw
band = percentiles(d)

Inverse (bisection) find X s.t. E[count over X] ≥ target
X_lo = loots_for(ci_hi) ← optimistic
X_hi = loots_for(ci_lo) ← pessimistic