My alarm won't let me snooze if I'd be late

Elias Shieh — Thu, 22 Oct 2026 20:09:39 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

Every morning I want to sleep a little longer, but I'm scared to keep pressing snooze.

Snooze Oracle uses past Uber trips to work out when I need to get up for a meeting. It finds the latest time I can get up for which the model estimates at least a 90% chance of being on time. The alarm rings 30 minutes before that, and I can snooze up to 10 minutes at a time until I reach it.

Right now it is a web replay and a command-line planner that writes the alarms to a calendar file. There is no phone app yet, and I don't live in New York, so I haven't used it on a real morning.

Try to snooze it yourself: snooze.eliasshieh.com (works in a phone browser)

What I Built

If you have to be somewhere at the same time every weekday, you probably set the same alarm every day. But the trip doesn't take the same time every day. On the route in my demo, a weekday Uber from University Heights in the Bronx to Midtown, requested between 7 and 9am, took 28 to 75 minutes from request to drop-off in July and August. So when the alarm rings, you don't know how long you can stay in bed.

In the replay, the meeting is at 9:00 in Midtown. The alarm rings at 07:14. You snooze to 07:24, 07:34 and 07:44, and then it says no: one more minute would drop the estimated chance of being on time to 89%. So I can keep snoozing without doing the math in my head, and I don't have to check the map the night before.

It doesn't know about tomorrow's accident or rain. It learns from past trips how long your route usually takes on a weekday morning at that hour, and how much that changes. So the wake-up time depends on the day of the week and the meeting time.

Demo

The demo page replays one day of August 2026 data. Pick a commute or an airport pickup, press Start and keep pressing Snooze. When another snooze would put the estimate below 90%, the button says "No safe snooze" and the page shows the number.

The page is static. The curves were computed with TabPFN on my machine and saved into the page, so nothing on it calls a model.

The video's narration is ElevenLabs text-to-speech, the music was made with ACE-Step 1.5, and the video's 3D scenes are three.js.

Code

ting-hong-shieh / snooze-oracle

An alarm that lets you snooze only while you'll still make it. TabPFN-3.5 on NYC Uber trips.

Snooze Oracle

An alarm that works out, the night before, the latest time you can get up and still be on time with an estimated 90% probability. It rings 30 minutes earlier and allows snoozes of up to 10 minutes until that cutoff, then refuses.

Two mornings are covered:

Commute: an Uber to a meeting in Midtown, the Financial District or Hudson Yards.
Pickup: meeting someone off an early flight (landing 03:00–08:59) at JFK or LaGuardia.

Ride times come from TabPFN-3.5 run locally on NYC TLC Uber trips; flight delays from TabPFN-3.5 on BTS on-time data.

Try it: https://snooze.eliasshieh.com replays six August 2026 mornings (four commutes two airport pickups) with a simulated alarm clock and a map of each route. The page is static: the curves were precomputed and nothing on it calls a model.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 3 The write-up is on …

View on GitHub

How I Built It

Data. NYC TLC trip records for about 14 million Uber trips a month (July and August 2026), and BTS on-time records for flights into JFK and LGA. The models only get July trips (for flights, the 12 months before) and are tested on August.

Why TabPFN. It did best where data is thin. On airport routes with fewer than 30 trips in July, I gave TabPFN, LightGBM and a lookup table exactly the same rows. TabPFN's mean pinball loss (lower is better) was 2.49 minutes, against 2.78 for LightGBM and 2.97 for the lookup. On busy routes it tied LightGBM.

I don't train or fine-tune TabPFN. I use the pretrained model as it is. For each ride prediction, I give it up to 10,000 July trips as examples. I start with trips on the same route around the requested hour, then add trips from the same borough to the same destination. It predicts a range of trip times and how likely each one is, and the planner uses that to compare possible wake-up times.

The alarm. For each possible wake-up time, it simulates 2,000 mornings: getting ready (I assume about 15 minutes) and the ride. For an airport pickup, I compare my arrival with the flight's predicted arrival plus 20 minutes for the passenger to get out. The target is the latest wake-up time where at least 90% of those mornings are on time.

The test. Every strategy picks one wake-up time the night before and is scored against August trips. The fixed buffer is the simple way: take the meeting time, then subtract 15 minutes to get ready, the July median trip time, and a buffer. The other three are the same alarm built on a lookup table, on LightGBM and on TabPFN.

Across all 12 commute routes, the alarm was late 5.1% of the time and the 10-minute buffer 8.3%. But you sleep a little less. On average the alarm got you up 2.9 minutes earlier than the 10-minute buffer.

A 13-minute buffer matched the alarm's overall late rate at about the same average wake-up time, but I could only pick 13 after seeing the August results. On the University Heights route, the 13-minute buffer was late 17.1% of the time. The TabPFN alarm was late 12.7%, which is better but still above my 10% target, and it got you up 7.1 minutes earlier than the 13-minute buffer on average (small sample, see the details below).

The full reports are in the repo: commute backtest, airport backtest and ride model comparison.

I also tested airport pickups, where both the drive and the flight's arrival are uncertain. Here the TabPFN alarm did worse than the lookup alarm: late in 10.3% of simulations, versus 9.1%. It gave some flights too much extra sleep, so I need to improve those predictions before I would trust it for a real pickup.

All the numbers

Share of mornings late:

	Airport	Commute	Demo route
Fixed buffer*	11.1%	8.3%	22.9%
Lookup alarm	9.1%	6.1%	21.3%
LightGBM alarm	11.7%	6.6%	14.6%
TabPFN alarm	10.3%	5.1%	12.7%

*30 minutes at the airport, 10 minutes for the commute. A 13-minute commute buffer was late 5.1% overall and 17.1% on the demo route (University Heights to Midtown Center).

Airport: 1,575 completed flights scheduled to arrive from 4:00 to 7:59, each with 8 pickup zones: 12,600 scenarios. Planning for the scheduled time and ignoring delays was late 46% of the time.
Airport, by flight: on the 4.3% of scenarios where the alarm woke you 10 or more minutes earlier than a 30-minute buffer, mostly red-eyes from the West Coast and Hawaii, the buffer was late 17.8% of the time and the alarm 3.8%. On the 2.0% where it let you sleep 10 or more minutes longer, mostly short 7am flights into LaGuardia, the alarm was late 16.9% and the buffer 5.6%.
Commute: 12 routes into Midtown, the Financial District and Hudson Yards, meetings from 8:00 to 10:00, 21 weekdays: 1,260 mornings, of which 1,070 had enough August trips to score.
University Heights route: 63 simulated mornings with meetings at 8:00, 9:30 and 10:00; the demo's 9:00 meeting had no August mornings I could score. The route has few trips, so its ride samples come from any August weekday, and they don't measure each day's traffic.
Flights alone: pinball loss TabPFN 10.38, lookup 10.56, LightGBM 10.68.
I tested commute buffers from 0 to 30 minutes and airport buffers from 0 to 90 minutes on August data. August trips were never in the models' training rows or context, but I used August results to compare buffers and to choose the flight-model variant.
A feature I dropped: I looked for a reason to wait 10 minutes before requesting the Uber and didn't find one. On the busiest early-morning airport routes, the typical fare changed by $0.80–2.40 between neighbouring 10-minute slots, while the spread of fares inside one slot was $12–34.
The backtest scored wake-up times. Its snooze simulation used 9-minute snoozes; the demo now uses up to 10.

Why Does Open Innovation Matter?

I can keep the planning local. TabPFN runs on my computer, and the planner reads saved predictions. Picking a pickup area or a flight doesn't mean sending my plans to a model provider.
I could test without API fees. In my third round of ride tests, TabPFN ran on 2,914 route-and-hour groups, 59,321 trips in total. That took about two hours on my GPU.
Other people can check my choices. The repo has the code that downloads the public NYC TLC and BTS data, compares the models and tests the alarm. You can change my assumptions, like 15 minutes to get ready or 20 minutes for bags, and rerun the tests.

The code is Apache-2.0. TabPFN-3.5's weights have a separate non-commercial license, so rebuilding the predictions needs a Prior Labs login, that license, the weights and a GPU. The public demo only replays saved results.

Prize Categories

Best Use of TabPFN
Best Use of ElevenLabs: the narration in the demo video is ElevenLabs text-to-speech.

How this was made: I built this with AI coding agents (Claude Code, and Codex for reviews). I chose the idea, the rules and what to test. The agents wrote most of the code, the video and the first drafts of this post. Every number comes from runs on my own GPU.

DEV Community: Elias Shieh