flightscout: a sharp toolkit for flight research and fare-watching

Flight research is mostly guesswork. You squint at a fare today, have no idea whether it is good, and for a far-out trip you cannot even tell whether the dates are bookable yet. Price-watch tools promise to tell you when something drops, then quietly miss the one alert that mattered. We built a small, sharp toolkit that fixes the parts that actually break.

flightscout sits on top of fli, an unofficial Google Flights client, and adds the two things that turn raw fare lookups into a tool you can trust: booking-frontier intelligence that tells you when a far-out trip even opens for sale, and fare watches whose alerts fire exactly once and cannot be lost. It runs as a CLI, as an MCP server, and as a drop-in Claude Code skill, so an assistant can do the research for you.

The problem

Two questions trip up almost everyone planning travel, and neither is solved by a normal flight-search box.

The first is "when can I even book this?" Airlines only sell on a rolling horizon, commonly about 330 to 360 days out, so a date further out is not bookable yet. There is no flight to price, no fare to watch, and no clear signal telling you the calendar day the route will open. People just check back at random and hope.

The second is "is this a good price, and will I hear about it when it drops?" Fare alerts are easy to demo and hard to make reliable. The failure that matters is the one nobody sees: the price drops, the alert fires, the notifier is down for an hour, and the alert is simply gone. By the time the service recovers, the moment has passed. A watch that can lose the one alert you set it for is worse than no watch, because you trusted it.

The approach

flightscout is deliberately small. It is a thin, sharp layer over fli that adds exactly the intelligence the underlying client does not give you, and nothing speculative on top.

Core commands

The CLI is built with typer and rich, so the everyday research surface is fast and readable: search for one-way or round-trip, cheapest for the cheapest departure dates across a window, flexible for the cheapest within plus or minus N days, compare to fan out across nearby airports and merge the results by price, frontier for the booking-frontier read, and watch plus history for ongoing fare-watching.

Watches that fire exactly once, and cannot be lost

This is the real engineering of the project. A naive watcher checks the price, and if the condition is met, sends a notification in the same breath. The moment delivery fails, the event is gone. flightscout splits those two concerns on purpose. A check runs from cron via flightscout watch check --notify. When the condition is met, detection is latched in state, separately from delivery. If the notifier is down on the firing day, the latch holds and the watch keeps retrying until delivery actually succeeds. The alert is durable, not best-effort. And after several consecutive errored checks, a dead-man's-switch alert warns you that the watch itself may be broken, so silence never gets misread as good news.

Six pluggable notifiers

Delivery is a plug-in point, configured via TOML or environment variables. Pick the channel that fits how you already get notified.

An honest read, not a forecast

flightscout does not pretend to predict fares. Every check logs the day's cheapest fare, and history shows the trend and where today sits versus the recent median. That is the honest version of "is now a good time to book": context, not a crystal ball. We would rather give you a true read of where the price has been than a confident guess about where it is going.

Agent-native by design

The same core engine is exposed three ways. It is a CLI for a human at a terminal, an MCP server so an AI assistant can call the tools directly, and a drop-in Claude Code skill. That means you can ask an assistant to do the research, run the comparisons, and set the watches for you, and it is working against the same booking-frontier logic and the same durable watch machinery, not a separate, weaker path.

Try it

A booking-frontier read and an availability watch, straight from the README. The frontier call probes the furthest bookable date for a route; the watch then alerts you the day your far-out date opens for sale.

# How far out can I book, and when does my target date open?
flightscout frontier --from JFK --to LHR --target 2027-06-15

# Watch for that date to become bookable, then check from cron.
flightscout watch add availability --from JFK --to LHR --date 2027-06-15
flightscout watch check --notify

Honest limits

These are not caveats buried in a footnote. They are the boundary of what the tool honestly does, and stating them plainly is part of the design.

• Cash fares only. No miles, award, or points pricing. If you book on points, this is not your tool.
• Unofficial data source. It reads an unofficial, undocumented Google Flights endpoint through fli, so it is rate-limited and can change without notice.
• Not a Google product. flightscout is not affiliated with or endorsed by Google.
• Credit where it is due. The underlying flight client is the fli project. flightscout adds the frontier logic, the reliable watches, and the agent-native surfaces on top of it.

Why this one is worth a look

Three things make flightscout more than a wrapper. The booking frontier binary-searches a real, undocumented horizon and turns "check back later" into a date on your calendar. The watch design latches detection separately from delivery and backs it with a dead-man's-switch, so the alert you set is one you can actually rely on. And it is both a CLI and an MCP server over one engine, so a human or an assistant can drive the exact same logic. It is small on purpose, honest about its limits, and the hard parts are the parts that usually get skipped.

Skills

Tech

An open-source project of ours, published under the MIT license. Credit for the underlying Google Flights client goes to the fli project. Not affiliated with or endorsed by Google.