Find Flights

Find Flights

Core Rule

Build an actual booking plan the user can execute, rather than a generic travel summary. Treat points as money. A portal redemption is valuable only when the portal fare is at or below the real comparable public fare. If a portal says a fare costs $2,616 and Google/airline-direct shows the same flight at about $2,400, do not call the portal a discount; compute the true value from the public fare and mark the portal fare as inflated.

Inputs To Establish

Extract or ask only for missing constraints that materially change the search:

• Origin and destination airports or cities, including acceptable alternates.
• Passenger count, cabin, bags, seat/refund constraints, and passport/visa constraints when relevant.
• Outbound and return date windows, including earliest departure and latest acceptable arrival.
• Hard events with exact local datetimes, such as a wedding at 6 PM; reject options that arrive too close even if cheap.
• Preference weights: cheapest, direct, shortest duration, fewest stops, alliance/airline preferences, arrival buffer, red-eye tolerance.
• Point programs and portal rules only when the user says points matter, such as a Chase Sapphire Reserve at 1.5x or an Ink Preferred at 1.25x.

Source Coverage

Use live sources because fares change. Minimum source set unless a source is blocked:

• Google Flights for broad fare, schedule, duration, and date-grid truth.
• Skyscanner for OTA and alternate-market checks.
• Skiplagged for one-way, hidden-city, and regular fare anomalies.
• Kayak for hacker fares, one-way builds, and route context.
• Kiwi for self-transfer and unusual multi-carrier builds.
• Momondo when extra OTA coverage is useful.
• Airline-direct for selected finalists and major carriers on the route.
• Credit-card portals such as Chase Travel only when points or portal booking is relevant.

If a source cannot be checked live, say exactly which source was blocked and do not imply it was covered. Do not rely on search-result snippets for a final fare when an exact live query is feasible. Preserve useful result URLs and include links in the output for every source, booking path, or exact search result that can be shared. For authenticated portals where links may not be reusable, include the portal name and current page context instead of pretending the link is stable.

Search Method

Search both conventional and constructed itineraries:

• Round trip on the whole route.
• Separate one-ways for outbound and return.
• Mixed carriers and mixed booking channels when it can reduce net cost or improve timing.
• Flexible return dates if the user permits them.
• Nearby airports only when the user permits them or they are obviously part of the metro area.
• Direct/nonstop options even when expensive, so the user can price the convenience.
• Cheapest 1-stop and 2-stop options, but reject them when they violate event timing or create unreasonable risk.
• Prefer total route duration under 14 hours when possible; for long-haul routes where this is impossible, use it as a benchmark and explain the best achievable duration.
• Try to avoid any single travel leg or one-way trip over 24 hours. Include trips over 24 hours only when they are uniquely cheap, uniquely late/early, or otherwise satisfy a user constraint that no shorter option satisfies.
• Apply dominance filtering: if an option has no advantage over another viable option, do not include it. Drop any flight that is worse or equal on all relevant dimensions such as cost, duration, departure/arrival timing, stop count, booking risk, and points value.

For hard arrival constraints, use absolute dates and local times. Include buffer judgments explicitly, for example: "arrives 4:50 PM for a 6 PM wedding, rejected as too tight."

Points And Portal Valuation

When points are involved:

• Treat points as money with real opportunity cost.
• Use USD for all reported prices and net costs. Convert foreign-currency source prices to USD using a live exchange rate and state the rate or source briefly.
• Compute net cost in USD as the total economic cost to the user: cash paid plus points valued at the user's redemption/opportunity value.
• Compare the portal fare against the same or closest public itinerary before evaluating point value.
• Calculate actual cents per point as public comparable cash fare / points required.
• Flag portal inflation when portal cash price exceeds public fare for the same itinerary.
• Do not say points "save cash" when the user spends all points; say whether the redemption is economically good.
• Keep the final decision matrix simple, with a single net-cost column and no separate before/after or fake savings columns.

For card-portal examples such as Chase Travel:

• A 1.5x portal multiplier means each point can cover 1.5 cents of portal fare, but actual value may be lower if the portal fare is inflated.
• A 1.25x multiplier follows the same rule.
• If points were transferred between cards, verify the destination card balance or assume only after the user confirms transfer success.

Output Matrix

Return a compact table that contains only viable or decision-relevant options. Include:

• Build type: round trip, separate one-ways, portal, airline-direct, OTA, or mixed.
• Source.
• Booking channel.
• Link to the source/search/result when available.
• Airline and flight path.
• Outbound departure datetime.
• Outbound arrival datetime.
• Return departure datetime.
• Return arrival datetime.
• Duration for each leg or total duration when clearer.
• Stops and layovers.
• Net cost for all passengers in USD.
• Points required if applicable.
• Actual point value if applicable.
• Notes: timing risk, baggage caveat, fare inflation, overnight layover, self-transfer risk.

After the table, give a short decision matrix:

• Best overall.
• Cheapest acceptable.
• Fastest acceptable.
• Not worth it / rejected.
• Final recommendation with the concrete booking path.

Final Recommendation

End with an explicit booking recommendation. Do not leave the user to infer the path from the table. State:

• Whether to book a single round trip, separate one-ways, or a mixed/piecemeal build.
• The exact source for each bookable piece, such as a card travel portal, airline-direct, Google Flights-selected OTA, Skyscanner OTA, Kayak hacker fare, Kiwi, or Skiplagged.
• A link for each bookable piece when available.
• Whether to use points or cash for each piece.
• The reason for each source choice, especially portal inflation, point value, timing risk, or schedule quality.
• The backup option if the preferred fare disappears before booking.

Use direct language: "Book this as two one-ways: outbound through the portal with points if the portal fare is still within $X of public fare; return cash through the airline because the portal is inflated." Replace any conditional with a completed live check whenever the source is accessible.

Booking Safety

Do not book, pay, transfer points to external airline/hotel partners, or submit a purchase without explicit action-time authorization. Internal point combining between the user's own eligible cards may proceed only when the user clearly authorizes the exact source/destination/amount; verify the review screen before submitting.