A scoring engine, built and run by an AI agent

Built in Cowork, by design. The Input Card, the scoring engine, and every output section run as plain JavaScript in your browser. Two things leave it, and both are stated on screen where they happen: a fare search sends the route, dates, cabin, and traveler count to the site's own /api/fares function, and watching a trip stores that route server-side so the scheduled re-check has something to check. Your wallet stays put. Cards and balances never leave the browser.

No terminal in this stack. Cowork builds it; your browser runs it.

Fares have exactly one mode: real. Every run pulls live Google Flights prices through the site's own backend, merges in anything you scanned yourself from Kayak or Booking (each one carries a labeled source pill), and scores the lot with the engine below. When nothing real comes back, the site says so and shows no figures at all. The old synthetic fallback model was deleted on 2026-07-26, on the principle that a plausible invented number is worse than an honest empty state.

A few other numbers are estimates, and they say so on screen. Flight times for offers that arrive without a duration get computed from great-circle geometry against a hand-maintained city coordinates table. Mileage figures are distance-scaled planning ranges, because award availability isn't searched yet. Upgrade friendliness is the softest of them: a per-carrier reputation judgment, nowhere near a live seat map.

The Points Intelligence panel carries a different kind of number again. Point valuations (which airline's miles are worth the most, in cents per point) and active transfer bonuses are published figures from The Points Guy's monthly valuations, hand-copied with their date shown on screen and refreshed by hand each month. They're facts with a timestamp. Not a model output, and not a live feed either, which is why that as-of date always sits right next to them.

Every candidate itinerary is scored 0 to 100 on Cost, Comfort, Upgrade Potential, Award Value, Flexibility, Risk, and Time. Your ranked priority list, from Cheapest to Best Overall Experience, maps onto those seven dimensions through a fixed weighting table: a rank-1 priority carries more weight than a rank-7 one. The final score is a weighted sum, shown on the results page as an explicit percentage per dimension, so the reasoning behind the recommendation is never reduced to a single number. Time was added 2026-07-25, after Fastest and Cheapest returned the same pick on a route where every offer had one stop: Risk only scored stop count, so there was nothing left for "fastest" to actually rank by.

The actual math, in full: each of the 7 priority lenses (Cheapest, Best Value, Fastest, Most Comfortable, Best Upgrade Opportunity, Best Use of Miles, Best Overall Experience) has its own fixed weight per dimension, hand-tuned in app.js. If you rank more than one priority, a rank-1 pick's vector counts more than a rank-2 pick's, by this formula:

rankWeight   = (totalPriorities + 1 − rank) / totalPriorities
dimWeight[d] = Σ (priorityVector[priority][d] × rankWeight[priority]),
               then normalized so all 7 weights sum to 1
score        = Σ (dimensionScore[d] × dimWeight[d])  for d in the 7 dimensions

For example, under "Best Overall Experience" (the default lens most results are viewed through), the fixed vector is Cost 1.4, Comfort 0.5, Upgrade 0.4, Award 0.3, Flexibility 0.3, Risk 0.3, Time 0.2. Cost was raised from 0.3 to 1.4 on 2026-07-19, a direct, documented judgment call: an earlier version had a $2,400 nonstop beating a $1,300 one-stop under "Best Overall," which didn't hold up as a real recommendation. The new weight was tuned against that exact case and pinned by a regression test, so it can't silently drift back.

The scoring is deterministic. Run the same trip against the same fares tomorrow and you get the identical answer, down to the weights. Nothing is randomized and nothing calls a language model at recommendation time, which is what makes the weight breakdown on the results page worth reading: it's the arithmetic that actually produced the pick, not a rationalization written afterward.

Every push to main auto-publishes, with no manual step. The backend is five small functions and nothing else. fares runs the live search; scan-offers holds the fares you scanned by hand. watch keeps the watched-trip list and watch-check re-searches it every other day. watched-trips serves the privacy-scoped read for the Concert Radar link. A separate weekly GitHub Actions script, not a Netlify function, sweeps for shows that have just started matching and commits the result. No framework, no build step, no database beyond one storage service.

Award-space search is the biggest gap left. Mileage figures are planning ranges, never availability checks.

The watcher does the fare-watching on its own now, re-checking each saved trip roughly every other day, capped at six trips (raised from three on 2026-08-11). Each check spends one metered search against a 100-search monthly quota, which is why the cap exists. Raising it further, or adding email and push alerts, needs a new credential or a quota decision, so it waits for Susan's explicit yes, the same rule that governs every other real cost here.

Saved memory covers the wallet, the preferences, and the watched trips. Other inputs still reset each session. The Points Guy valuation and transfer-bonus tables are a manual monthly refresh, copied by hand with their date on screen, so a stale month shows rather than hides.