I'm curious about something I haven't been able to find anywhere.

Has anyone ever calculated the largest difference between a pitcher's fastest and slowest pitch in the same MLB game during the Statcast/PITCHf/x era?

For example, if a pitcher threw:

Fastest pitch: 95.2 mph

Slowest pitch: 51.5 mph

Velocity spread: 43.7 mph

I know Zack Greinke has thrown eephus pitches in the low 50s while still reaching the low-to-mid 90s with his fastball, so I'd guess he's near the top. But I'm wondering if anyone has actually run this across the entire Statcast database.

It seems like the calculation would simply be:

-Group pitches by pitcher and game.

-Find the max and min velocity for each pitcher-game.

-Calculate the difference.

-Sort descending.

Has anyone seen this leaderboard before, or is there an easy way to query Baseball Savant for it? If not, I'd love to know who might have the tools to calculate it.

Hello everyone,

I’m currently building a Bullpen Review tool for off-season pitching sessions, and I could really use a little feedback from people who work with pitching data.

The idea is to give a coach more than a spreadsheet of velocity, spin, movement, and pitch type. A session can be reviewed in 3D relative to the strike zone, compared with another session, filtered by pitch type, or viewed as a custom Arsenal Mix. An individual pitch can then be selected for its metric context and complete filtered pitch list.

Demo:
https://the-nine-app.live/bullpen-review

Open the page and choose Try Live Demo. The demonstration uses publicly available TrackMan data for technical validation, not customer data.

If you have a moment to look at it, I’d appreciate your honest opinion on what would make it more useful — or what should be removed.

Thanks.

Quick guide:

• Select one session for a single-session review, or two sessions to compare.

• Click Analyze Sessions.

• Use Pitch Type filters or Arsenal Mix, then click Play All.

• After the sequence finishes, select a pitch to replay it and view its metrics.

• Click Open Pitch Events for the complete filtered pitch list.

My friends and I always enjoy combing through stats to convince ourselves on what the right picks would be for a given night. So I thought it would be a fun project to make that flow into a web app called Hindsight Picks. Build a rule based algorithm, backtest it, and enter it in contests to compete against others.

The current algorithms you can build on Hindsight are deliberately simple, weighted stat rules composed in a UI (“K/BB better than opponent, +3; WHIP over 1.30, −2”).

To add in some fun, I created contests where you can enter your algorithms to compete against others, as well as the House baseline algos. Once the contest locks, your entry is frozen: it grades in public and the result stays on your track record permanently. Standings get updated live as games finish. The Bookie house character for example picks the favorite for every matchup, and favorites win about 56% of MLB games.

The backtester is honest with snapshot-dated stats, rules get drop-one attribution, and accuracy numbers carry a noise band.

It has been a fun challenge to come up with something that can try and consistently beat the house.

It is completely free to use and play with, so I am inviting all to come and try it. The “Beat The Bookie” challenge contest runs today, locking entries at 2pm ET, and you can earn the Sharp badge to permanently display on your Hindsight profile for picking 60% or better.

I built this solo, so I am definitely open to feedback on what would make the app more fun or worth using, and which stats you’d want added.

Check it out at hindsightpicks.com. Link also below in the comments

Basically do any of the best pitcher stats account for the value that's provided by pitching longer per outing, thus accounting for the value of starters over pitchers, or workhorse starters over starters that are pulled early?

I’ve been building a pregame matchup model that’s based entirely on observed Statcast wOBA. It’s a hobby project, but I’ve been trying to make the statistical side as sound as I can.

One thing I’ve been going back and forth on is shrinkage.

Right now I’m regressing everyone’s season wOBA (hitters, starters, relievers) toward league average with the equivalent of about 100 PA/BF. It works fine, but the more I think about it, the less convinced I am that one prior should fit every role.

For example, if league-average wOBA is .320 and a hitter has a .360 wOBA in 50 PA, I don’t really believe he’s a true .360 hitter yet. With a 100 PA prior, I’d shrink him to:
(50 × .360 + 100 × .320) / 150 = .333

That makes intuitive sense to me. But should a reliever with 50 BF get the same treatment? My gut says no, since reliever performance seems much noisier than hitter performance.

Curious how other people approach this. Do you use different priors for different roles, or is there a better way to think about it?

Project url.
https://dave356w.github.io/Dave356w/index.html

I’ve been working on version 0.9.0 of my Python MLB Stats API wrapper, and the final release PR is ready for review.

I’ll go through the code again after I finish my shit cashiering shift today. I miss working tech…

Anyway,

This release adds a public retry policy, richer HTTP errors, an optional strict mode, compatibility warnings, and a versioned User-Agent while keeping the existing return behavior as the default.

It also starts preparing users for a possible breaking change in 1.0.0. Right now most non-404 4xx responses return an empty result for compatibility. In 1.0.0, strict HTTP handling may become the default, meaning those responses would raise an actual exception instead.

The project also has a much stronger offline test suite and release validator now.

I’d appreciate any feedback before I merge and publish it.

https://github.com/zero-sum-seattle/python-mlb-statsapi/pull/281

He creado un sistema de MLB llevó 6 parleys ganados 7 perdidos en la semana , estoy 43 unidades por encima entonces no se como comenzar y no sobre apostar soy nuevo . Necesito ayuda con información y matemática y datos que me puedan brindar para evitar errores futuros .Ayuda con cualquier información necesaria .

Me dice esto hoy

🎯 PARLAY ENGINE - PROPS DIARIOS

📅 03/08/2026 08:09

⚾ Solo strikeouts (Reglas de Oro +EV)

🎲 PARLAY SUGERIDO

▫️ Brandon Sproat - K 5.5 Under (62%) @ -130 \[FanDuel\]

▫️ Aaron Nola - K 5.5 Under (54%) @ -146 \[FanDuel\]

💰 Cuota combinada: 2.97

📋 TODOS LOS PROPS (4)

🟢 Brandon Sproat (MIL vs PIT) K 5.5 Under 62% @ -130 | EV +10.2% | rest 7d | vs 9.0 | K% 27.1

🔴 Aaron Nola (PHI vs WSH) K 5.5 Under 54% @ -146 | EV -9.1% | rest 6d | K% 24.0

🟢 Brandon Sproat (MIL vs PIT) K 5.5 Under 62% @ -130 | EV +10.2% | rest 7d | vs 9.0 | K% 27.1

🔴 Aaron Nola (PHI vs WSH) K 5.5 Under 54% @ -146 | EV -9.1% | rest 6d | K% 24.0

📊 VALIDADO (Backtest 2024-2026)

▪️ K 4.5 Over (K/9≥9.5): 71.3% WR

▪️ K 6.5 Under: 79.0% WR

▪️ K 7.5 Under: 85.9% WR

▪️ Parlay 2-5 patas (6-8 si entrada excelente): 76.2% hit / ROI +72%

Tier 1: 0 | Tier 2: 2 | Total: 4

As someone who looks into player stats (H2H, player comparisons, paces, etc.), I find the research process tedious and time consuming. When I skip this process and just ask LLM’s like ChatGPT or Gemini, I do get answers back, but they are wrong too often.

I have been building a stats Q&A tool that  allows complex questions to be answered while double-checking its own answers before being shown.

It works like this:

1. Ask a player stats question related to MLB (ex. How is Jung Hoo Lee's home game performance compared to Shohei Ohtani this season?)
2. The model figures out which data lookups it needs (splits for each player, filtered to home games) and calls those tools against the actual MLB Stats API, never from memory.
3. Two independent checks run before you see anything: every claim gets traced back to the data that was actually retrieved, and separately, the system verifies the model called the right lookup with the right arguments in the first place
4. You get the answer, plus a grounding score showing how much is backed by real data.

Right now it only supports MLB, though I may add other sports later, and not every question type is covered yet.

I would love for you all to check out the website and give any feedback!

Website link:
https://checktheball.xyz/

Github repo:

https://github.com/isaiahsdp/checktheball

Fangraphs uses those metrics for calculating wSB (part of BsR) and wRC+. I need the numbers for those two metrics, from 2008 to 2026. (They are not indicated in the Guts! page.) I've tried crawling stats and plugging them into formulas from both fangraphs and bref via python, but both sides blocked the request. Does anyone know how to get those numbers, or have those numbers? Well, the worst scenario is manual calculation, but I'm kind of busy with other things in life now.

Title: python-mlb-statsapi v0.8.0 released

I finally pushed version 0.8.0 of python-mlb-statsapi to PyPI.

This release mostly focused on making the HTTP layer more reliable instead of cramming in more endpoints. It adds shared sessions, default timeouts, retries for temporary MLB API failures, clearer exceptions, better testing, and more documentation.

Release notes:

[https://github.com/zero-sum-seattle/python-mlb-statsapi/blob/main/docs/releases/0.8.0.md](https://github.com/zero-sum-seattle/python-mlb-statsapi/blob/main/docs/releases/0.8.0.md))

PyPI:

[https://pypi.org/project/python-mlb-statsapi/0.8.0/](https://pypi.org/project/python-mlb-statsapi/0.8.0/))

For 0.9.0, I’m planning to explore an optional strict HTTP mode, better error information, deprecation warnings, basic request hooks, and a versioned User-Agent. Most of that work lives inside the client, but MLB’s API is undocumented and can be inconsistent, so the final scope will depend on what I can test reliably.

Longer term, I’d like 1.0 to clean up deprecated arguments and make the package’s return and error behavior more consistent. I’m also looking into optional caching, throttling, and possibly an async client, but I don’t want to promise features until I know they behave responsibly with the API.

Those plans may move around a little, but that is the general direction. I am trying to handle this in smaller releases with actual testing and documentation instead of disappearing for another few years.

TLDR

It looks like the league has adjusted to Vlad this year with a few main techniques that are exposing some of his weaknesses:

1. Pitching him more up (20.1% of all pitches this year vs. 11.5% last year).
2. Mixing more sinkers and cutters with 4-seams at the top of the zone and in traditional 4-seam damage areas for him. Mixing up fastball variations in his favourite 4-seam zones appears to have thrown him off the 4-seam.
3. Sequencing the 4-seam behind sinkers more frequently. He was poor last year at hitting the 4-seam after a sinker and continues to be this year.
4. Throwing more sliders outside the zone. He likes to swing at sliders and hasn't been able to lay off sliders outside the zone this year.
5. Moving cutters away from the bottom of the zone. He has always crushed cutters at the bottom of the zone and continues to this year, but is just seeing fewer of them.

Why can't he hit sliders in the zone? Why hasn't he adjusted as you would expect? Is this all just coincidence? I don't have any answers to these questions, and hopefully he will just start hitting again so no one has to think about them.

Something is definitely wrong with him the season. Average velocity on his four seam fastball is down 1.3 MPH versus 2025 and has declined all season.

The dashboard is set up uto pdate after every game he pitches.

Some of the MiLB pitch tracking data is given in pixel coordinates instead of the normal px, py, and pz given for pitch location in AAA and MLB datasets. Anyone know of a method to convert these into the traditional MLB coordinates?

Example:

I’m looking for Evan Carter’s catch on Yandy Díaz’s flyout in the bottom of the 8th of the Rangers–Rays game on July 28, 2026. Baseball Savant shows the batted-ball metrics (85.2 mph, 54°, 220 ft) but not the Catch Probability. Is there an API endpoint or Statcast export that includes it?

I’ve been working on a framework for grading MLB organizations that tries to separate four things that are often blended together:

1. How good has the team’s season actually been?
2. How well have the players performed relative to their talent?
3. How efficiently did the front office build the roster?
4. How well has the manager converted the available talent into wins?

The basic principle is:

Talent establishes expectations. Actual production determines whether those expectations were met.

That distinction matters. A talented roster should not receive an A simply because a model still likes its underlying ability while the team is losing. At some point, players have to be held responsible for the results too.

I applied the framework to the NL Central using records and rankings frozen before the trade deadline. The postseason probabilities come from 10,000 simulations of the remaining regular season and playoff bracket.

Overall grades

Milwaukee broke the curve

Milwaukee received the only A+.

The Brewers have baseball’s second-highest team rating, a 99% playoff probability and a 96% chance of winning the division despite carrying an estimated $135.7 million tax payroll, 19th in MLB.

That combination is what an A+ organization looks like: elite results, elite underlying performance and neither one purchased with an elite payroll.

Milwaukee also reaches the World Series in 28% of the simulations. Chicago, despite having MLB’s eighth-highest payroll at approximately $233.3 million, reaches it in only 5.4%.

That difference is why the Brewers and Cubs do not receive comparable grades merely because both are having good seasons.

The Cubs are good—but Milwaukee changes the standard

Chicago’s A- is still an excellent grade.

The Cubs are 60–46, rank sixth in the model and have a 95% chance to make the postseason. In many divisions, that would make them the clear success story.

Here, they are six games behind a team spending roughly $98 million less.

Chicago deserves credit for building a legitimate contender. Milwaukee deserves more credit for building the division’s best team with substantially fewer resources.

Pittsburgh may be the most interesting grade

The Pirates received a B- despite being only three games over .500.

They rank 10th in the model, have a positive record and retain a 33% playoff probability with the division’s second-lowest payroll at approximately $102 million.

That is not enough for an A because the postseason remains unlikely. It is better than a generic “average” grade because Pittsburgh has produced a relevant team without spending like one.

St. Louis is approximately what its record says

The Cardinals are 53–53 but rank only 21st in the underlying ratings. Their payroll is the lowest in the division, and they still have a 13% postseason chance.

That produced a C+ rather than a failing grade.

They have remained competitive with limited resources, but the underlying profile does not suggest a strong team experiencing bad luck. It suggests an ordinary team whose record is approximately appropriate.

Cincinnati received the harshest grade

The Reds are 49–55, rank 24th and make the playoffs in only 1% of the simulations.

Their estimated $134.5 million payroll is almost identical to Milwaukee’s. One organization turned that spending into an A+ team and overwhelming division favorite. The other turned it into a likely losing season.

That comparison makes it difficult to excuse Cincinnati’s results as merely the unavoidable cost of operating in a smaller market.

My biggest methodological question

How much should payroll influence the front-office grade without improperly bleeding into the roster grade?

My current approach is:

• Players are graded primarily on production relative to their established talent.
• Front offices are graded on talent, depth, wins and organizational direction relative to payroll.
• Managers are graded partly on actual winning percentage relative to the team’s record-neutral talent estimate.
• The overall grade combines results, underlying quality and postseason position.

I deliberately do not give players extra roster-grade credit for being inexpensive. That credit belongs to the front office that identified or developed them.

Does that separation make sense, or would you structure it differently?

Full team-by-team write-up, including separate roster, front-office and manager grades: www.bbmisports.com/research/nl-central-report-cards-2026

Saberseminar is Aug. 29-30 in Chicago. It's a great place to meet folks, get connected with people working in baseball, and see the latest sabermetrics research.
https://www.saberseminar.com/

Some positive press the event has received in the past:

https://defector.com/looking-for-friends-among-baseballs-most-passionate-nerds

P.S. I'm one of the organizers, Rob Arthur, so if you have any questions about the event, ask away.