Where the time goes when an AI plans a trip

A traveler experiences one number: how long until the trip is ready. Engineers can't change that number directly. They can only change the stages underneath it, and most of the useful work is figuring out which stage the time actually belongs to.

Trip creation is a chain. Understand the request, settle the route, plan the days, find and check real places, schedule them, review the draft, save it. Some links must wait for the one before. Some can run side by side. And one, waiting for the traveler to answer a question, shouldn't count at all. A single total hides all of that.

This article describes how Platix structures that chain so its time can be explained, and what we change first when a trip feels slow.

Time the same stages the traveler sees

The progress screen tells the traveler what is happening: Understanding your trip, Building your route, Drafting your itinerary, Checking places and timing, Reviewing the draft, Saving your private trip. Those labels aren't decoration. Each one corresponds to a stage the backend records as the work advances, which is how the screen can survive a refresh and show the same position in another tab.

Timing uses the same boundaries. One trace identity follows a trip from request to save, with a duration for each stage. When the traveler's label and the engineer's timer share a boundary, a slow stage is visible to both, and nobody has to guess whether "it took ages" meant the model, the providers or the save. How to show honest progress while AI builds a trip covers the traveler's side of that contract.

Separate waiting from working

Three kinds of time hide inside one total, and they need different fixes.

• Queue time is work waiting to start. The traveler sees it as Waiting to build your trip. It's a capacity problem, not a planning problem.
• Traveler time is the system waiting for an answer to a clarifying question. It belongs to the traveler, and counting it as latency would punish the planner for asking a question that was worth asking.
• Working time is everything else: model calls, provider calls, scheduling and the final save. This is the time engineering can actually shorten.

Overlap what is independent, order what is not

Some work doesn't depend on its neighbors. Researching places for day three doesn't need day two's answer, so Platix's day planner runs the model and provider work for different days concurrently. Several independent lookups that run at the same time cost roughly the longest one in wall time, not the sum of all of them.

Other work must stay in order. Placing stops into days runs in route order, so when two days could use the same place, the earlier day gets it, the same way every time. That ordering costs a little speed and buys something more valuable. Given the same candidates, placement produces the same arrangement, so a change in the result points to a change upstream, not to whichever call happened to finish first.

This is why a trace keeps two numbers. Wall-clock time is what delayed the traveler. Aggregate call time is how much work actually happened, which matters for cost and load even when concurrency hides it from the traveler.

Budget the whole trip, not each call

A per-call timeout stops one slow request. It does nothing about a long trip that quietly makes many more requests than a short one.

Platix gives each trip one shared budget. It meters model requests, place searches, place details and route lookups across the whole plan. The budget grows with the length of the trip and has a ceiling. A three-week itinerary is allowed more work than a weekend, but no trip can multiply its work without limit. That makes both latency and cost predictable from the shape of the trip before the first call is made.

Make repair earn its time

Review often finds something fixable: a requested stop that didn't fit, a suggested stop outside its opening hours, a day that came out thin. Each fix costs time, and an open-ended repair loop turns a quality feature into a latency problem.

So repair is bounded. A day with a specific, fixable gap gets one extra look, and the result is kept only if the day actually gets better. Time is spent where there is a named gap, and only the improvements are kept. What can't be fixed within that bound is disclosed on the trip rather than retried out of sight, which is the subject of Why a partial itinerary can be better than no itinerary.

Compare like trips with like trips

A weekend in one city and a multi-country rail trip don't have the same workload. Latency analysis keeps a few broad descriptors of complexity, such as the number of days, route segments, selected places, the planning strategy and whether repair ran. A slower week may simply contain longer trips. A repaired trip shouldn't be compared blindly with one accepted on the first pass.

Medians describe the ordinary case and high percentiles describe the slow tail, and neither means much without a sample size and a time window. Failed attempts are reported separately, because a fast failure is not a performance win.

Measure without copying the trip

None of this needs the traveler's words. A useful trace keeps stage names, versions, start and finish times, call and token counts, broad complexity measures, stable failure codes, and whether the result was complete, partial or blocked. It leaves out the request text, the itinerary and anything about the traveler. The trace explains the system's behavior without becoming a second copy of someone's holiday.

What we change first

Once the stages are visible, the order of work is usually clear:

• If independent work runs one after another, change the dependency graph so it overlaps.
• If place research dominates, cut detail lookups the ranking doesn't use and share lookups between days.
• If model input keeps growing, tighten what each stage is given.
• If the trip is saved but the browser is still waiting, fix the handoff, not the planner.

Every change is checked against quality as well as speed. Skipping review makes trips faster and worse. Trimming place details the ranker relies on makes them faster and wrong.

Two minutes is the start of the question

"Trip creation took two minutes" is where an investigation starts, not where it ends. The useful questions are which stage changed, for which kind of trip, and with what effect on the result. A system built to answer them — stages the traveler can see, waiting kept apart from working, overlap where it's safe, one budget per trip and repair that has to earn its time — can get faster without getting worse.