DEV Community: YMori

Two players, pick one on last season's numbers: how often is it right? MLB 2026, checked against rules fixed in advance

YMori — Mon, 05 Oct 2026 10:09:48 +0000

When players are compared, "his average was higher last year" or "his ERA was lower" often comes up first. There are also plenty of numbers that try to take the luck out of the results: xwOBA, FIP, K−BB% and so on. If one of two players has to be chosen, which of last season's numbers most often picks the one who does better the next season? I had long wondered about that.

So I used public MLB data to repeat "pick one of two players on last season's numbers" hundreds of thousands of times, and counted how often each number picked right. For 2026, I wrote down the method and the reading rule and froze them in a repository before checking the result. I have no experience inside the game; this is just an analysis of public data.

Data and method

Season stats for hitters and pitchers: tables built from the MLB Stats API and Baseball Savant, 2015-2026. I used the player-season tables of my public Hugging Face dataset

The method:

Take every player with at least 100 plate appearances (hitters) or 100 batters faced (pitchers) in both a season (year 1) and the next season (year 2)
Pair up every two players of the same season (pitchers only with the same role: starters with starters, relievers with relievers)
Pick one of the two on a year-1 number: for hitters the higher one, for pitchers the lower ERA, FIP or xERA, or the higher K−BB%
The pick is right if the picked player did better in year 2: higher wOBA for hitters, lower ERA for pitchers

A pair that a rule cannot split (equal year-1 numbers) counts as half right. A share of 50% means the rule does no better than a coin flip.

Scoring the pairs looks like this in Python (simplified; the real code also filters the players and computes the intervals):

# x: year-1 number (oriented so that higher is better), y: year-2 result (higher is better)
dx = x[:, None] - x[None, :]          # year-1 difference for every pair
dy = y[:, None] - y[None, :]          # year-2 difference for every pair
right = np.where(dx == 0, 0.5, (dx > 0) == (dy > 0))   # right if the pick is also ahead in year 2
valid = (dy != 0) & ~np.eye(len(x), dtype=bool)         # drop year-2 ties and self-pairs
share = right[valid].mean()

The numbers compared (definitions in the appendix):

Hitters: wOBA, xwOBA, wRC+, and a blend of five numbers (xwOBA carries the most weight)
Pitchers: ERA, FIP, xERA, K−BB%, and a blend of the four

The blends were fitted only on pairs whose year 1 is 2015-2024 (year 2 up to 2025).

What was fixed in advance

I built the method on 2015-2024 (dropping the seasons where year 1 or year 2 is the 60-game 2020), then picked on 2025 numbers and scored on 2026 results. Before reading the 2026 results, I froze the rule in the repository: "for the 2025→2026 pairs, report each number's share picked right and its difference from the base number (wOBA for hitters, ERA for pitchers). If the whole 95% interval of the difference is above 0, the number picks right more often; if it is wholly below 0, it picks right less often; if it crosses 0, the two are indistinguishable." In fact the pitcher version was scored first; the hitter version was written in the same form and frozen after I had seen the pitcher result, then scored. The intervals come from 2,000 resamples of players with replacement. The same player sits in hundreds of pairs, so resampling pairs instead of players would make the intervals far too narrow.

The 2026 test has 353 hitters (62,126 pairs) and 359 pitchers (32,122 pairs).

Hitters: last season's xwOBA picked right 65% of the time, wOBA 61%

Picking on last season's wOBA was right 61.4% of the time. xwOBA was right 65.1% and the blend 65.4%. wRC+ was 61.6%, about the same as wOBA.

Against wOBA, xwOBA was +3.7 points (95% interval +1.3 to +6.1) and the blend +3.9 points (+1.9 to +6.1); both intervals are above 0, so by the rule fixed in advance both pick right more often than wOBA. wRC+ was +0.2 points (−0.3 to +0.6): indistinguishable.

Note that wRC+ adjusts for park and league, while the outcome here (next season's wOBA) is not adjusted.

Pitchers: 56-58% whichever number, none separable from ERA

Picking pitchers on last season's ERA was right 55.8% of the time. FIP was 57.1%, xERA 58.1%, K−BB% 58.4% and the blend 58.5%. All are a little above ERA, but every 95% interval of the difference (+1.2 to +2.6 points) crosses 0, so by the rule all four are indistinguishable from ERA.

"Indistinguishable" does not mean "no difference". It means one season of pairs was not enough to tell a difference of this size apart.

2026 came out in roughly the same order as the development seasons

Here 2026 sits next to 2015-2024, the seasons the method was built on (486,143 hitter pairs, 259,065 pitcher pairs). White is that period, blue is 2026.

Hitters' wOBA fell from 63.8% to 61.4%, while xwOBA barely moved (65.8% to 65.1%), so the gap widened in 2026 (+2.0 to +3.7 points)
Pitchers' ERA was 55.8% both times. The other numbers were 0.9 to 1.6 points lower in 2026, so their gap to ERA shrank
In 2015-2024, FIP, xERA and K−BB% did beat ERA for pitchers (+2.9 to +3.6 points, intervals clear of 0). The case that these numbers pick pitchers better than ERA rests on that period

When wOBA and xwOBA disagree, xwOBA was right 59% of the time

In most pairs every number picks the same player. The choice of number only matters in the pairs where two numbers point at different players, so here are those pairs alone.

wOBA and xwOBA pointed at different hitters in 12,195 of 62,126 pairs (about a fifth); xwOBA was right in 59% of them and wOBA in 41%. ERA and K−BB% pointed at different pitchers in 11,028 of 32,122 pairs (about a third); K−BB% was right in 54% and ERA in 46%. The 95% interval of the difference is +6.9 to +30.1 points for hitters (xwOBA minus wOBA, +18.7), clear of 0, but −3.2 to +18.9 for pitchers (K−BB% minus ERA, +7.4), which crosses 0: one season cannot separate them. In 2015-2024 the figures were 56% for xwOBA and 56% for K−BB%.

One pair at a time

Here are a few pairs where the numbers disagree sharply.

Hitters: Harrison Bader and Salvador Perez (2025)

	wOBA	xwOBA	PA	2026 wOBA
Harrison Bader	.346	.297	501	.238
Salvador Perez	.311	.357	641	.285

wOBA picks Bader, xwOBA picks Perez. Bader's results were .049 better than his quality of contact predicted, Perez's .046 worse. In 2026 Perez was ahead: xwOBA was right. Note, though, that Bader had only 111 PA in 2026.

Nor is xwOBA always right. Pairing the same Perez with Jacob Wilson (2025 wOBA .348, xwOBA .304, 523 PA), Wilson had .301 in 2026 and Perez .285: wOBA was right.

Pitchers: Brayan Bello and Dylan Cease (2025, both starters)

	ERA	K−BB%	FIP	xERA	Batters faced	2026 ERA
Brayan Bello	3.35	9.3%	4.19	4.48	700	4.33
Dylan Cease	4.55	19.9%	3.56	3.46	722	2.40

ERA picks Bello, K−BB% picks Cease. Cease struck out many more than he walked yet had a 4.55 ERA; in 2026 his ERA was 2.40. K−BB% was right.

On the other hand, with Clay Holmes (2025 ERA 3.53, K−BB% 8.9%) and Jack Flaherty (ERA 4.64, K−BB% 18.9%), Holmes had 3.29 in 2026 and Flaherty 4.48: ERA was right.

Hand-picked pairs alone prove nothing, so here are all such pairs counted together. Among pitcher pairs where both faced 500+ batters and the one with the ERA lower by more than 1.00 was not the one with the K−BB% higher by more than 6 points, there were 38 pairs and K−BB% was right in 55% (21); with only 38 pairs, that cannot be told apart from a coin flip. Among hitter pairs where both had 500+ PA and the one with the wOBA higher by more than .025 was not the one with the xwOBA higher by more than .025, there were 56 pairs and xwOBA was right in 35 of them (62.5%). Both counts were made after the results were read, for reference.

Hitters picked on xwOBA had a next-season wOBA .019 higher, over all pairs

The share picked right does not say how far apart the picked and the unpicked player end up the next season. Here is the mean next-season gap between the player picked and the one left (wrong picks count as negative).

For hitters, picking on wOBA gave a next-season wOBA .014 higher on average, xwOBA .019. For pitchers, picking on ERA gave a next-season ERA 0.23 lower, K−BB% 0.37 lower. In both cases picking on xwOBA or K−BB% gives the bigger gap.

Why

Hitters: xwOBA takes out the luck on batted balls

wOBA is computed from the actual result of each plate appearance. xwOBA replaces each batted ball with the value expected mostly from its exit velocity and launch angle. The difference between the two contains batted-ball luck: whether the same ball goes straight to a fielder or finds a gap.

In my previous article on pitch-level results, batted-ball luck hardly carried over to the next season either. For hitters too, plotting last season's wOBA and xwOBA against next season's wOBA, xwOBA gives the clearer upward slope.

Over the 353 hitters of the 2026 test, the correlation with next season's wOBA is 0.32 for wOBA and 0.42 for xwOBA.

How hard the outcome itself is: same-season numbers get about 80%

To see why the numbers were harder to tell apart for pitchers, I measured how hard the outcome itself is to pick. What if the 2026 ERA is picked using the same season's 2026 FIP? Same pairs, same scoring as the picks on last season's numbers. It is a reference value that could never be used in practice, and it is not part of the method fixed in advance.

Even knowing the same season's FIP, the lower ERA was picked 77% of the time (xERA 76%, K−BB% 67%). For hitters, the same season's xwOBA picked the higher wOBA 82% of the time. Even with same-season numbers, around a fifth of pairs come out the other way. For hitters, xwOBA and wOBA differ only in the results of batted balls (out, single, extra-base hit), so that is where the reversals come from. For pitchers, ERA also depends on whether hits come with runners on and on the fielders behind them, which FIP leaves out.

Picking on last season's numbers, hitters land 11 points (wOBA) or 15 points (xwOBA) above a coin flip, pitchers 6 points (ERA) or 8 points (K−BB%). For pitchers no number gets far from a coin flip, and the numbers differ from each other by only 1 to 3 points. One season's intervals are ±3 to 4 points wide, too wide to separate gaps of that size. Pooling the eight seasons of 2015-2024 narrows the intervals to about ±1 point, and gaps of the same size then clear 0.

By plate appearances, xwOBA had the higher share in every band

I split the pairs into three bands by the smaller of the two hitters' 2025 PA. The pre-registration lists this as reported only, not used for conclusions.

xwOBA had the higher share in every band, but in the 500+ PA band the interval of the difference crosses 0 (−1.8 to +7.2 points). In 2015-2024 too, the 500+ band had a small gap between xwOBA and wOBA (0.7 points) with an interval crossing 0.

Summary

In this data:

Picking one of two hitters on last season's numbers, xwOBA was right 65% of the time in 2026 and wOBA 61%, and the gap held up on one season alone. wRC+ did about as well as wOBA
Picking one of two pitchers, ERA, FIP, xERA, K−BB% and the blend were all right 56-58% of the time, and 2026 alone could not separate them from ERA. In 2015-2024 the numbers other than ERA did pick better
Where wOBA and xwOBA point at different hitters, xwOBA was right 59% of the time. For pitchers, K−BB% was right 54% against ERA, which one season cannot separate
For reference, even same-season FIP or xwOBA picks right about 80% of the time

What surprised me most is that picking the player with the better number last season is still wrong about 4 times in 10. For hitters, picking on xwOBA was right more often than picking on wOBA, and that is the clearest result here. For pitchers one season says little, and I would like to keep checking it for a few more seasons.

Appendix

Terms

wOBA: an overall batting measure that weights each plate-appearance outcome (walk, single, home run, ...) by its run value
xwOBA: wOBA with each batted ball replaced by the value expected mostly from its exit velocity and launch angle (sprint speed is also used for some weakly hit balls)
wRC+: batting run contribution adjusted for park and league, with league average = 100
ERA: earned runs per nine innings
FIP: a pitcher's expected run allowance from strikeouts, walks, hit-by-pitches and home runs only
xERA: an ERA estimate from the exit velocity and launch angle of the batted balls a pitcher allowed, plus strikeouts, walks and hit-by-pitches
K−BB%: strikeouts minus walks, as a share of batters faced
Blend: a combination of year-1 numbers fitted on 2015-2024 to predict year 2. Hitters: wOBA, xwOBA, strikeout rate, walk rate and ISO (slugging minus average). Pitchers: ERA, FIP, xERA and K−BB%. In the hitter blend xwOBA carries the most weight (about 60% by coefficient times standard deviation) and wOBA almost none

Caveats

Only players with 100+ PA (batters faced) in year 2 are counted. Players whose playing time dropped after a bad season drop out, so this compares players who kept playing. With a 50 bar in year 2, the hitters' order is the same; for pitchers xERA and K−BB% swap places (58.9% and 58.8%)
A pitcher is a starter if at least half of his year-1 games were starts, otherwise a reliever; only same-role pairs are formed
Pairs a rule cannot split count as half right; pairs with equal year-2 results are not counted
The same player appears in hundreds of pairs, so tens of thousands of pairs do not carry that much information; the intervals resample players
The strong-disagreement counts (500+ PA or batters faced, an ERA gap of more than 1.00, and so on) and the same-season reference values were computed after the results were read and are not part of the method fixed in advance
Fielding, baserunning, park, age, health and contracts are not included. Choosing real players involves a lot more than this

Reproducing

All code, the rules fixed in advance and the results are in mlb-data-pipeline.

analysis/decision_pairs_batters/: hitters (PREREG.md is the rule fixed in advance, RESULTS.md the result)
analysis/decision_pairs/: pitchers (same). article_dig.py computes the extra numbers for this article and article_figs.py draws the charts

How well do player projections predict team wins? I froze MLB 2026 first, then checked

YMori — Sun, 04 Oct 2026 23:53:04 +0000

Every spring there are plenty of "how many games will each team win" projections. Most of them build a forecast for each player and add the players up by team. I had long wondered how well that actually works.

So I built one of my own and checked it against the 2026 MLB season. I froze the projections in a repository before looking at the results, so nothing could be adjusted afterwards. I have no experience inside the game; this is just an analysis of public data.

Data and method

Player stats: batting and pitching from the MLB Stats API, 2015-2026, every player
Rosters: each team's 40-man roster on opening day (including the 60-day injured list), from the same API (only what is known before the season)
The answer: final standings (wins, runs scored, runs allowed) from the same API

The player forecasts are based on Marcel, a deliberately simple method by Tom Tango: weight the last three seasons (newer ones more), pull the result toward league average, and adjust a little for age. It is often used as the baseline other systems are compared with. The real Marcel projects each component (home runs, walks, strikeouts, ...) separately; mine is a simplified version that applies its weights, regression, playing time and age factor to wOBA and FIP directly.

Batters: wOBA relative to league average, three seasons weighted 5:4:3, regressed with 1,200 PA of league average
Pitchers: FIP relative to league average, weighted 3:2:1, regressed with 134 innings of league average
Playing time: half of last season plus a tenth of the season before, plus 200 PA for batters and 60 innings (starters) or 25 (relievers) for pitchers
Team: add up the opening-day 40-man roster into runs scored and allowed, then turn them into wins with the Pythagorean formula

For one batter it looks like this in Python (simplified; the real code also adjusts for age and makes league runs scored and allowed match):

# h: the player's last three seasons, one row per season
# rel = that season's wOBA minus that season's league wOBA
w = h.season.map({y - 1: 5, y - 2: 4, y - 3: 3})
rel = (w * h.pa * h.rel).sum() / ((w * h.pa).sum() + 1200)   # pull toward league average
pa = 0.5 * pa_last + 0.1 * pa_before + 200                    # playing time
runs_above_avg = pa * rel / woba_scale                         # runs above an average hitter

A team's runs scored are league-average runs plus the sum of its players' runs above average; runs allowed are built the same way from the pitchers. Plate appearances and innings are scaled so each team gets 162 games' worth.

To have something to beat, I used three floors that take no work at all:

Every team .500: 81 wins each
Last season's record: the same winning percentage as last year
Last season's Pythagenpat: last year's winning percentage implied by its runs scored and allowed (Pythagenpat is a version of the Pythagorean formula)

If adding up player forecasts is worth the effort, it should at least beat these three. The yardstick is the mean absolute error of wins over the 30 teams.

Over nine past seasons, it beat last season's Pythagenpat in seven

Before 2026 I ran the same thing on the nine seasons 2016-2025 (leaving out the 60-game 2020), projecting each season only from the seasons before it and taking the mean error over its 30 teams.

The average over the nine seasons was 8.27 wins, against 10.60 for .500, 9.67 for last season's record and 9.34 for last season's Pythagenpat. It beat the toughest floor, Pythagenpat, in 7 of 9 seasons (not in 2019 or 2025).

These nine seasons, though, are the ones I was looking at while making design choices, so they may flatter the method. Against Pythagenpat, the 95% bootstrap interval (resampling seasons) only just cleared zero, with an upper end of -0.01 to -0.05 depending on the random seed.

In 2026 it was slightly better than the floors, but not distinguishably

For 2026 I wrote the projections to a file and merged them into the repository, together with the scoring rules, before fetching the standings. I froze them after the season had ended, but the projections only use information from before opening day; the point is that the method cannot be adjusted to fit the result. At scoring time I checked that the frozen files had not changed by a byte.

The mean error was 7.92 wins, a little below all three floors. But the 95% intervals from resampling the 30 teams cross zero for every floor (against Pythagenpat: -0.80 wins, -2.82 to +1.36). By the rule set in advance, that is "indistinguishable".

A version that stretches the projections away from .500 by a factor of 1.25 (fitted on the past seasons) did slightly worse in 2026, at 8.16.

The big misses were MIL, TB, SF and ATH

Projected wins across, actual wins up; the closer to the dashed line, the better. MIL was projected for 84 and won 103, TB 80 and 98, SF 83 and 65, ATH 80 and 64. The correlation of projected and actual wins was 0.48 (0.63 over the nine past seasons).

The projections spread half as wide as the results

The 30 projected and actual win totals on one line: the projections sit between 67 and 93 wins, while the actual records ran from 58 to 103. Marcel pulls every player toward league average, so the teams built from them are pulled toward .500 too.

Even with the actual runs, about 4 wins of error remain

A miss splits into two parts: the runs scored and allowed were projected wrong, or the team won more or fewer games than its runs suggest. The second part comes from things like close games, and no player forecast can remove it. So I asked how well the Pythagorean formula does if the actual runs scored and allowed were known.

With the actual runs, the average miss is still 3.94 wins. The gap between the projected wins and the wins implied by the actual runs, which is the runs projection being off, averages 8.06 (runs scored were off by a standard deviation of 56, runs allowed by 68).

What the miss is made of differs by team

For the four big misses, I split the miss into those two parts. Blue is the runs projection (projected wins minus wins implied by actual runs), gray is record versus runs (wins implied by actual runs minus actual wins); together they make the miss.

Almost all of MIL's 19-win miss came from runs. TB's 10 wins from runs were topped up by 8 wins of beating its runs. ATH's runs projection was off by 21 wins, but it won 5 more than its runs suggest, shrinking the miss to 16. SF's 11 wins from runs were compounded by losing 6 more than its runs suggest.

MIL had two projected players beat their forecasts by 30+ runs

I split MIL, the biggest miss, by player: how many runs above average each was projected to add (or save), against what they did. Batters use wOBA and pitchers FIP, converted to runs the same way as in the projection. Projected PA and innings are after scaling the roster to 162 games. Only players on the opening-day 40-man roster with a projection are shown.

Jacob Misiorowski (pitcher) was projected for 97 innings and about 5 runs saved; he threw 169 innings and saved about 38. With few innings behind him, his forecast was pulled hard toward average and his innings were estimated low. Jake Bauers (batter) was projected for 309 PA at about league average and had 574 PA and about 31 runs above average. Better rates and more playing time both played a part.

Still, the projected players beating their forecasts explain only 40% of MIL's run gap

MIL scored 93 more runs than projected and allowed 96 fewer, about 190 runs in all. The projected batters beating their forecasts (+19 projected, +71 actual) account for 52 of them, the projected pitchers (by FIP, +46 to +70) for 24: about 40% together. The other 60% includes fielding, baserunning and batted-ball outcomes that FIP and wOBA do not see, and players without a projection; pitchers with no forecast threw 33% of MIL's innings.

20-30% of playing time went to players with no forecast

The players without a projection are those not on the opening-day 40-man roster and rookies with no MLB history. I took their share of all 2026 plate appearances and innings.

They took 20% of plate appearances and 27% of innings. The projection assumes the projected players fill that time in proportion. Across the 30 teams, though, the correlation between a team's miss and its unprojected players' total WAR was a weak -0.27, with no clear link to the big misses.

Summary

Adding up player forecasts beat the floors over nine past seasons, but in the frozen 2026 test its mean error of 7.92 wins could not be told apart from the floors (8.50 to 8.83).
Even with the actual runs, about 4 wins of error remain. The runs projections alone miss by about 8 wins on average, partly offset for some teams by winning more or fewer games than their runs suggest. The projections cluster toward .500 and spread half as wide as the results.
In the biggest miss, MIL, projected players beating their forecasts explain about 40% of the run gap; the rest includes fielding, baserunning and unprojected players.

What surprised me most is that a gap of under one win cannot be seen in one season. A method can win over past seasons and still not show it in a single year of scoring, so comparing projection systems probably takes several years side by side. If I change anything next, it will be how rookies and new arrivals are handled, again frozen in advance, for 2027.

Appendix

Terms

wOBA: a batting rate that weights each outcome (walk, single, home run, ...) by its run value
FIP: a pitcher's run estimate from strikeouts, walks, hit batters and home runs only, leaving out whether balls in play fall for hits
Marcel: Tom Tango's simple projection: a weighted average of three seasons, regressed toward average, with an age adjustment (applied here directly to wOBA and FIP)
Pythagenpat: the Pythagorean win formula with an exponent that depends on the run environment, ((runs scored + allowed) per game)^0.287

Also checked

Do young teams beat their projection? MIL made it look as if teams whose young players improve should beat their projections. Over 300 team-seasons (the nine past seasons and 2026), the correlation between the age of a team's projected batters (weighted by projected PA, relative to that season's average) and its miss was -0.01. Split into age quartiles, the average miss ranged from -0.7 to +1.6 wins with no order.

Caveats

No fielding, park or schedule. Runs allowed come from FIP only, so defence is not in it.
Opening-day 40-man rosters include players on the injured list or in the minors that day, so playing time is spread over more players than actually played.
Shohei Ohtani is listed as a pitcher on the 2018-2019 rosters, so his batting is missing from the 2019 backtest (he is a two-way player from 2020 on).
The interval for one season of 30 teams ignores that teams share league-wide trends, so it is narrower than it should be.

Reproducing it

Code, the frozen projections and the scoring rules are in mlb-data-pipeline, forecast/team_wins.

fetch.py: opening-day 40-man rosters and standings from the MLB Stats API
project.py: Marcel forecasts and team wins
score.py: floors and scoring
PREREG.md: the scoring rules written before the answer was known
RESULTS.md: the 2026 result

Asking a Decision-Only AI (TypeSafe Jev) to Forecast Next Season's Hitting: Worth About 20 to 50 Training Examples

YMori — Wed, 30 Sep 2026 10:24:22 +0000

TypeSafe Jev is a decision-only model: it does not write text, it returns typed answers with probabilities. You can ask for a yes/no probability (Noul), probabilities over choices (Choice) or over ordered levels (Score).

If it answers with probabilities, could it help with baseball's "what happens next year" questions? I wanted to know how often it is right and where it goes wrong, so I tried it on public MLB data. I have no experience working in baseball; I just tallied up public data.

How to call Jev

Jev is available through OpenRouter. All 697 calls used for evaluation in the two studies below fit in a new account's free allowance (no card, balance left at $0; the costs returned by the API add up to about $0.019 = 0.0107 + 0.0080).

A call sends a state describing the situation and typed questions:

body = {
    "model": "typesafe/jev-1.13",
    "state": {"context": "An anonymous MLB hitter's 2025 regular season. ...",
              "wOBA": 0.315, "xwOBA": 0.33, "strikeout_rate_pct": 19},   # excerpt
    "questions": {
        "delta_bin": {"type": "score",
                      "instructions": "How will this hitter's wOBA in 2026 compare with his 2025 wOBA?",
                      "criteria": ["Big drop: ...", "Small drop: ...", "About the same: ...",
                                   "Small rise: ...", "Big rise: ..."]},
    },
}
req = urllib.request.Request("https://openrouter.ai/api/alpha/decisions",
                             data=json.dumps(body).encode(), method="POST",
                             headers={"Authorization": f"Bearer {key}",
                                      "Content-Type": "application/json"})
resp = json.load(urllib.request.urlopen(req, timeout=30))
probs = [resp["answers"]["delta_bin"]["probabilities"][str(k)] for k in range(5)]

What comes back is only the probabilities, like {"0": 0.02, "1": 0.32, ...}, with no explanation.

Code, pre-registrations and every Jev answer are in yasumorishima/jev-baseball.

First study: will an ABS challenge be overturned?

I first asked whether an ABS challenge (a player disputing a ball/strike call) would be overturned. Every challenge has a known answer, so the probabilities are easy to score.

Building the data

In MLB StatsAPI game feeds (feed/live), a challenged pitch carries reviewDetails. From 777 games in August and September 2026 I extracted 2,678 pitch challenges (reviewType == "MJ").

Two things needed care:

The pitch's details.call.description is the call after the review. Using it would leak the answer, so the original call comes from who challenged (the batting side challenges strikes, the fielding side challenges balls).
The count on a pitch is the count after that pitch. The count before it comes from the previous pitch.

A gap I found later. While re-collecting a full season for another article, I found that when the final call ends the plate appearance (a called strike three or ball four), reviewDetails sits on the play, not on the pitch. This study read only the pitch, so of the 3,543 challenges from August 1 to September 27 collected again, 893 (25%) were missing (the 2,650 it did capture differ slightly from the original 2,678 because they were collected at different times). The missing ones were overturned 48.6% of the time, against 56.8% for the captured ones.

All 250 challenges put to Jev came from the captured part, so this section describes challenges where the plate appearance went on. Refitting the distance-only formula on all of August and scoring all of September (1,650) gives a Brier score of 0.102. On the captured September challenges (1,238), the original formula scores 0.1121 and the refitted one 0.1123, nearly the same. The two sets differ, so 0.102 and 0.112 cannot be compared directly, but using every challenge did not make the formula worse. I did not ask Jev again (the free allowance is spent), so Jev's numbers cover only the captured part.

The distance to the zone depends on whether the ball's surface touches the zone, so it is "distance from the zone rectangle to the ball's center, minus the ball's radius" (which gives the zone rounded corners):

def edge_in(px, pz, top, bot):
    """Inches from the ball's surface to the zone; + misses, - touches."""
    x0, x1 = -17 / 24, 17 / 24                     # half the plate width (feet)
    dx = max(x0 - px, 0.0, px - x1)
    dz = max(bot - pz, 0.0, pz - top)
    if dx > 0 or dz > 0:
        d0 = math.hypot(dx, dz)
    else:
        d0 = -min(px - x0, x1 - px, pz - bot, top - pz)
    return (d0 - 1.45 / 12) * 12                    # minus the 1.45-inch ball radius

I asked Jev about 250 challenges from September and compared it with a logistic regression on a single input, "inches on the wrong side of the original call", fitted on 1,431 August challenges. Jev was given the coordinates and zone top and bottom, plus this distance precomputed.

Result: the distance-only formula wins easily

The Brier score (mean squared gap between the probability and the 0/1 outcome; lower is better) was 0.113 for the distance-only formula and 0.180 for Jev.

I split the 250 into four groups by how far, and on which side, each pitch was from the original call. The 82 pitches at least an inch on the wrong side were overturned 99% of the time, and the formula said 98%. Jev's average probability was 65%. The 63 pitches more than an inch on the called side were never overturned, yet Jev gave them 18% on average.

Near the edge (within an inch) both the formula and Jev are unsure. Even pitches within an inch on the called side were overturned 58% of the time: the edge computed from StatsAPI coordinates does not seem to reproduce the zone ABS actually uses right at the edge.

The wrong task for this tool

This result could have been predicted before measuring anything. ABS compares a tracked position with a fixed zone, so the answer is set by a rule; it is not a judgment call.

So I switched to something not settled by a rule, and genuinely uncertain.

Main study: how much will a hitter's wOBA move next season?

A hitter's next season is a mix of regression to the mean, luck, age, injuries and more. No rule settles it, but measures of the hitting itself (xwOBA, strikeout rate and so on) are available, so there is material to judge from.

Data and comparison

Data: season hitting lines from my own MLB dataset (yasumorishima/mlb-stats on Hugging Face), built from Baseball Savant and MLB StatsAPI
Hitters: 227 with at least 250 plate appearances in both 2025 and 2026. The 82 who had 250 in 2025 but not in 2026 are not included, so this is about hitters who kept playing
Given to Jev: 2025 PA, wOBA, xwOBA, strikeout and walk rates, ISO, BABIP, batted-ball mix (ground ball, fly ball, pulled air ball) and sprint speed; age and position in four bands. No name or team, and numbers rounded
Question: which of five bins the 2026 change in wOBA falls in (Score)

The bin edges split past year-to-year changes into fifths. The past pairs are the 1,620 consecutive seasons from 2016→2017 through 2024→2025 with 250+ PA in both (pairs touching the 60-game 2020 season excluded). The edges came out at −36, −14, +3 and +25 points (1 point = 0.001 of wOBA).

Forecasts were scored with the RPS (Ranked Probability Score): the mean squared gap between the cumulative forecast and the cumulative outcome, so predicting "small rise" is punished more when the answer is "big drop" than when it is "big rise". Lower is better.

def rps(probs, b):          # probs: 5 bin probabilities, b: actual bin (0-4)
    cp, tot = 0.0, 0.0
    for k in range(4):
        cp += probs[k]
        tot += (cp - (1.0 if b <= k else 0.0)) ** 2
    return tot / 4

Three comparators:

Guessing: 20% in every bin
Marcel-style rule: pull toward the league mean by plate appearances and adjust a little for age, with no fitting. The forecast change is the center of a normal distribution whose width is the rule's error on the past pairs, turned into five bin probabilities
Models fitted on past examples: ridge regression fitted on n of the 1,620 past pairs

def marcel(u):
    lg = u["lg"]                                             # 2025 league wOBA
    proj = lg + u["pa"] / (u["pa"] + 600) * (u["woba"] - lg)
    age = u["age"]
    proj *= (1 + 0.006 * (29 - age)) if age < 29 else (1 - 0.003 * (age - 29))
    return proj - u["woba"]                                  # forecast change

A model fitted on all the data will beat Jev, so the question is how many past examples a fitted model needs to catch up with Jev. That number is a rough measure of how much baseball knowledge Jev brings with it, which matters most where data is scarce, such as new foreign players or rookies.

To avoid reading the results in whatever way suited me, I committed the design and "which result means what" to the repository before calling Jev (PREREG.md).

Jev's gain over guessing is a third of the Marcel-style rule's

Guessing scores an RPS of 0.195. The chart shows how far each method gets below that.

Jev gets 0.015 below, better than guessing: the 95% interval of the difference over 10,000 resamples of hitters is [−0.029, −0.001] and excludes 0.

The Marcel-style rule gets 0.046 below, and Jev does not reach it (difference +0.031, 95% interval [+0.017, +0.044]). By the pre-registered reading, Jev is worse than a textbook rule.

Jev is worth a model fitted on 20 to 50 past examples

I fitted ridge regressions on n of the 1,620 past pairs (n = 10, 20, 50, 100, 300) and scored them on the same 227 hitters. Which examples are drawn matters, so each n is an average over 200 draws.

On average, the model fitted on 20 examples is worse than Jev and the one on 50 is better. With no examples at all, Jev forecasts about as well as a model fitted on 20 to 50 examples.

With 20 examples, though, the result swings a lot with the draw (95% range 0.157 to 0.242), and Jev's 0.180 is inside it. And only 20 and 50 were measured; where the lines cross is not a measured value.

Jev rarely expects big moves

From here on, the analysis was done after seeing the results. First, where did Jev lose points?

For each bin, the share of hitters who actually landed in it (gray) next to Jev's average probability for it (orange). The bins split past changes into fifths, so in past pairs each holds about 20%.

In 2026, 15% of the 227 had a big drop and 22% a big rise. Jev gave these 2% and 9%. It put too much on "about the same" and "small rise".

It is clearer hitter by hitter. I turned Jev's five probabilities into an "expected change" by weighting each bin's average change in the past pairs (−57, −24, −5, +14, +45 points).

The actual change is on the x-axis and the forecast change on the y-axis. Points on the dashed line are exact. Jev's forecasts stay within about ±30 points, a flat band.

The standard deviation of the forecasts is 13 points for Jev and 21 for the rule, against 36 for the actual changes. Actual changes include luck, so even a good forecast moves less than reality; the fair comparison is with the rule, and Jev moves only about 60% as much.

Because this "expected change" is built from bin averages, it cannot go below −57 points even if Jev puts 100% on "big drop". The bottom-left corner of the chart is partly a limit of that construction.

The direction is right. The correlation of the forecast with the actual change is 0.57 for Jev and 0.62 for the rule, not far apart. The gap is in how far the forecasts move.

Jev missed the stars' big drops, got the unlucky hitters right

The number beside each name is the 2025 wOBA. Jev never saw names; to Jev, Judge was "wOBA .465 (rounded to 0.005), an outfielder aged 30 to 33".

Aaron Judge had a .463 wOBA in 2025 and dropped 91 points in 2026. The rule, reasoning that such a high number regresses, forecast a 75-point drop; Jev forecast 20. Cal Raleigh (.392) and George Springer (.408) look the same: about 90 points down, with Jev at 15 to 23. No forecast, the rule included, caught drops this large.

Jev did better on others. Henry Davis had a low .229 wOBA in 2025, 64 points below his xwOBA (.293), an unlucky year. He rose 34 points; Jev said +35, nearly exact, while the rule said +64, too high.

Michael Conforto rose 55; Jev said +34 and the rule +11, so Jev was closer. His wOBA was 43 points below his xwOBA, and here it matters whether a forecast uses luck (next section).

Jev uses luck, but not much regression to the mean

What Jev leans on may explain these five. I regressed Jev's expected change on two inputs:

Regression to the mean: how far the 2025 wOBA was above the league mean
Luck: 2025 wOBA − xwOBA (the gap to the wOBA expected from exit velocity and launch angle)

and fitted the same regression to the actual changes in the 1,620 past pairs:

X = np.c_[np.ones(n), woba_minus_league, woba_minus_xwoba]
w_actual, *_ = np.linalg.lstsq(X_train, actual_delta_train, rcond=None)   # 1,620 past pairs
w_jev, *_    = np.linalg.lstsq(X_test, jev_expected_delta, rcond=None)     # Jev's forecasts (227)

In the past pairs, a hitter one point above the league mean gave back 0.43 points the next season, and one point of wOBA above xwOBA also gave back 0.43. In Jev's forecasts, the luck weight is 0.32, somewhat weaker than reality, but the regression weight is 0.20, less than half.

The Marcel-style rule is the reverse: a strong regression weight (0.57) but, with no xwOBA in the formula, almost no luck weight (0.01). That is why the rule said only +11 for Conforto; the past-pair weights give +30.

A star who really was hitting, like Judge, also has a high xwOBA, so there is little luck to give back. What is left is regression to the mean: −66 points with the past-pair weights, but Jev uses it weakly and stopped at −20 (the actual was −91, beyond even the weights' formula).

For Henry Davis, the past-pair weights give +64, the same as the rule. Jev being right on Davis is one hitter's result that these two inputs do not explain.

Width and regression filled in: indistinguishable from the rule

If Jev's forecasts are too narrow, does widening them catch up with the rule? I did not ask Jev again; everything below is computed from its existing answers.

Jev's center + the rule's width: a normal distribution centered on Jev's expected change, with the rule's width (the standard deviation of the rule's errors in past pairs, 32 points), turned into five bin probabilities
Flattening: Jev's bin probabilities flattened as p ** (1 / T) and mixed with guessing (20% each) at weight w. T and w were chosen by splitting the 227 into 10 groups, picking the best on nine and scoring the tenth (every group chose T between 2.7 and 3.2 and w = 0)
... plus the missing regression to the mean: the first repair, with (past-pair weight 0.43 − Jev's weight 0.20) × (points above the league mean) added to the center. Neither weight uses any 2026 outcome

Keeping Jev's center with the rule's width takes the RPS from 0.180 to 0.162, closing more than half of the 0.031 gap to the rule. Flattening gives 0.168. Neither reaches the rule's 0.149, and the 95% intervals of the differences exclude 0 (width only: +0.014 [+0.004, +0.023]).

Adding the missing regression to the mean gives 0.1505, a difference from the rule of +0.002 (95% interval [−0.005, +0.008]): indistinguishable. I think the remaining gap was almost all the weak regression to the mean. This repair, though, was thought of after seeing the results, and the repaired forecast is no longer Jev's alone.

Summary

In this data:

On a problem settled by a rule, like ABS challenges, Jev lost clearly to a distance-only formula (Brier 0.113 vs 0.180)
Asked for next season's wOBA change from anonymized lines, Jev beat guessing and was worth a model fitted on 20 to 50 past examples, but it did not reach the Marcel-style rule
It gets the direction, and it uses luck (wOBA − xwOBA), a little less than it should
It underestimates how far hitters move, above all by using too little regression to the mean. Repairing the width and the regression after the fact gave a forecast indistinguishable from the rule (no longer Jev's alone)

What the two studies share: Jev gets the direction, but its probabilities sit too close to the middle. Personally, if I start from Jev's answers where data is scarce, the next thing I want to try is filling in regression to the mean and the width from a small amount of data.

I tested one model version (jev-1.13-20260917), one way of asking, and MLB hitters from 2025 to 2026 only. Other prompts or other tasks may give different results.

Appendix

Terms

wOBA: an on-base measure weighting each outcome (walk, single, home run and so on) by its run value; the 2025 league mean was .313
xwOBA: wOBA with each batted ball replaced by the value expected from its exit velocity and launch angle
RPS: score for ordered-bin forecasts; mean squared gap between cumulative forecast and cumulative outcome; lower is better
Brier score: score for yes/no probabilities; mean squared gap between probability and the 0/1 outcome; lower is better

Pre-registered vs post-hoc

Pre-registered: how hitters were selected, the bins, the comparators, the learning curve (models fitted on n examples) and the main readings
The registered readings included a rule like "if the catch-up point is 50 examples, then ...", but the "worse than the Marcel-style rule" rule applied first, so the catch-up point is reported descriptively
Post-hoc: the bin shares, the scatter, the named hitters, the regression weights, the width and regression repairs, and the ABS breakdown by distance

Caveats

Without 17 near-outlier lines (any input more than 2.5 standard deviations from the mean), the difference from guessing has an interval crossing 0 ([−0.024, +0.005])
Rounding does not hide stars like Judge, so Jev may have recognized players. I also blended each line with a similar hitter's to hide identity, but blending narrows the actual changes too (standard deviation 0.036 → 0.029), which favors Jev's narrow forecasts. Recall would make Jev worse on blended lines and the narrowing makes it better, and only the sum is observed, so this check cannot say whether Jev recalls players
"Jev's expected change" is computed from its bin probabilities and the past bin averages; Jev did not state it
The weight comparison uses different samples (Jev's 227 forecasts vs 1,620 past actual changes). Fitting the 227 hitters' actual 2026 changes gives 0.52 for regression and 0.41 for luck, the same pattern
The ABS comparison uses a zone computed from StatsAPI coordinates, which does not reproduce the ABS zone exactly at the edge

Data and code

Hitting: yasumorishima/mlb-stats (Hugging Face), taken on 2026-09-29, two days after the regular season ended
ABS challenges: MLB StatsAPI game feeds
Analysis and charts: https://github.com/yasumorishima/jev-baseball (post-hoc analysis in study2-projection/deepdive.py)
Japanese version: Qiita

Does a pitch's performance carry over to next season? Whiff rate vs run value on 8,022 MLB pairs

YMori — Tue, 29 Sep 2026 00:08:51 +0000

While looking at pitch-type stats on Baseball Savant, I started wondering: if a pitch missed a lot of bats one year, does it still miss bats the next year? If a pitch was hard to hit one year, is it still hard to hit the next?

A good number in one season could mean the pitch is genuinely good, or it could mean it was just a good year, and that probably depends on the metric. So I checked with public MLB data. I have no professional baseball experience; I just aggregated public data.

Data and how the seasons are compared

Pitch-type stats: Baseball Savant's pitch arsenal table (pitcher x pitch type x season), 2017–2025
Pitch-level data: about 5.98 million pitches from Savant's Statcast Search (used later to split run value)

The comparison is simple. The same pitcher's same pitch type in two consecutive seasons is one pair, for example one pitcher's 2023 slider and his 2024 slider, and I take the correlation between season 1 and season 2. Only pairs with 100+ pitches in both seasons are used: 8,022 pairs.

Compared as is, the correlation would be inflated just because sliders miss more bats than sinkers no matter who throws them. What I want is "is this slider good among sliders", so I first subtract that season's average for that pitch type.

In SQL the pairs look like this. It is simplified for the post; the real thing is a dbt model (mart_scouting_reliability) that also leaves out the season in progress, among other things.

with a as (
    select player_id, season, pitch_type, pitches, whiff_rate,
           whiff_rate - avg(whiff_rate) over (partition by season, pitch_type) as w
    from pitch_arsenal
    where pitches >= 100
)
select least(x.pitches, y.pitches) as min_pitches, x.w as w1, y.w as w2
from a x
join a y on y.player_id = x.player_id
        and y.pitch_type = x.pitch_type
        and y.season = x.season + 1

Small samples are noisy, so the pairs are split into four bands by the smaller of the two seasons' pitch counts, and corr(w1, w2) is computed per band.

Whiff rate carries over; run value does not

Every metric carries over more with more pitches, but the gap between metrics is larger than the gap between sample sizes. Whiff rate with only 100–199 pitches (0.53) carries over more than run value with 800+ (0.35).

For the 1,962 pairs with 400+ pitches in both seasons, the year-to-year correlation is 0.70 for whiff rate and 0.27 for run value. This is what that difference looks like, one dot per pair:

For whiff rate, most pitches that were above average in season 1 are above average again in season 2, and the dots form a rising band. For run value, a pitch above average in season 1 can land almost anywhere in season 2; the cloud is nearly round.

How often the top pitches stay on top

Correlations are hard to picture, so I also counted it another way: rank each season's pitches (after subtracting the pitch-type average) and see how many of the top 20% are still in the top 20% next season. If the two seasons were unrelated, it would be about 20%.

With 400+ pitches in both seasons, about one in three top-20% run value pitches stayed in the top 20%, and 36% dropped to the bottom half (about 50% if unrelated). For whiff rate, only 12% dropped to the bottom half.

At 500 pitches, the correlation with next season is 0.68 for whiff rate and 0.20 for run value

If one season's number is "the pitch's true level + noise", then with n pitches the true level is roughly n / (n + k) of it, where k is the pitch count at which it is half signal, half noise. "Signal" here just means the part that is not chance.

The true level itself also changes a little from year to year. If c (at most 1) is how stable it is, the year-to-year correlation is c times the geometric mean of the two seasons' signal shares.

A reader suggested this model in a comment on this post, and later suggested reporting the correlation at a fixed pitch count rather than k. I sorted the 8,022 pairs by pitch count into 12 equal-size groups and searched for the c and k that best fit each group's correlation, using the actual pitch counts of the pairs in the group (weighted by group size). From those I computed the correlation when both seasons have the same n pitches, c * n / (n + k):

# expected correlation for one group of pairs with pitch counts n1, n2
r_pred = c * np.mean(np.sqrt(n1 / (n1 + k) * n2 / (n2 + k)))
# correlation when both seasons have n pitches
r_n = c * n / (n + k)

Whiff rate: 0.68 (95% interval from 200 resamples of pitchers: 0.65–0.70)
xwOBA allowed: 0.41 (0.38–0.44)
Run value: 0.20 (0.18–0.23)

500 pitches is close to one season of a reliever's main pitch or a starter's second pitch (2021–2025 medians: 463 for the most-used pitch of relievers with 40+ innings, 613 for the second pitch of starters with 100+ innings). A starter's main pitch over a full season is about 1,100 pitches (median 1,086.5 for the most-used pitch of the 316 pitcher-seasons with 2,400+ pitches in 2021–2025). Even there, run value reaches only 0.35 (0.27–0.39), about half of whiff rate at 500, with twice the pitches.

In terms of k, the pitch count at which half of a season is signal: about 100 for whiff rate (76–138) and about 300 for xwOBA allowed (176–498). Run value's fit gives about 1,800, but the interval runs from 455 to 2,212, and in 92 of the 200 resamples c sat at its cap of 1. Within the pitch counts in this data (at most about 2,300 for one pitch in one season), c and k cannot be told apart well. The correlation at a fixed pitch count does not have that problem: any (c, k) pair that fits the data traces nearly the same curve within this range, so its interval is much narrower than k's (0.18–0.23 at 500 pitches, 0.27–0.39 at about 1,100). An earlier version of this post led with k and said run value needs "at least 600" pitches; recomputed with 200 resamples, the lower end is 455.

The comment put run value's k at about 700. The bands use the smaller of the two seasons' pitch counts, so the other season had more pitches than that; fitting with both seasons' counts gives a larger k.

Splitting run value into parts

Why does run value carry over so little? I went down to pitch-level data.

According to the MLB glossary, run value adds up, pitch by pitch, how much each result (ball, strike, hit, out and so on) moved the expected runs. Pitch-level data carries that value as delta_run_exp (positive favors the batter). Summing it by pitcher, pitch type and season, flipping the sign and rounding to an integer matches Savant's published pitch-type run value on 99.2–99.7% of rows in every season. The rest differ by 1, and all of them have a fractional part near 0.5, where the rounding rule decides.

I then split each pitch's value into five parts that add back exactly to run value:

Mid-PA pitches: pitches that did not end the plate appearance (balls, strikes, fouls), the value of the count change
K / BB / HBP: plate appearances ending in a strikeout, walk or hit-by-pitch
Batted-ball quality: for balls in play, the value expected from exit velocity and launch angle (xwOBA) and the count
Batted-ball luck: for balls in play, actual minus expected: the same contact can be an out at a fielder or a hit through a gap
Base/out situation: the same count and result is worth different amounts with different runners and outs

The first four use values averaged over runners and outs: the mean over all pitches with the same season, count and result, and for batted-ball quality, the mean over batted balls with the same season, count and xwOBA (in 0.05 steps). "Result" is the plate appearance outcome (strikeout, single and so on) for a pitch that ended it, and the pitch call (ball, swinging strike and so on) otherwise.

The core of it looks like this (simplified: it leaves out batted balls without an xwOBA, the final sign flip to the pitcher's side and so on):

# mean by season, count and result = value averaged over runners and outs
P["cn"] = P.groupby(["season", "balls", "strikes", "result"]).delta_run_exp.transform("mean")
# for batted balls, the mean by season, count and xwOBA step is the "expected" value
P["cn_exp"] = P[bip].groupby(["season", "balls", "strikes", "xwoba_bin"]).cn.transform("mean")

P["midpa"]     = np.where(~end_of_pa, P.cn, 0)          # mid-PA pitches
P["pa_nonbip"] = np.where(end_of_pa & ~bip, P.cn, 0)    # K / BB / HBP
P["bip_exp"]   = np.where(bip, P.cn_exp, 0)             # batted-ball quality
P["bip_luck"]  = np.where(bip, P.cn - P.cn_exp, 0)      # batted-ball luck
P["situation"] = P.delta_run_exp - P.cn                 # base/out situation

One pitch at a time

To see what the split shows, I picked two top run value pitches of 2021 whose makeup differs clearly, and put them next to 2022. These are season totals in runs, not relative to the pitch-type average.

Adam Wainwright's sinker: +13 of its +20 runs in 2021 were batted-ball luck. Its whiff rate was 9.8%, below the 2021 sinker average (15.5%). In 2022 luck was still positive (+11), but batted-ball quality fell to −18, and the total was 0.

Corbin Burnes's cutter: in 2021 batted-ball luck was negative (−7), and strikeouts/walks plus mid-PA pitches alone were worth +34. In 2022 those two fell to +26, but luck swung to +11 and batted-ball quality was −10, so the total was +27.

For one pitch in one season, even the parts that rarely carry over sometimes do and sometimes don't. Two hand-picked examples prove nothing, so here are all the pitches.

All pitches

Pairs with 400+ pitches in both seasons (1,962 pairs), per 100 pitches, after subtracting the pitch-type average.

Each part's share of one season's run value variation (covariance of the part with run value divided by the variance of run value; the five add to 100%). Batted-ball luck is 27% and base/out situation 4%, about 30% together.

Year-to-year correlation of each part alone. Batted-ball luck (0.06) and situation (−0.03) barely carry over; K / BB / HBP (0.57) and mid-PA pitches (0.60) carry over well. Those two are only about 30% of one season's variation, but about 70% of the "high this year, high next year" link comes from them.

Dropping luck and situation predicts next season better

So I tried predicting next season's run value from the three parts that remain after dropping luck and situation. The prediction was fit on pairs whose second season is 2021 or earlier and checked on pairs whose second season is 2022 or later, so it is tested on years it did not see.

Just adding up the three parts correlates better with next season than this season's run value itself (0.29 → 0.35). Resampling pitchers 2,000 times, the 95% interval of that difference is 0.03 to 0.10 and does not include 0. Pairs with 100–399 pitches go the same way (0.12 → 0.18), though both are low.

Summary

In this data:

Whiff rate carries over well: the correlation with next season is 0.68 at 500 pitches, and about 100 pitches are enough for half of a season's number to be signal
Run value carries over little in one season: 0.20 at 500 pitches, and 0.35 even for a starter's main pitch over a season (about 1,100)
About 30% of one season's run value variation is batted-ball luck and base/out situation, which barely carry over
Adding up the other three parts predicts next season's run value better (0.29 → 0.35)

My personal take: when looking at one season of run value, it seems useful to look at whiff rate and strikeouts/walks alongside it to think about the next season.

Appendix

Terms

Whiff rate: share of swings that miss
xwOBA allowed: the value of plate appearances ending on that pitch, with batted balls replaced by their expected value from exit velocity and launch angle
Run value: the sum, pitch by pitch, of how much each pitch moved the expected runs (positive favors the pitcher)

Caveats

The correlations mix random noise and real change in the pitch (a new grip, lost velocity and so on)
Bands use the smaller of the two seasons' pitch counts, so a band also holds pairs where one season had many more pitches
Pairs touching the 60-game 2020 season are included
Pitchers who stopped pitching (or threw fewer than 100 of that pitch) after a bad year form no pair. That removes low first-season values, so the correlations may be slightly low
Savant's pitch arsenal table counts knuckle curves and slow curves as curveballs, and the pitch-level data follows it
Batted-ball luck is only actual minus expected from exit velocity, launch angle and count; defense and park are not separated out
The five-part split is my own choice; for example, whether the count is used in the batted-ball expectation moves the line between quality and luck a little

Code

The correlations are built with dbt, with a test that computes the same table another way. The run value split is computed with pandas from pitch-level data.

https://github.com/yasumorishima/mlb-data-pipeline

ABS Challenges from Triple-A to MLB: Catchers Win Most, and Batters Who Don't Chase Win More

YMori — Mon, 28 Sep 2026 02:11:16 +0000

In 2026 MLB started the ABS challenge, where a player can dispute a ball/strike call. Watching players tap their helmet or cap on broadcasts, I got curious: who wins these challenges, and where does the gap between good and bad challengers come from?

Triple-A used the same system a year earlier, in 2025, so there are records from before players reached MLB. With the regular season over, I looked at public data from Baseball Savant and MLB StatsAPI. I have no experience working in baseball; I just tallied up public data.

How ABS challenges work

According to MLB's announcement:

The plate umpire still calls every pitch. Only the batter, pitcher or catcher can challenge, and must do so immediately
Each team has two challenges per game; a failed challenge uses one up (a successful one does not)
Hawk-Eye tracking decides. The zone top is 53.5% of the player's height (without cleats), the bottom 27%, measured over the middle of the plate

A challenge wins (the call is overturned) when the tracked pitch was on the other side of the call.

Data

Two sources.

1. Baseball Savant's ABS challenge boards (per player)

Savant's ABS Challenges board lists each player's challenges and overturns, plus Savant's expected values: how many times an average player would challenge, and win, given the same opportunities as this player. The page's CSV export has no player id, so I added a function to my package savant-extras that reads the JSON embedded in the page:

import savant_extras as sx

# MLB 2026 regular-season catcher challenges, including players with none
df = sx.abs_challenges(2026, level="mlb", challenge_type="catcher",
                       game_type="regular", min_challenges=0)

I joined 15 boards (MLB and Triple-A; batters, pitchers and catchers; spring and regular season) on the player id, added season stats and Statcast aggregates (chase rate, framing and so on), and published the result on Kaggle (ABS Challenges: Triple-A 2025 to MLB 2026). The numbers here are from the final version, after the regular season.

2. MLB StatsAPI game feeds (pitch by pitch)

To see what kind of pitches were challenged, you need pitch-level data. In StatsAPI game feeds (feed/live, no key needed), a challenged pitch carries reviewDetails, so I extracted them from every 2026 regular-season game (2,402 games had a challenge).

There were three traps:

The pitch's details.call.description is the call after the review. The original call comes from who challenged (the batting side challenges strikes, the fielding side challenges balls)
The count on a pitch is the count after that pitch. The count before it comes from the previous pitch
When the final call ends the plate appearance (strikeout or walk), reviewDetails sits on the play, not on the pitch. Reading only the pitch misses all of those

I missed the third one at first, and found it when a breakdown by count said batters' challenges with two strikes won 100% of the time, which cannot be right: every failed challenge that would have ended in a strikeout was missing. Picking up both places in jq (excerpt):

.liveData.plays.allPlays[] as $p
| ($p.playEvents) as $ev
| (
    # the plate appearance went on: on the pitch
    ( range(0; $ev | length) as $i | select($ev[$i].reviewDetails.reviewType == "MJ")
      | {i: $i, rv: $ev[$i].reviewDetails} ),
    # the plate appearance ended: on the play; the challenged pitch is the last one
    ( select($p.reviewDetails.reviewType == "MJ")
      | ([range(0; $ev | length) | select($ev[.].isPitch == true)] | last) as $li
      | {i: $li, rv: $p.reviewDetails} )
  )

I checked the counts against Savant's board totals: 10,557 regular-season challenges, matching exactly, and by challenger 5,612 catcher (Savant 5,613), 4,766 batter (4,765) and 179 pitcher (179). Before fixing the third trap, 2,661 challenges (25%) were missing.

At every level, catchers win the most challenges

In the 2026 MLB regular season, catchers won 58.6% of 5,613 challenges, batters 48.9% of 4,765 and pitchers 39.7% of 179. Triple-A has the same order, with a 13-point gap between catchers and batters in 2026.

Pitchers rarely challenge; on the fielding side it is almost entirely the catcher's job.

Triple-A catchers went from 53.7% in 2025 to 57.9% in 2026. Batters stayed at 45% both years.

Why do catchers win more?

Catchers win 10 points more often than batters. Is it because they judge the calls better? I looked at what kind of pitches were challenged.

From the StatsAPI coordinates I computed how far the ball's surface was from the zone edge, and split challenges into three groups:

Call looks clearly wrong: at least an inch on the other side of the call (for example, a ball call on a pitch an inch or more inside the zone)
Within an inch of the edge
Call looks right: at least an inch on the called side

This is my own zone, and it differs from the ABS call near the edge (see the appendix). But pitches an inch or more from the edge were called "as they look" about 98% of the time or more, for catchers and batters alike, so the two outer groups are largely reliable.

38% of catchers' challenges were on pitches whose call looks clearly wrong, against 21% of batters'. The other way round, 16% of catchers' challenges were on calls that look right, against 36% of batters'.

I also swapped only the mix of pitches, keeping each group's win rate. If batters chose pitches in the catchers' mix, they would win 67.4%, more than catchers actually do (58.6%). If catchers chose in the batters' mix, they would win 40.7%. Either way, the difference in mix alone opens a gap bigger than the actual 10 points between catchers and batters. Most of the catchers' edge seems to come from choosing more pitches whose call looks clearly wrong. Catchers receive the ball in their mitt and see its location closest, which may make those pitches easier to pick.

On the hard pitches within an inch of the edge, batters won 64% and catchers only 46%. That group, though, is where my zone's error matters most (appendix), so I cannot say batters are better at judging the hard ones.

So why do batters challenge calls that look right? I looked at the situations.

By strikes before the pitch, batters won 59% with no strikes and 40% with two. Catchers won 61%, 62% and 53%, a smaller drop.

A called strike with two strikes is strike three if it stands. 34% of batters' challenges came in that spot (the same 1,619 challenges as the two-strike point above), and 40% won, 13.5 points below their challenges of other strike calls (53%).

45% of the strike-three challenges were on pitches whose call looks right (32% for other strike calls). When a strikeout is on the line, batters challenge more long shots.

Late in the game, from the 9th inning on, both catchers and batters won less often. The share of catchers' challenges on calls that look right rose from 13% in innings 1 to 6 to 28% from the 9th on.

This data alone does not say why. Unused challenges disappear at the end of the game, so teams may spend what is left; or late innings hold more high-leverage spots, where even a long shot is worth a challenge.

Among catchers, the share won ranges from 47% to 81%

These are the 44 MLB catchers with 60+ challenges in 2026. J.T. Realmuto won 70 of 86 (81%); Francisco Alvarez won 42 of 90 (47%).

Savant's expected values say how many times an average player would challenge, and win, given the same opportunities. Realmuto's expected challenge count was 138; he made 86, about 40% fewer than an average catcher. He may have saved them for pitches likely to win. Alvarez made 90 against an expected 81, a little more than average. Salvador Perez, second at 46 of 65 (71%), made exactly as many challenges as expected (65).

With 60 to 90 challenges per catcher, chance is not small. Using the catchers' overall 58.6%, the binomial probability of winning 70 or more of 86 is below 1 in 100,000, and about 0.03% that any of 44 catchers would. Realmuto is hard to explain by chance. Winning 42 or fewer of 90 has a probability of 1.5%, or 49% that at least one of 44 catchers would; Alvarez's low number is well within what chance produces.

Across the 44, catchers who challenged less than expected tended to win more often (Spearman −0.26, p = 0.09), but the trend is not clear.

Batters who chase less win more challenges

I split the 465 MLB batters with 100+ plate appearances in Statcast into thirds by chase rate (swings at pitches outside the zone). From the least to the most chasing, they won 51.3%, 48.0% and 45.7% of their challenges. Among the 182 with 10+ challenges, the rank correlation between chase rate and share won is −0.20 (p = 0.008).

Do batters with a good eye judge calls better? As with catchers, I split their challenges into the three groups (4,603 challenges from the three thirds):

Challenges of calls that look right: 33% for the least chasing third, 37% in the middle, 39% for the most chasing
Challenges of calls that look clearly wrong: 22%, 21%, 19%
Win rates within each group are about the same across the thirds (63% to 64% within an inch of the edge)

So the difference is that batters who chase less challenge fewer calls that look right and slightly more that look clearly wrong. There is no clear difference in judging the hard pitches near the edge.

How often a batter challenges is nearly unrelated to chase rate (Spearman −0.04, 465 batters).

By name, Taylor Ward, with the lowest chase rate (15%), won 8 of 15 (53%); Ceddanne Rafaela, with the highest (45%), won 6 of 24 (25%).

Stealing strikes and winning challenges are different skills

Catchers can make balls look like strikes: framing. Savant's official framing is MLB-only, so I computed, per catcher from pitch-level Statcast, the share of out-of-zone takes called strikes. That works in Triple-A too.

As the left panel shows, in MLB 2026 it has a rank correlation of 0.83 with official framing runs (56 catchers), good enough as a stand-in (Triple-A has no official number, so I cannot check the fit there).

But it is almost unrelated to challenge skill (Savant's challenges vs expected, see the appendix), as the right panel shows: 0.03 in MLB 2026, 0.08 in Triple-A 2026 and 0.14 in Triple-A 2025, none significant. Making a ball look like a strike and spotting a wrong call worth disputing seem to be different skills.

What carries up from Triple-A is how often a player challenges

I compared the same players in Triple-A 2025 and MLB 2026 (63 batters and 51 catchers with 5+ challenges in both):

How often they challenge carries over clearly (Spearman 0.37 for batters, 0.45 for catchers)
Share won carries over for batters (0.32, p = 0.01); for catchers it is 0.24 (p = 0.10)
Savant's challenges vs expected (the net against an average player given the same opportunities) does not: 0.05 for batters and 0.21 for catchers, neither clear

Chase rate itself carries over strongly (0.68). As in the previous section, batters who chase less challenge fewer calls that look right, so the carry-over in share won may come from there (I did not check this). For example, Gary Sánchez challenged at 16% in Triple-A 2025 (7 challenges) and 16% in MLB 2026 (37).

No clear age difference

Split into four age groups, MLB 2026 batters aged 34 and over won 54.2%, higher than the rest. But that is 34 batters and 334 challenges, and the interval (48.8% to 59.5%) overlaps the other groups. Savant's challenges vs expected per batter is −0.23 for 25 and under, +0.29 for 26 to 29, −0.30 for 30 to 33 and +0.73 for 34 and over, with no ordering by age. There is no clear age effect.

Summary

In this data:

At both MLB and Triple-A, catchers win the most challenges (58.6% in MLB 2026, batters 48.9%)
Most of that gap seems to come from catchers choosing more pitches whose call looks clearly wrong (38% vs 21%). Batters challenge more calls that look right with two strikes, especially on called strike three
Late in the game, more challenges go to calls that look right, and fewer win
Catchers differ a lot: Realmuto challenged about 40% less than expected and won 70 of 86
Batters who chase less win more, because they challenge fewer calls that look right and slightly more that look clearly wrong
Framing and challenge skill are different things
What carries from Triple-A to MLB is how often a player challenges; whether skill carries is unclear

Appendix

Terms

Expected values (Savant): how many times an average player would challenge (exp_chal) and win (exp_chal_gained) given the same opportunities as this player. They are not computed for the pitches the player chose. "Challenges vs expected" here is Savant's overturns_vs_exp: the net of overturns and failures against expectation, minus the same for challenges made against the player's side. It mixes how often and how well a player challenges
Challenge rate: challenges ÷ the opportunities Savant counts for the player (n_total_sample)
Chase rate: share of pitches outside the zone that the batter swung at (Statcast)
Rank correlation: Spearman's

Caveats

Everything here is correlation, not causation
The "distance from the zone edge" in the pitch-level sections is my own, from StatsAPI coordinates (measured at the front of the plate) and the zone top and bottom in StatsAPI. The zone top and bottom were constant per batter in 2026, but ABS judges over the middle of the plate, so my zone differs from the actual call near the edge. Within an inch of my edge, 64% of batters' and 46% of catchers' challenges were overturned, so the error may lean against catchers. An inch or more from the edge, 97.9% to 99.7% of calls went the way they look
Individual players' shares swing a lot with few challenges. The named players' numbers are one season's results

Data and code

Dataset: https://www.kaggle.com/datasets/yasunorim/mlb-abs-challenges-aaa-2025-to-mlb-2026 (DOI: 10.34740/kaggle/dsv/20077454)
Notebook: ABS Challenges: Who Wins Them, AAA to MLB
Build code: https://github.com/yasumorishima/kaggle-datasets (abs-challenges-dataset/)
Sources: Baseball Savant / MLB StatsAPI (MLB Advanced Media)
Japanese version: Qiita

Rewritten on 2026-09-30 with pitch-level data for the full regular season. An earlier version described Savant's expected values as accounting for the difficulty of the challenged pitches, and said older batters were below expected; Savant's expected values are for an average player given the same opportunities, and that "below expected" figure mixed two denominators.

M5 StackChan pairing fails with No devices found — the factory firmware is the cause

YMori — Sat, 25 Jul 2026 09:00:55 +0000

TL;DR

I bought the official M5Stack StackChan (M5STACK-K151), and the "StackChan World" mobile app refused to finish setup: after selecting the device, it showed No devices found.

The cause was not Bluetooth permissions and not an app bug — the factory firmware was simply too old. After flashing the latest official firmware over USB, pairing went through on the first attempt.

What makes this worth writing about is that the situation is a closed loop you cannot escape on the device itself:

New firmware arrives via OTA
OTA needs Wi-Fi
Wi-Fi setup needs app pairing
Pairing fails on the old firmware

So flashing over USB is the only way out.

Environment and dates


Product	M5StackChan AI Desktop Robot (ESP32-S3) / `M5STACK-K151` (official assembled unit)
Purchased	2026-07-24 (Switch Science, Japan)
Setup attempted	2026-07-25
Factory firmware on the unit	1.2.4 (released 2026-04-20)
Latest official firmware that day	1.4.4 (released 2026-07-13)
Host	Windows 11
Phone	Android

The dates matter here. This product launched in 2026-05 and both the firmware and the app are still being updated frequently. The firmware version that ships with a unit depends on when you buy it, so whether you hit this problem depends on timing. If you buy stock that has been sitting for a few months, you are a good candidate for the same trap.

The symptom

The setup flow is:

Power on, pass the servo test
The device shows a 12-digit ID
In the app: "Add a new StackChan" → scan for nearby devices
Pick the entry matching the ID on the device screen
Set device name → AI agent → Wi-Fi

Step 4 immediately produced No devices found, and step 5 was never reachable.

What did not help

The message talks about devices not being found, so of course I attacked discovery first. None of this changed anything:

Granting Bluetooth and location permissions to the app (verified from the OS settings, not just the in-app prompt)
Turning location services on (BLE scanning on Android is entangled with location)
Force-stopping and restarting the app, rebooting the phone
Rebooting the device, returning to the ID screen before scanning
Toggling Bluetooth off and on

One thing I learned the hard way: do not pair from the OS Bluetooth settings screen. If you bond the device at the OS level, it gets registered as a known device and disappears from the app's "find a new device" list. I did exactly this while "just checking", which made the picture even muddier. If you already did it, remove the pairing.

The serial log told a completely different story

I stopped guessing about permissions and captured the USB serial log. When you connect the unit to a PC, the CoreS3 (ESP32-S3) native USB shows up as a serial port (VID_303A / PID_1001, USB-Serial/JTAG).

Here is what the log showed while the app was "not finding" anything:

I (111140) NimBLE: connection established; status=0
I (111160) NimBLE:  peer_ota_addr_type=1 peer_ota_addr=
I (111160) NimBLE: 63:a2:04:c7:fa:5d
[info] [WifiConfigServer] app Connected
I (112260) NimBLE: Stack-Chan characteristic write; conn_handle=1 attr_handle=22
I (112260) NimBLE: Config data received (42 bytes): {"cmd":"handshake","data":"1784964126892"}
I (112420) NimBLE: GATT procedure initiated: notify;
I (112430) NimBLE: notify_tx event; conn_handle=1 attr_handle=22 status=0 is_indication=0
I (112440) NimBLE: Config notification sent

Reading that:

The BLE connection was established (status=0)
The app was connected (app Connected)
The app sent a handshake ({"cmd":"handshake"})
The device answered (Config notification sent)
And then nothing more arrives from the app — not even a disconnect

So No devices found did not describe reality. The process was not failing at discovery; it was failing at verification of the response the device sent back. Trusting that message is what sent me down the permissions rabbit hole.

For confirmation I read the app side too. The firmware, the app, and the server for StackChan are all published in m5stack/StackChan — the Flutter app source lives in the same repository. The device-selection screen has a 30-second connect timeout and a 20-second verification timeout, with failure messages such as Device did not return encryption data. and Device verification decryption failed., and it registers the device with the server only after verification succeeds.

Root cause: firmware version, plus a deadlock

The boot log prints the version:

I (690) app_init: Project name:     stack-chan
I (696) app_init: App version:      1.2.4
I (700) app_init: Compile time:     Apr 15 2026 09:18:33

1.2.4, while the latest official build that day was 1.4.4 — nine versions apart.

And that is where the loop from the top of this post bites: OTA needs Wi-Fi, Wi-Fi needs pairing, pairing fails on old firmware. USB is the only remaining path.

Note that building the firmware yourself does not help. The handshake implementation in the public repository (firmware/main/hal/utils/secret_logic/secret_logic.cpp) is a stub whose token function returns a fixed string. It is declared as a weak symbol, and the real implementation is linked in at official build time. Only the official binary can satisfy the app's verification step.

The fix: flash the official firmware over USB, without M5Burner

The official flashing tool is M5Burner (a GUI), but the firmware distribution API it uses is public, so the whole thing can be done from the CLI. No Python required either.

1. List the official firmware versions

curl -s "https://m5burner-api.m5stack.com/api/firmware" \
  | jq -r '.[] | select(.name=="StackChan-UserDemo") | .versions[] | "\(.version)  \(.published_at)  \(.file)"'

The factory firmware is named StackChan-UserDemo (author: M5Stack):

V1.2.4   2026-04-20  3c8ffe6be0ca26375d836e10e06e3609.bin
V1.4.3   2026-07-02  fb75fa818e63b7ee6b0d35eba308f386.bin
V1.4.4   2026-07-13  790e3fcde496020aa7f188153b23e6f0.bin

Older versions stay available, so rolling back is possible too — which makes updating a lot less scary.

2. Download the binary

curl -sL "https://m5burner-cdn.m5stack.com/firmware/790e3fcde496020aa7f188153b23e6f0.bin" \
  -o stackchan-v1.4.4.bin

If the first byte is e9 (the ESP image magic), it is a merged full image to be written at offset 0x0:

od -An -tx1 -N 1 stackchan-v1.4.4.bin
#  e9

3. Get esptool (no Python needed)

Espressif ships standalone executables:

gh api repos/espressif/esptool/releases/latest \
  --jq '.assets[] | select(.name|test("windows-amd64")) | .browser_download_url'

4. Verify communication with a read-only command first

.\esptool.exe --port COM3 flash-id

Detecting chip type... ESP32-S3
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
USB mode:           USB-Serial/JTAG
Detected flash size: 16MB

No manual download mode was necessary — esptool resets the chip through USB-Serial/JTAG. If it cannot connect, hold the reset button for about 2 seconds and release it once the internal green LED lights up.

5. Flash

.\esptool.exe --port COM3 write-flash 0x0 stackchan-v1.4.4.bin

Wrote 12783792 bytes (3185393 compressed) at 0x00000000 in 47.7 seconds
Verifying written data...
Hash of data verified.

About 50 seconds for just under 12.8 MB.

6. Confirm the version

Look for app_init: App version: 1.4.4 in the boot log. With that in place, pairing succeeded on the first try, and I went straight through AI agent setup, Wi-Fi setup, and an actual voice conversation.

Other traps worth knowing

Opening the serial port reboots the device

rst:0x15 (USB_UART_CHIP_RESET),boot:0x2b (SPI_FAST_FLASH_BOOT)

You cannot capture logs and operate the device at the same time. Opening the port in the middle of the setup wizard sends you back to the start (it did for me). The flip side is useful: if you want the boot log from the very first line, open the port and then trigger a reset.

There is no interactive serial console

Sending commands produces no response, and the write itself blocks. Treat the serial port as read-only.

Do not power both USB-C ports at once

The unit has a USB-C port on the CoreS3 and another on the heel (base). 5V fed into the CoreS3 side is routed to the base through the M-BUS BUS_5V line, so powering both ports puts two supplies on the same rail. The official documentation's "try powering from both ports" means one at a time. The heel port is the recommended one for power and flashing.

Servo zero positions survive a full flash erase

I backed up NVS before flashing, but the same zero positions were read back afterwards ([ScsServo] id: 1 get zero pos: 460 from settings). Those values appear to live in the servos themselves, so a full-flash rewrite does not lose them.

A separate warning about charging

The firmware sets the AXP2101 charge current to 700mA at boot:

auto ret = setChargerConstantCurr(XPOWERS_AXP2101_CHG_CUR_700MA);

The ESP32-S3 enumerates as a USB 2.0 device, so a PC USB port gives you 500mA at most. Combined with the system draw (LCD, camera, servos, radio) that exceeds the input limit, and charging never starts from a PC port. Use a USB charger with headroom at 5V.

If the servos do not report their current position ([ScsServo] ignore invalid current pos: -1), read that as another sign of insufficient power.

Takeaways

No devices found did not describe what was happening. The BLE connection and the handshake both succeeded; the failure was in response verification
The real cause was old factory firmware, fixed by flashing the latest official build over USB
OTA ↔ Wi-Fi ↔ pairing form a loop, so USB flashing is the only exit
Do not over-trust the error string — capture the log. Every minute I spent re-checking permissions would have been saved by one serial capture

Scripts and the full write-up are in the repository:

https://github.com/yasumorishima/stackchan-lab

References

Official docs: https://docs.m5stack.com/en/stackchan
Firmware / app / server source: https://github.com/m5stack/StackChan

M5 StackChan pairing fails with \"No devices found\"? The factory firmware is the cause

YMori — Sat, 25 Jul 2026 08:48:29 +0000

TL;DR

I bought the official M5Stack StackChan (M5STACK-K151), and the "StackChan World" mobile app refused to finish setup: after selecting the device, it showed No devices found.

What makes this worth writing about is that the situation is a closed loop you cannot escape on the device itself:

New firmware arrives via OTA
OTA needs Wi-Fi
Wi-Fi setup needs app pairing
Pairing fails on the old firmware

So flashing over USB is the only way out.

Environment and dates


Product	M5StackChan AI Desktop Robot (ESP32-S3) / `M5STACK-K151` (official assembled unit)
Purchased	2026-07-24 (Switch Science, Japan)
Setup attempted	2026-07-25
Factory firmware on the unit	1.2.4 (released 2026-04-20)
Latest official firmware that day	1.4.4 (released 2026-07-13)
Host	Windows 11
Phone	Android

The symptom

The setup flow is:

Power on, pass the servo test
The device shows a 12-digit ID
In the app: "Add a new StackChan" → scan for nearby devices
Pick the entry matching the ID on the device screen
Set device name → AI agent → Wi-Fi

Step 4 immediately produced No devices found, and step 5 was never reachable.

What did not help

The message talks about devices not being found, so of course I attacked discovery first. None of this changed anything:

Granting Bluetooth and location permissions to the app (verified from the OS settings, not just the in-app prompt)
Turning location services on (BLE scanning on Android is entangled with location)
Force-stopping and restarting the app, rebooting the phone
Rebooting the device, returning to the ID screen before scanning
Toggling Bluetooth off and on

The serial log told a completely different story

Here is what the log showed while the app was "not finding" anything:

I (111140) NimBLE: connection established; status=0
I (111160) NimBLE:  peer_ota_addr_type=1 peer_ota_addr=
I (111160) NimBLE: 63:a2:04:c7:fa:5d
[info] [WifiConfigServer] app Connected
I (112260) NimBLE: Stack-Chan characteristic write; conn_handle=1 attr_handle=22
I (112260) NimBLE: Config data received (42 bytes): {"cmd":"handshake","data":"1784964126892"}
I (112420) NimBLE: GATT procedure initiated: notify;
I (112430) NimBLE: notify_tx event; conn_handle=1 attr_handle=22 status=0 is_indication=0
I (112440) NimBLE: Config notification sent

Reading that:

The BLE connection was established (status=0)
The app was connected (app Connected)
The app sent a handshake ({"cmd":"handshake"})
The device answered (Config notification sent)
And then nothing more arrives from the app — not even a disconnect

Root cause: firmware version, plus a deadlock

The boot log prints the version:

I (690) app_init: Project name:     stack-chan
I (696) app_init: App version:      1.2.4
I (700) app_init: Compile time:     Apr 15 2026 09:18:33

1.2.4, while the latest official build that day was 1.4.4 — nine versions apart.

And that is where the loop from the top of this post bites: OTA needs Wi-Fi, Wi-Fi needs pairing, pairing fails on old firmware. USB is the only remaining path.

The fix: flash the official firmware over USB, without M5Burner

The official flashing tool is M5Burner (a GUI), but the firmware distribution API it uses is public, so the whole thing can be done from the CLI. No Python required either.

1. List the official firmware versions

curl -s "https://m5burner-api.m5stack.com/api/firmware" \
  | jq -r '.[] | select(.name=="StackChan-UserDemo") | .versions[] | "\(.version)  \(.published_at)  \(.file)"'

The factory firmware is named StackChan-UserDemo (author: M5Stack):

V1.2.4   2026-04-20  3c8ffe6be0ca26375d836e10e06e3609.bin
V1.4.3   2026-07-02  fb75fa818e63b7ee6b0d35eba308f386.bin
V1.4.4   2026-07-13  790e3fcde496020aa7f188153b23e6f0.bin

Older versions stay available, so rolling back is possible too — which makes updating a lot less scary.

2. Download the binary

curl -sL "https://m5burner-cdn.m5stack.com/firmware/790e3fcde496020aa7f188153b23e6f0.bin" \
  -o stackchan-v1.4.4.bin

If the first byte is e9 (the ESP image magic), it is a merged full image to be written at offset 0x0:

od -An -tx1 -N 1 stackchan-v1.4.4.bin
#  e9

3. Get esptool (no Python needed)

Espressif ships standalone executables:

gh api repos/espressif/esptool/releases/latest \
  --jq '.assets[] | select(.name|test("windows-amd64")) | .browser_download_url'

4. Verify communication with a read-only command first

.\esptool.exe --port COM3 flash-id

Detecting chip type... ESP32-S3
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
USB mode:           USB-Serial/JTAG
Detected flash size: 16MB

5. Flash

.\esptool.exe --port COM3 write-flash 0x0 stackchan-v1.4.4.bin

Wrote 12783792 bytes (3185393 compressed) at 0x00000000 in 47.7 seconds
Verifying written data...
Hash of data verified.

About 50 seconds for just under 12.8 MB.

6. Confirm the version

Other traps worth knowing

Opening the serial port reboots the device

rst:0x15 (USB_UART_CHIP_RESET),boot:0x2b (SPI_FAST_FLASH_BOOT)

There is no interactive serial console

Sending commands produces no response, and the write itself blocks. Treat the serial port as read-only.

Do not power both USB-C ports at once

Servo zero positions survive a full flash erase

A separate warning about charging

The firmware sets the AXP2101 charge current to 700mA at boot:

auto ret = setChargerConstantCurr(XPOWERS_AXP2101_CHG_CUR_700MA);

If the servos do not report their current position ([ScsServo] ignore invalid current pos: -1), read that as another sign of insufficient power.

Takeaways

No devices found did not describe what was happening. The BLE connection and the handshake both succeeded; the failure was in response verification
The real cause was old factory firmware, fixed by flashing the latest official build over USB
OTA ↔ Wi-Fi ↔ pairing form a loop, so USB flashing is the only exit
Do not over-trust the error string — capture the log. Every minute I spent re-checking permissions would have been saved by one serial capture

Scripts and the full write-up are in the repository:

https://github.com/yasumorishima/stackchan-lab

References

Official docs: https://docs.m5stack.com/en/stackchan
Firmware / app / server source: https://github.com/m5stack/StackChan

My Raspberry Pi 5 Kept Vanishing From the Network — Diagnosing With journalctl and Fixing It With a Watchdog

YMori — Tue, 23 Jun 2026 14:33:34 +0000

The symptom

I run a headless Raspberry Pi 5 (over Wi-Fi) via SSH and Tailscale. Every so often it would stay powered on (LED lit) but completely vanish from the network:

SSH over LAN → timeout
SSH over Tailscale → timeout
RDP → timeout

And it kept recurring — every time I "fixed" it by power-cycling. Here is how I actually diagnosed it and set up auto-recovery.

Step 1: `tailscale status` tells you device-side vs your-side

When SSH hangs, it's tempting to assume "the Pi died." But the problem can be on your side (your PC's Wi-Fi / VPN). Rule that out first.

If you use Tailscale, tailscale status is the fastest check:

100.x.y.z   raspberrypi   user@   linux   active; relay "..."; offline, last seen 1h ago, tx 124956 rx 0

The key is the peer line: offline, last seen 1h ago. This comes from Tailscale's coordination server — it's a third-party fact, independent of your own SSH attempt.

peer offline → the Pi really did drop off the network
peer active/online → it's your side that's broken (your VPN/network)

last seen also tells you when it dropped. tx ... rx 0 means "you're sending, but getting zero bytes back."

Confirm your own side is healthy too via tailscale status --json → BackendState=Running / Self.Online=true.

Step 2: After recovery, read `journalctl -b -1` (the previous boot)

This is the part people miss. While the Pi is off the network you obviously can't pull its logs — you read them after it's back. But the moment you reboot, the "current boot" is brand new, so journalctl (default) and dmesg won't contain the moment it dropped.

The drop is in the previous boot:

# tail of the previous boot
journalctl -b -1 --no-pager | tail -30

# only wlan0 / network-related lines
journalctl -b -1 --no-pager | grep -iE "wlan0|cfg80211|brcmfmac|LinkChange|network is unreachable" | tail -40

What I found, in order:

19:57  avahi-daemon: Withdrawing address record ... on wlan0   # IPv6 address flapping
20:08  tailscaled: LinkChange: major, rebinding ... rebind-reason=[time-jumped(13m50s),ips-changed,protocols-changed]
22:06  tailscaled: ... connect: network is unreachable          # fully down

The important part: the logs kept flowing the whole time. So this was not a full OS freeze or OOM — only the wlan0 / network layer dropped while the OS stayed alive (no oom, no panic at the tail of journalctl -b -1).

I couldn't pin the root trigger (why wlan0 dropped) from the logs — there was no explicit driver crash line, and vcgencmd get_throttled read 0x0 after recovery (no undervoltage flag). So from here it's a symptomatic fix for wlan0 drops in general.

The fix: a NetworkManager watchdog

If "the OS is alive but only the network is down," then a cron job that watches for it and restarts networking can auto-recover. Recent Pi OS uses NetworkManager (resolv.conf says # Generated by NetworkManager), so restart that.

/home/pi/.local/bin/net-watchdog.sh:

#!/usr/bin/env bash
# If the gateway is unreachable, restart NetworkManager to bring wlan0 back.
GATEWAY=192.168.1.1   # replace with your router IP
LOG=/home/pi/logs/net-watchdog.log
if ping -c 3 -W 3 "$GATEWAY" >/dev/null 2>&1; then
  exit 0
fi
echo "$(date -Is) gateway $GATEWAY unreachable, restarting NetworkManager" >> "$LOG"
systemctl restart NetworkManager

/etc/cron.d/net-watchdog (every 3 minutes, as root):

*/3 * * * * root /home/pi/.local/bin/net-watchdog.sh

Install:

chmod +x /home/pi/.local/bin/net-watchdog.sh
mkdir -p /home/pi/logs
echo "*/3 * * * * root /home/pi/.local/bin/net-watchdog.sh" | sudo tee /etc/cron.d/net-watchdog

Verify it does NOT restart when the network is fine

You don't want spurious restarts. Run it once by hand while the network is healthy:

/home/pi/.local/bin/net-watchdog.sh
echo $?        # → 0
cat /home/pi/logs/net-watchdog.log   # → no such file (= it did not restart anything)

While ping succeeds, nothing is logged and systemctl restart never runs. It only acts when the network is actually down.

Takeaways

"Powered on but gone from the network" is usually a network-layer drop — the OS is still alive.
Fastest triage: tailscale status (third-party offline record) → after recovery, journalctl -b -1 (the previous boot).
A gateway-ping → restart-NetworkManager watchdog in cron auto-recovers within minutes, as long as the OS keeps running.
Caveat: a cron-driven watchdog can't help if the OS itself stops executing.

I still haven't pinned the root cause, but at least I'm out of the "power-cycle it by hand every time" loop.

Follow-up: a selective outage the watchdog couldn't see — and watchdog v2

About two weeks after deploying the watchdog above, the Pi died in a completely different way — and since the gateway ping still succeeded, the watchdog never fired.

The symptom (nothing like last time)

SSH (over Tailscale) worked fine
Ping to the gateway worked fine
But DNS resolution was completely dead (getent hosts github.com failed)
Behavior differed per destination:
- Google properties returned HTTPS 200
- GitHub / Cloudflare (1.1.1.1) / everything else → TCP connect timeout
- IPv6 was entirely dead

With "only Google works," it looks like an ISP or router outage. Spoiler: it was the Pi itself again — a wedged wlan0 Wi-Fi client state.

Triage 1: hit the same destinations from another device on the same router (the decisive check)

From a PC on the same Wi-Fi, GitHub and everything else worked normally. → The router and the ISP are innocent; the problem is Pi-specific. Skipping this check would have sent me down the useless "reboot the router" path.

Triage 2: probe each DNS server directly over UDP

No dig or nslookup on the Pi? A few lines of python3 can send a raw DNS query:

import socket, struct

def q(server, timeout=3):
    # minimal DNS A query for github.com
    pkt = struct.pack('>HHHHHH', 0x1234, 0x0100, 1, 0, 0, 0)
    for part in b'github com'.split():
        pkt += bytes([len(part)]) + part
    pkt += b'\x00' + struct.pack('>HH', 1, 1)
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.settimeout(timeout)
    try:
        s.sendto(pkt, (server, 53))
        data, _ = s.recvfrom(512)
        return f'OK answers={struct.unpack(">H", data[6:8])[0]}'
    except Exception as e:
        return f'FAIL {type(e).__name__}'
    finally:
        s.close()

for srv in ['192.168.1.1', '100.100.100.100', '8.8.8.8', '1.1.1.1']:
    print(srv, '->', q(srv))

Result: router=FAIL / Tailscale MagicDNS=FAIL / 8.8.8.8=OK / 1.1.1.1=FAIL. So DNS wasn't "down" — traffic to specific destinations was down, and DNS failure was just one symptom. ip route get and the firewall were both normal.

The fix: a full wlan0 reconnect (`reapply` is not enough)

nmcli dev reapply wlan0 (re-applying the config) did not fix it. What fixed it was a full disconnect → connect. Since SSH itself rides on wlan0, detach the command so it survives your own disconnection:

sudo nohup bash -c 'nmcli dev disconnect wlan0; sleep 3; nmcli dev connect wlan0' >/dev/null 2>&1 &

About 20 seconds later everything was back: all destinations 200, and the router DNS that had "looked dead" was answering again. The DNS death, the selective timeouts, and the IPv6 blackout were all symptoms of one root cause: the wedged wlan0 client state.

watchdog v2: also probe external connectivity

Gateway ping alone misses this failure mode, so I added a second tier:

#!/bin/bash
# net-watchdog v2: two-tier self-healing
# tier1: gateway unreachable -> restart NetworkManager
# tier2: gateway OK but external connectivity mostly dead (<2 of 4 probes) -> full wlan0 reconnect
LOG=/home/pi/logs/net-watchdog.log
STATE=/home/pi/logs/net-watchdog.last-reconnect
GW=192.168.1.1   # replace with your router IP
mkdir -p /home/pi/logs

if ! ping -c3 -W3 $GW >/dev/null 2>&1; then
  echo "$(date -Is) gateway unreachable -> restart NetworkManager" >> $LOG
  systemctl restart NetworkManager
  exit 0
fi

alive=0
for url in https://www.google.com https://github.com https://1.1.1.1 https://www.yahoo.co.jp; do
  curl -4 -sS --max-time 5 -o /dev/null "$url" 2>/dev/null && alive=$((alive+1))
done

if [ "$alive" -lt 2 ]; then
  now=$(date +%s)
  last=$(cat "$STATE" 2>/dev/null || echo 0)
  if [ $((now - last)) -lt 1800 ]; then
    echo "$(date -Is) external dead (alive=$alive/4) but reconnected <30min ago, skip" >> $LOG
    exit 0
  fi
  echo "$now" > "$STATE"
  echo "$(date -Is) gateway OK but external dead (alive=$alive/4) -> wlan0 reconnect" >> $LOG
  nmcli dev disconnect wlan0
  sleep 3
  nmcli dev connect wlan0
fi
exit 0

Design notes:

2 of 4 independent probes alive = healthy — a single site being down never triggers a reconnect
https://1.1.1.1 is IP-literal, so this probe still works when DNS is dead
Reconnects have a 30-minute cooldown (no flapping)
As with v1: run it by hand while healthy and confirm it does nothing before wiring it into cron

Follow-up takeaways

A gateway-ping watchdog is blind to "selective outage caused by a wedged Wi-Fi client state"
"Only some sites work" looks like an ISP problem but can be your own device. The fastest triage is hitting the same destinations from another device on the same LAN
nmcli dev reapply and a full disconnect/connect are different things — escalate to the full reconnect when reapply doesn't cut it

I Had Claude Fable 5 Review My Indie Diary App Before It Got Pulled — The Bugs It Caught

YMori — Mon, 15 Jun 2026 13:00:53 +0000

Intro

I had Claude Fable 5 review and fix my Flutter diary app, Daily Diary (live on Google Play), before a release. This is a record of that.

Fable 5 was pulled worldwide just three days after launch (June 9 -> June 12, 2026) by a US Commerce Department export-control directive — but I got this pass in right before it went dark. Instead of generic "it caught what other models missed" claims, I'm pasting the actual diffs from my repo's commit history.

The app: Daily Diary

A simple offline diary app.

📱 Offline-first: data stays on the device, no cloud
🌐 5 languages: Japanese / English / Chinese / Korean / Spanish
🌙 Dark mode, 📅 calendar with mood indicators, 📊 stats (streaks, mood trends), 🔍 full-text search, 🎲 random past entry, 💾 JSON export/import
Google Play: https://play.google.com/store/apps/details?id=com.diary.daily

Stack: Flutter 3.x / Dart, Provider, Hive (local NoSQL), Flutter intl.

What I asked for

Not "rewrite everything" — more like "find and fix what's questionable quality-wise": resolve flutter analyze warnings (there were 47), set up tests, add CI, update dependencies.

1. BuildContext used across an async gap

Several spots touched BuildContext (Navigator, localization) after an await. If the widget is disposed during the await, that throws. Fable inserted if (!mounted) return; right after the await:

   final db = DatabaseService();
   final existingEntry = await db.getEntryByDate(_selectedDate);
+  if (!mounted) return;

   final result = await Navigator.push(
     context,

You rarely hit this in normal use, so it's easy to miss even when testing yourself.

2. Hoisting the l10n lookup before the await

In the import handler _importData, AppLocalizations.of(context) (localized strings) was looked up repeatedly after awaits. It got hoisted to a single lookup before the first await, with a mounted guard before showing the confirmation dialog:

       _isImporting = true;
     });
+
+    final l10n = AppLocalizations.of(context)!;

     try {
       final result = await FilePicker...
       ...
       if (file.bytes == null) {
-        final l10n = AppLocalizations.of(context)!;   // looked up after await
         throw Exception(l10n.fileReadError);
       }
       ...
-      final l10n = AppLocalizations.of(context)!;
+      if (!mounted) return;                            // guard before dialog

3. The test that tested nothing

The leftover template widget_test.dart referenced a non-existent MyApp and didn't even compile (= effectively zero tests). It was removed and replaced with 12 real tests for the model and Hive persistence:

removed test/widget_test.dart             (broken template)
added  test/diary_entry_test.dart   +49   (model serialization, etc.)
added  test/database_service_test.dart +92 (Hive-backed save/load)

"You think you have tests, you don't" is the scariest state to be in, so fixing this mattered most.

4. 47 analyzer warnings to zero

The headline one was the Color.withOpacity() deprecation (withValues is now preferred for color precision). 27 spots replaced:

-  color: Colors.white.withOpacity(0.1),
+  color: Colors.white.withValues(alpha: 0.1),

Plus removing the deprecated ColorScheme.background / onBackground, and migrating RadioListTile (groupValue / onChanged removed) to the RadioGroup ancestor API. dart fix --apply handled the mechanical ones; API migrations were done by hand.

5. Major dependency bumps

Bumped the main dependencies, with two breaking API changes:

-  google_mobile_ads: ^4.0.0
+  google_mobile_ads: ^9.0.0
-  share_plus: ^7.2.1
-  file_picker: ^8.1.4
+  share_plus: ^12.0.2
+  file_picker: ^11.0.2

share_plus: Share.shareXFiles(...) -> SharePlus.instance.share(ShareParams(...)).

-  await Share.shareXFiles(
-    [XFile(file.path)],
-    subject: fileName,
+  await SharePlus.instance.share(
+    ShareParams(
+      files: [XFile(file.path)],
+      subject: fileName,
+    ),
   );

file_picker: the instance API FilePicker.platform.pickFiles(...) became a static FilePicker.pickFiles(...).

-  final result = await FilePicker.platform.pickFiles(
+  final result = await FilePicker.pickFiles(

On the pins: share_plus 13 conflicts with file_picker 11, and file_picker 12 is beta-only — so I settled on share_plus 12 / file_picker 11.

6. Added CI

A new flutter-ci.yml runs flutter analyze + tests on push/PR, so the project can't slip back into the "broken test" state.

How it felt as a solo dev

Honestly, what Fable caught wasn't flashy features — it was the class of things I systematically don't check on my own:

async-gap mounted -> only crashes on certain timing
a broken test -> you think you have tests, you don't
a pile of deprecations -> works now, breaks later
stale dependencies -> major bumps get postponed out of fear of breaking changes

I can write the features myself, but "only fails under specific conditions," "are the tests actually testing anything," and "deprecated-API + dependency housekeeping" tend to slip without a dedicated reviewer. One thorough pass on that was genuinely useful for a side project.

There are limits too: device-UI-dependent behavior (ads, export/import sharing) can't be verified in CI — I still test that on a real device. Concept, design, device testing, store submission, and final review stay my job.

It's a shame it went dark after three days, but I'm glad I got this pass in before it did.

Daily Diary is live on Google Play — give it a try:

📱 https://play.google.com/store/apps/details?id=com.diary.daily

transform: translateY(0) Breaks position: fixed — A Hidden Trap in SPA Animations

YMori — Mon, 06 Apr 2026 09:55:09 +0000

The Bug

One day I got this bug report on my Next.js site:

Clicking a photo near the bottom of the gallery opens a lightbox, but it's completely black. Scroll up and the image is there.

A position: fixed; inset: 0 overlay was not covering the viewport — it was stuck at the top of the page. Browser bug? No. This is CSS working exactly as specified.

How to Reproduce

Two ingredients:

An ancestor element with transform set (even translateY(0))
A descendant with position: fixed

/* Page transition animation */
@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: translateY(0); /* The culprit */
  }
}

.page-enter {
  animation: page-enter 0.35s ease both; /* both = keeps final values */
}

// Lightbox (descendant of .page-enter)
<div className="fixed inset-0 z-50 bg-black/90">
  <img src={photo.url} />
</div>

Near the top of the page, everything looks fine. Scroll down and open the lightbox — it renders at the top of the ancestor element, not the viewport.

Why This Happens — The CSS Spec

From MDN's position: fixed documentation:

The element is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none.

Ancestor's `transform`	`fixed` is relative to
`none` or unset	viewport (expected)
`translateY(0)`	that ancestor (broken)
`translateY(12px)`	that ancestor (broken)

translateY(0) is not the same as no transform. It's a transform that moves nothing — but the CSS engine still creates a new containing block.

The `animation-fill-mode: both` Trap

.page-enter {
  animation: page-enter 0.35s ease both;
}

both (forwards + backwards) keeps the final keyframe values after the animation ends. So transform: translateY(0) persists for the lifetime of the element.

The same applies to JavaScript inline styles:

// IntersectionObserver fadeIn component
<div style={{
  transform: visible ? "translateY(0)" : "translateY(16px)",
  // After visible=true, translateY(0) stays forever
}}>
  {children}
</div>

Blast Radius

Every fixed descendant of a transform-bearing ancestor is affected:

Lightboxes / modals
Toast notifications
Cookie consent banners
PWA install prompts
Progress bars
Scroll-to-top buttons

Bottom navs and sticky headers may not visibly break (they sit at viewport edges), but they are technically affected too.

The Fix

1. Use `transform: none` (Most Important)

@keyframes page-enter {
  from {
    opacity: 0;
    transform: translateY(12px);
  }
  to {
    opacity: 1;
    transform: none; /* Not translateY(0) */
  }
}

<div style={{
  transform: visible ? "none" : "translateY(16px)",
}}>

transform: none means "no transform is applied" — no containing block is created.

2. Use `createPortal` to Escape the DOM Tree (Defensive)

import { createPortal } from "react-dom";

function Lightbox() {
  return createPortal(
    <div className="fixed inset-0 z-50 bg-black/90">
      {/* ... */}
    </div>,
    document.body // Renders at body root — immune to ancestor CSS
  );
}

No matter what ancestors do, the overlay is not affected. This is a best practice for any viewport-covering overlay.

3. Do Both (Recommended)

Fix the root cause with transform: none, and add createPortal as defense-in-depth. If someone later adds a new transform ancestor, overlays still work.

Summary

Don't	Do
Use `translateY(0)` as animation end value	Use `transform: none`
Render `fixed` overlays deep in the DOM tree	Use `createPortal(document.body)`
Add animations without checking `fixed` elements	Audit `fixed` descendants when adding `transform`

translateY(0) and none look identical but behave differently. Miss this spec detail and every overlay on your site breaks the moment you add a page transition animation.

NPB 2021 Backtest: Could a Bayesian Model Predict Last-Place-to-Champion?

YMori — Tue, 24 Mar 2026 02:51:07 +0000

Introduction

In a previous article, I added Bayesian integration to my NPB prediction system. The 8-year backtest showed "97% probability of beating Marcel." But how did it perform in the worst year for predictions?

2021 was NPB's biggest upset: both Yakult (CL) and Orix (PL) went from last place to champions. I ran a full backtest with 25 new foreign players individually projected using FanGraphs and Baseball Savant data.

GitHub: npb-2021-backtest
Main model: npb-prediction

Team Standings: Predicted vs Actual

Central League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Yakult	73W (1st)	69.5W (4th)	70.7W (4th)	+1.2W (Santana, Osuna)
Hanshin	77W (2nd)	72.8W (2nd)	72.6W (2nd)	-0.2W
Giants	61W (3rd)	83.1W (1st)	84.3W (1st)	+1.2W (Smoak, Thames)

Pacific League

Team	Actual	Bayes (no foreign)	Bayes (with foreign)	Foreign Effect
Orix	70W (1st)	64.5W (6th)	62.0W (6th)	-2.5W (worse)
SoftBank	60W (4th)	77.6W (1st)	76.2W (1st)	-1.4W

MAE: 10.4 wins → 10.7 wins. Foreign player predictions slightly worsened accuracy.

Foreign Player Predictions vs Actual

Accurate Predictions (average MLB players)

Player	Team	Pred OPS	Actual OPS	Diff
Kevin Cron	Carp	.703	.701	-.002
Jose Osuna	Swallows	.683	.694	+.011
Cy Sneed	Swallows	ERA 3.53	ERA 3.41	-0.12

Major Misses (extreme players)

Player	Team	Pred OPS	Actual OPS	Diff
Mike Gerber	Dragons	.862	.352	-.510
Mel Rojas Jr.	Tigers	.867	.663	-.204
Domingo Santana	Swallows	.713	.877	+.164

Gerber had an MLB wOBA of .127 (49.3% K rate) — the model over-regressed toward the mean, predicting .862 OPS when the actual was .352.

Santana was predicted from 84 PA in 2020 (COVID-shortened). His career .757 OPS would have been more predictive.

What Actually Drove the 2021 Standings

Yakult's Championship Run

Player	2020	2021	Change
Tetsuto Yamada	OPS .766	OPS .885	+.119
Domingo Santana	—	OPS .877	New signing
Noboru Shimizu	ERA 3.54	ERA 2.39	-1.15

Orix's Championship Run

Player	2020	2021	Change
Yutaro Sugimoto	OPS .695	OPS .931	+.236 (HR King at 31)
Hiroya Miyagi	—	ERA 2.51 (147IP)	20-year-old, 13 wins
Yoshinobu Yamamoto	ERA 2.20	ERA 1.39	-0.81 (Sawamura Award)

Sugimoto and Miyagi's breakouts were impossible to predict from past data. This is a structural change, not a statistical fluctuation.

Giants Collapse (Predicted 84.3W → Actual 61W)

Sugano (ERA 1.97→3.19), Sakamoto (OPS .844→.657), Maru (OPS .899→.775) — three stars declining simultaneously. The Bayesian model trusted their skill metrics and predicted even higher than Marcel.

Key Findings

Average MLB players predicted well (Cron .703 vs .701 actual)
Extreme players over-regressed (Gerber .862 vs .352) → need regression limits
Single-year small samples mislead (Santana's 84 PA in 2020) → use career stats
Bad MLB pitchers stay bad in NPB (Sparkman 6.02→3.88 pred→6.88 actual)
2021 was driven by Japanese player breakouts, not foreign players

Conclusion

Individual foreign player projections improve accuracy for "average" players but carry risk for extreme cases. In 2021, Japanese player breakouts and collapses determined the standings — foreign player predictions had minimal impact (MAE +0.3 wins).

This is a personal hobby project. There may be oversights in data collection and verification.

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records
FanGraphs — MLB wOBA/K%/BB%
Baseball Savant — MLB Statcast
Baseball Reference — MLB/MiLB stats

Adding Bayesian Ensemble + Monte Carlo to an NPB Prediction App

YMori — Mon, 23 Mar 2026 21:48:12 +0000

Introduction

I've been running a personal NPB (Japanese pro baseball) prediction app:

Dashboard: npb-prediction.streamlit.app
GitHub: npb-prediction

It used Marcel projections (3-year weighted average) and ML (XGBoost/LightGBM). Decent, but I wanted better accuracy. After adding Bayesian corrections, the predicted standings changed significantly.

Terms

Term	Meaning
Marcel	Predict next year from weighted average of past 3 years
Bayesian	Combine prior knowledge with data. Gives uncertainty estimates
CI	Credible interval — range where the true value falls with 80%/95% probability
OPS	On-base + Slugging. Overall batting metric
ERA	Earned Run Average. Runs allowed per 9 innings
MAE	Mean Absolute Error. Average prediction miss. Lower = better

Problems with the Previous Approach

Problem 1: All Foreign Players Treated as "Average"

Marcel needs 3 years of NPB data. First-year foreign players have none, so all 24 of them were treated as league-average. Dalbec (Giants, .355 wOBA in MLB) and Hummel (BayStars, .240 wOBA) were calculated identically.

Problem 2: Skill Metrics Ignored

Marcel averages past results directly. Two players with OPS .800 might have very different K% and BB% profiles, which affects how stable their performance will be next year.

Problem 3: No Uncertainty

"Maki's OPS: .812" gives no sense of how much it might vary. The difference between .750-.870 and .790-.830 matters a lot for team projections.

What Changed with Bayesian Integration

Foreign Players: Average → Individual Predictions

Built a model to convert MLB/KBO stats to NPB projections. For example, a .350 wOBA MLB hitter maps to approximately .350 × 1.235 = .432 NPB-equivalent wOBA.

All 24 players' names and prior-league stats were individually web-verified (guessing English names from katakana is surprisingly error-prone).

Foreign hitter examples:

Player	Team	Prior wOBA	NPB Pred OPS	80% CI
Sano	Dragons	.370	.760	.632–.889
Seymour	Buffaloes	.365	.735	.607–.863
Dalbec	Giants	.355	.725	.577–.884
Hummel	BayStars	.240	.694	.530–.849

Foreign pitcher examples:

Player	Team	Prior ERA	NPB Pred ERA	80% CI
Quijada	Swallows	3.26	2.76	1.28–4.24
Hjelle	Buffaloes	3.90	3.34	1.05–5.59
Cox	BayStars	8.86	3.36	1.82–4.85

Players with poor prior-league stats get pulled toward league average (Bayesian regression effect), but with wider CIs = lower confidence.

Japanese Players: K%/BB%/BABIP Corrections

Three models combined into a final prediction:

Model	Weight	Notes
Marcel	35%	Strong baseline, especially for pitcher ERA
Bayesian correction	40%	K%/BB%/BABIP/age adjustment on top of Marcel
ML	25%	XGBoost/LightGBM

Did Accuracy Improve?

8-year backtest (2018–2025, predict each year and compare to actual):

Metric	Marcel MAE	Bayesian MAE	Improvement prob.
Hitter wOBA	0.05023	0.04980	97.1%
Pitcher ERA	1.23008	1.22241	97.1%

Small improvement, but consistent — 97% probability of beating Marcel across 8 years.

Historical Marcel Accuracy for Context

Overall (8 years × 12 teams = 96 team-years):

Metric	Value
Wins MAE	6.4 wins
Avg rank error	1.42 positions
Exact rank rate	18%
Within 1 rank	65%

Recent examples of Marcel misses:

Year	Team	Actual	Predicted	Miss
2025	Swallows (CL)	57W (6th)	72W (4th)	+15
2024	SoftBank (PL)	91W (1st)	75W (2nd)	-16
2024	Buffaloes (PL)	63W (5th)	78W (1st)	+15

Patterns:

Overestimates bottom teams, underestimates top teams (regression to mean)
Can't predict collapses (2024 Buffaloes: defending champions → 5th place)
Foreign player impact not captured when all treated as average

How Did the 2026 Standings Change?

Central League — Tigers Runaway Disappears, 4-Team Deadlock

Team	Marcel	Bayesian	Diff	P(Pennant)
Tigers	80.1W (1st)	71.5W (1st)	-8.6	26.0%
Giants	70.7W (3rd)	71.1W (2nd)	+0.4	20.2%
Dragons	68.8W (5th)	71.0W (3rd)	+2.2	21.2%
BayStars	71.3W (2nd)	70.7W (4th)	-0.6	20.2%
Carp	70.4W (4th)	69.1W (5th)	-1.3	12.3%
Swallows	64.3W (6th)	61.2W (6th)	-3.1	0.1%

Tigers dropped from 80.1W to 71.5W (-8.6). Skill corrections pulled them down. Giants at 71.1W even after losing Okamoto to MLB. Four teams within 0.8 wins — Tigers 26%, Dragons 21%, Giants 20%, BayStars 20%. Swallows at 61.2W (78% last place) after Murakami's MLB departure.

Pacific League — Lions Surge

Team	Marcel	Bayesian	Diff	P(Pennant)
Hawks	80.5W (1st)	81.3W (1st)	+0.8	47.9%
Fighters	76.8W (2nd)	79.1W (2nd)	+2.3	27.2%
Buffaloes	73.8W (3rd)	77.5W (3rd)	+3.7	17.6%
Lions	68.6W (4th)	74.9W (4th)	+6.3	7.1%
Eagles	65.5W (5th)	66.7W (5th)	+1.2	0.1%
Marines	67.1W (6th)	64.9W (6th)	-2.2	0.1%

Lions +6.3 wins — foreign player projections offsetting Imai's MLB departure.

Summary

Problem	Before	After
Foreign players	All league-average	24 individual projections from prior-league stats
Skill metrics	Not used	K%/BB%/BABIP corrections on Marcel
Uncertainty	None (point estimates)	80%/95% credible intervals on every prediction
Team standings	Single number	10,000 Monte Carlo sims with pennant probabilities
Accuracy	Marcel MAE 0.050	0.0498 (97% probability of improvement)

The accuracy gain is modest, but "foreign players are no longer invisible," "MLB departures are reflected," and "every prediction comes with uncertainty" meaningfully changed the standings picture. The CL went from "Tigers runaway" to a four-team deadlock.

Caveat: Data Limitations

During this work, I discovered that players who moved to MLB (Murakami, Okamoto) were still included in the team simulation — the roster filter only existed in the Streamlit display layer, not in the CSV generation pipeline. Fixed and regenerated, but there may be other oversights I haven't caught.

This is a personal project without professional-grade QA. The data is best treated as automated model output, not authoritative predictions.

Dashboard: npb-prediction.streamlit.app
GitHub: github.com/yasumorishima/npb-prediction

Data Sources

Baseball Data Freak — NPB player stats
NPB Official — Official records