Let me concede something upfront: the current generation of multi-city routing tools — ITA Matrix, Google Flights multi-city mode, the GDS fare shopping engines scraping published fares across 400-plus carriers — genuinely solve the combinatorial problem. A five-city itinerary touching three alliance partners can produce thousands of valid routing permutations before a single fare rule enters the picture. Brute-forcing that by hand is nobody's definition of productive. That part works. What does not work is the assumption that finding a route is the same thing as optimizing a fare construction. The routing is the easy half. Fare rules, booking class availability, stopover provisions that actually govern what a ticket costs — most tools either skip that math or get it dangerously wrong.

TL;DR

Red Flag #1: The Tool Cannot Parse Fare Basis Restrictions

You paste in a five-segment itinerary. The tool returns a price. What it does not return is the fare basis code governing each segment — or, worse, it shows you a fare basis but cannot tell you what the letters actually mean.

A fare basis is not a label. It is a compressed rule set. Take something like VLXP7DUS on a transatlantic carrier. That string encodes the booking class (V), the fare family (LX), the advance purchase requirement (P7 — seven days), the directionality constraint (D), and the market (US). Every letter carries a restriction that determines whether the fare survives your construction. Change the outbound to a different day and the P7 window closes. Route through a gateway not covered by the directionality flag and the fare breaks entirely.

Most multi-city tools treat the fare basis as decoration. They surface the total price and maybe a booking class letter, then call it done. If your tool cannot decompose the fare basis into its component restrictions and validate each one against your proposed routing, you are looking at a number that may not exist when you try to issue the ticket. That is the foundational problem. Everything downstream gets worse.

Red Flag #2: No Real-Time Booking Class Availability Check

Here is how a phantom fare happens. The tool queries published fares. It finds a K class fare on segment two priced at a reasonable level. It builds the itinerary around that fare. You click through to book. The K bucket on that specific flight has zero seats. The next available class is B, which costs $400 more per segment. Your five-city itinerary just moved by $800 or more, and the tool never warned you.

Published fares and available fares are different databases. A carrier files thousands of fare records in ATPCO. Those fares exist as pricing rules. Whether a specific booking class has inventory on a specific flight on a specific date is a separate question answered by the availability system — typically queried through a GDS or the carrier's direct channel. The two systems do not automatically agree.

Any routing tool that shows you a fare without simultaneously confirming that the booking class governing that fare has seats on every segment of your construction is showing you a hypothetical. Hypotheticals do not ticket. Real-time availability verification on every segment, for the exact booking class the fare requires, is not optional. It is the minimum standard for calling the output actionable.

Red Flag #3: Mileage Redemption Math Without Opportunity Cost

Award routing tools are especially guilty of this. They show you the miles required and the taxes. They might even calculate a cents-per-mile figure. What they almost never do is frame that number against the opportunity cost of spending those miles on this particular redemption.

Let me walk you through the arithmetic that matters. Say a tool surfaces a business class itinerary — three cities, two carriers, 85,000 miles plus $387 in carrier surcharges and taxes. The equivalent cash fare on a paid ticket is $3,200. Simple division: $3,200 minus $387 equals $2,813 in value extracted from 85,000 miles, which is 3.31 cents per mile. That sounds reasonable.

But here is the part the tool skips. Those 85,000 miles, if deployed on a different route with lower surcharges, could yield 4.5 cents per mile. On a partner redemption with no fuel surcharges, the same miles on a different construction could deliver $3,825 in value — a delta of over $1,000 in opportunity cost. The tool showed you one number. The real question was whether that number was the best available use of a finite resource. Without a baseline comparison across at least two or three alternative deployments of the same mileage balance, the redemption math is incomplete. A tool that cannot model opportunity cost across routes is a calculator, not an optimizer.

Red Flag #4: Stopover and Open-Jaw Rules Are Missing or Hardcoded

Stopovers are where multi-city routing either saves you serious money or silently doubles the fare. The rules governing them vary by carrier, by fare family, by routing direction, and sometimes by the specific market pair. A tool that either ignores stopover provisions or hardcodes a generic assumption — one free stopover per direction, say — will misconstruct your itinerary in ways you will not catch until the fare audit at ticketing.

Consider a Star Alliance construction routed LHR–IST–BKK–NRT–SFO–LHR. Whether you can stop in Istanbul for three days without repricing the outbound depends on the specific carrier's stopover rule for the fare class you are holding. Some carriers allow a free stopover at their hub on through fares. Others charge a flat stopover fee. Others prohibit stopovers entirely on discounted fare families and require you to price each segment as a separate one-way — which destroys the round-trip pricing advantage.

Open-jaw rules add another layer. Can you fly into Tokyo and out of Osaka without repricing? That depends on whether the carrier's rule treats KIX and NRT as the same pricing point for jaw purposes. If the tool does not know the carrier-specific jaw allowance for the fare family you selected, it cannot tell you whether the open-jaw saves money or costs more than the closed routing.

Red Flag #5: Alliance Partner Fares Treated as Interchangeable

This one burns people constantly. A tool surfaces a Oneworld routing with segments on three different carriers and prices it as a single construction. The price looks competitive. The problem: not all published fares on carrier A are available for interline ticketing on carrier B, even within the same alliance.

Alliance membership means codeshare agreements and reciprocal frequent flyer earning. It does not mean universal fare access across all partners. Special promotional fares, web-only fares, and deeply discounted fare families are frequently restricted to the ticketing carrier's own metal. A W class fare on one carrier might interline fine with a partner. The same booking class letter on a different carrier within the same alliance might not.

When a tool treats all alliance partner inventory as a single pool, it assembles Frankenstein itineraries — routings that look valid on paper but require fare combinations that no ticketing system will actually issue. The segments are real flights. The fares are real fares. The construction, as priced, is fiction. You need a tool that understands which fares interline and which do not, carrier pair by carrier pair.

Red Flag #6: No Advance Purchase Window Modeling

The advance purchase requirement is one of the most powerful levers in fare construction, and most multi-city tools ignore it completely. They show you today's price. They do not model what happens if you book fourteen days earlier or seven days later.

Advance purchase rules — typically filed as AP requirements in the fare rule paragraphs — create hard cutoffs. A fare available at T-21 (twenty-one days before departure) might vanish entirely at T-20. The next available fare in the same booking class could be $200 higher per segment. On a four-segment multi-city itinerary, missing a single advance purchase window by one day can move the total price by $600 to $800.

A tool that optimizes routing without modeling the AP windows on each segment's governing fare is optimizing in a vacuum. The cheapest construction today might not be the cheapest construction if you had searched three days ago — or if you wait two days. Showing one snapshot without indicating where the AP cliffs fall is like showing the price of a stock without the expiration date on the option. The time dimension is not optional context. It is the second axis of the optimization problem.

Red Flag #7: Output Shows Routes Without Fare Rule Citations

This is the transparency test. When a tool shows you a multi-city routing and a price, does it also show you which fare rule governs each segment? Can you read the rule text? Can you verify the restrictions yourself?

If the answer is no, you are trusting a black box. Fare rules are public documents filed with ATPCO. They are not proprietary secrets. Any tool that claims to optimize multi-city fare constructions but cannot surface the rule paragraphs — advance purchase, minimum stay, maximum stay, routing restrictions, combinability — is asking you to trust its interpretation without showing its work.

The practical consequence is that you cannot audit the construction. You cannot check whether the Saturday stay requirement on segment three actually applies given your travel dates. You cannot verify whether the routing restriction on the governing fare permits the connection point the tool selected. You are paying for an answer without seeing the equation. In any other field, that is called a guess.

Red Flag #8: The Optimization Is Just Cheapest-First Sorting

The most common failure. A tool generates twenty possible multi-city routings. It sorts them by total price, lowest first. It presents the cheapest option as the "optimized" result. That is sorting. That is not optimization.

Optimization requires a defined objective function with constraints. Price is one variable. But the constraint set for a real multi-city itinerary includes minimum connection times, maximum elapsed journey time, booking class flexibility for changes or cancellations, stopover allowances, mileage earning rates on the operating carrier, and sometimes visa transit requirements at connection points. A $1,400 routing that earns zero redeemable miles, forces a six-hour layover in a terminal with no transit visa exemption, and is locked into a non-refundable fare with a $300 change fee is not better than a $1,600 routing that earns 12,000 status-qualifying miles, allows a free stopover, and has a $75 change fee.

Cheapest-first sorting throws away every variable except one. A genuine optimizer weights the objective function across multiple dimensions and lets you set which constraints are binding. If the tool cannot do that, it is a price comparison engine with a better user interface.

The Verdict

Most multi-city routing tools solve the wrong problem well. They find routes. Routes are cheap. What costs money — what determines whether a construction actually works at the ticket counter — is the fare rule architecture underneath. A tool that cannot parse fare basis restrictions, verify booking class availability in real time, model advance purchase windows, and surface the governing fare rules for your inspection is a search engine, not an optimization engine.

The honest recommendation: use these tools for what they are good at, which is generating candidate routings. Then do the fare rule verification yourself — in a GDS, through the carrier's direct channel, or with a fare construction reference that lets you read the actual rule paragraphs. The tool finds the shape. You confirm the math. Until a tool can reliably do both, the second step stays manual.

FAQ

How do I verify booking class availability on a specific segment?

Query the segment directly in a GDS — Sabre, Amadeus, or Travelport — using the availability command for the specific date and flight number. The response shows every booking class with the number of seats available in each bucket. If you lack GDS access, ExpertFlyer or similar subscription services provide the same data through a web interface. Do not rely on the fare displayed by a shopping tool as confirmation that the booking class has inventory.

What is a reasonable cents-per-mile target for award redemptions?

There is no universal number because the baseline depends on the cabin, the route, and the carrier's surcharge structure. As a working framework: anything above 2.0 cents per mile in economy is acceptable, above 3.5 in premium economy is strong, and above 5.0 in business class represents a high-value deployment. Below those thresholds, cash fares may offer better value per dollar spent when you factor in the miles you would earn on a paid ticket.

Can ITA Matrix handle multi-city fare construction validation?

ITA Matrix excels at fare shopping and displays fare basis codes, routing details, and pricing breakdowns that most consumer tools suppress. It does not, however, perform real-time availability checks on the booking classes it prices. The fare it shows you may reference a booking class that has no seats on your specific flight. Treat ITA Matrix output as a pricing hypothesis that requires availability confirmation through a separate channel before booking.

Why do multi-city fares sometimes increase when I remove a segment?

Removing a segment can break the fare construction's routing logic. Some round-trip or circle-trip fare rules require a minimum number of segments or specific connection points to qualify for through-fare pricing. Drop a segment and the remaining itinerary may no longer satisfy the routing restriction on the governing fare, forcing the system to reprice each remaining segment as a standalone one-way — which almost always costs more than the constructed fare it replaced.