Plan a trip itinerary with AI
An AI itinerary is strong on shape and weak on facts. Let the model build the days, then take every hour, fare and address to the operator.
Ask any chat model for a five-day itinerary and you will have one inside a minute, and it will look excellent. Neighbourhoods with a line each on why they suit your group, a walking route that makes geographic sense, the big museum parked on the morning you will still have energy. Then you land, and the museum closes on Tuesdays, the restaurant shut two years ago, the train takes ninety minutes rather than the forty you were promised, and the ticket costs almost double.
Trip planning is the everyday job where a general chat model fails most reliably. The failure has a shape you can predict and route around. Anything carrying a date, a price or a timetable is the part it will invent. The structure underneath it, the sequencing, and the honest judgement about how much a person can do between breakfast and dinner: that is the part it does genuinely well.
Where the confident answer comes apart
A language model produces the most plausible next stretch of text, and a plausible set of opening hours is 10:00 to 18:00, closed Mondays, last entry an hour before. That sentence is well formed, common in the training data, and completely untethered from the museum you asked about. Nothing in the machinery separates a fact the model absorbed from a pattern it completed, which is why a wrong answer arrives with the same confidence as a right one. We wrote up the mechanism in why models invent facts.
Travel makes this worse than most subjects, for a reason that has nothing to do with the model: travel facts change often and the pages describing them are rarely updated. A guide written in 2019 can still rank, and an operator can change a Sunday timetable without any of the round-ups quoting the old one ever noticing. So even where the model read something real about your destination, what it read was probably stale, and it has no way to tell an expired fact from a current one.
The categories that go wrong are narrow enough to memorise:
opening hours, and above all the weekly closing day
ticket prices, and which ticket you actually need
journey times, and whether a connection runs on your date
whether a restaurant, bar or small museum still exists
seasonal opening, which is how summer advice quietly ruins a February trip
Every item on that list is checkable in under a minute against a page its owner controls. None of them should reach your calendar on the model's word alone.
Tell it the six things that change the answer
Most disappointing itineraries come from a thin prompt. "Four days in Lisbon" gives the model nothing to optimise against, so it returns the average of every Lisbon guide it has absorbed, roughly the itinerary you would have found yourself. Six pieces of information change the output more than any phrasing trick. Write the exact dates rather than a season, because a specific date lets the model reason about a weekday, a public holiday and a shoulder season instead of a generic month. Then say who is coming, with ages and walking pace: two adults who cover 15km a day cheerfully and a group carrying a four-year-old and a grandparent deserve different days in the same city.
The next two constraints decide whether the plan survives an actual afternoon. Give a daily budget and say what it covers, because otherwise the model assumes, usually generously. Then give a walking ceiling, the most useful sentence you can write and the one almost nobody writes. "No more than 5km on foot per day, with a sit-down break every two hours" reshapes an entire itinerary in a way that asking for a relaxed pace never does.
Finish with your refusals and your goal. Refusals are concrete: no starts before nine, no queue longer than half an hour, nothing that needs booking three weeks ahead. The goal is one sentence about what you want out of the trip, whether that is food, rest, art, or a child who sleeps. Then ask the model to put five questions to you that would change the plan. It is unusually good at that, and it costs one turn.
What can a model actually settle for you?
It helps to be blunt about the division of labour, because the useful half gets undersold by people who have only noticed the invented opening hours. Here is the split across decisions a traveller has to make anyway.
The decision | What the model settles well | What it cannot settle | What skipping the check costs you |
|---|---|---|---|
Where to base yourself | Which areas suit your group, budget and walking radius, and why | Which hotel has rooms on your dates, at what rate, on what terms | A well-argued neighbourhood and a room rate that was never real |
What order to see things in | A day sequenced so you never cross the city twice | Whether Tuesday is the closing day at the one place you came for | A morning spent outside a locked door |
How much to fit into a day | The honest cut, three stops instead of six, given a 5km ceiling and a nap | How long the walk really takes with roadworks and August heat | A schedule that collapses by two in the afternoon |
Where to eat | A shortlist matched to a budget, a diet and a ten-minute walk | Whether it still trades, its hours, whether it takes bookings | An evening spent outside the closed and the vanished |
Getting between cities | Which mode suits your luggage, group and the gap in your day | The timetable, the fare, and whether the route runs on a Sunday | A connection that does not exist on the day you travel |
What the trip will cost | The shape of the budget and where the money concentrates | The current price of anything at all | A total that is wrong in a direction you cannot predict |
Read that table left to right and you have the method. The middle column is judgement and sequencing, which a model does faster than a tired person with fifteen tabs open at midnight. The right-hand column is facts held by somebody else, and each has an owner with a website.
Web search is the hinge, and the free plan gives you two
All of this changes if the model can look things up while it answers. A searched answer separates a composed paragraph from one carrying a source you can click. Two limits shape how you use it. Not every model can run a search: 13 of our 59 active models can, seven from Anthropic's Claude family and six from Google's Gemini family. On the free plan the qualifying list is three, all Gemini Flash Lite entries, with an allowance of two web searches per 30 days on a fixed window.
Who decides when to search is the part people get wrong. On the web app, Intent Detection is on for every new account: it reads your message and searches when the question looks like one about the current world. The count happens on the server, so a detected search spends one of your two exactly as a pressed one does. Turn it off in Settings, then Tool Preferences, and a Search pill appears for you to press.
The two-searches allowance behaves better than it sounds, because of how it is counted. The unit is a request with search enabled rather than a query. One request that sends the model off to check six museums fires several queries and still spends one unit, so the move is one dense verification request instead of six thin ones: "Search for the current opening days and hours of these six places for the week of 16 November, and give me the source link for each." One turn, one unit, most of the risk retired.
Two conditions. Search is off entirely if you are not signed in, and the app says so. On mobile the search control is subscriber-only, so a free account spends its two verification requests in the web app.
The pill also picks the back-end: OpenAI Web Search, Google Search, Anthropic Web Search or Perplexity Sonar. Search and image generation are mutually exclusive in a turn, so turning one on turns the other off. And even with search running, read the citations rather than the summary: open two and check the date on the page, because a model quoting a 2021 post about a timetable is doing what it did without search, now with a footnote attached.
A photograph outranks a memory, and the operator outranks both
One move beats every prompt in this article, and it arrives the moment you are there. Photograph the sign. 46 of the 59 active models accept an image, 14 of them on the free plan, so the printed timetable in the station hall and the hours board bolted to the museum wall are things you can hand over directly. The model is then reading a statement the operator made themselves rather than reconstructing one from training data. Ask it to transcribe before interpreting, so you catch a misread number before it becomes a plan.
Documents come through a narrower gate. 24 of the 59 models accept a PDF upload and the picker will not let you attach one to the other 35. Four of those 24 sit on the free plan, GPT-5.4 Nano and the three Gemini Flash Lite entries, with one attachment per message at up to 10MB, three per day. A booking confirmation from an airline or a hotel is ordinary text underneath, so it comes through cleanly and the model can lift the reference number, the times and the change terms into the day plan.
Scans deserve their own warning. On a signed-in account, a PDF with no text layer goes through our OCR first, up to 20 pages, and the model reads that transcription, which may garble a digit. Longer scans skip it, and a model with native PDF support gets the file itself, which may well render the pages, but that is not something to build a travel day on. For the page you care about, photograph it and send it as an image.
Everything you have not photographed yourself falls under one standing rule. Every address, opening time, price and connection goes to the operator's own page before you commit to it: the museum's site, the railway's timetable, the restaurant's booking page. The model does not count as a source here, and neither does an aggregator working from somebody's 2022 summary.
This is less work than it sounds. The itinerary has already narrowed the field to a fixed list of specific facts rather than a city to research. Budget five minutes per day of the trip.
Two things we do not do, stated plainly. MultiChats books nothing, and it carries no live prices, no seat availability and no map. What you get is a shortlist and a shape.
Mid-trip, when the plan meets the weather
A plan survives about half a day. What you want from the model at that point is a repair rather than a fresh itinerary, and the difference lives in what you paste back. Give it five things: the time now, where you are standing, what went wrong (it rained, the place was closed), what is left on today's list, and any hard deadline, like a train at six. Then ask for the rest of today only. It will re-sequence what remains and drop the stop that no longer fits, none of which asks it to invent a fact.
To compare two versions of a day, read the label before you press it. On web, Try Again opens a new thread holding the alternative and leaves your original standing, so you end up with two threads to switch between. On mobile the same words do something else: Try again replaces the response you were looking at and the old one is gone, while Branch here keeps both. There is no view that puts the two versions beside each other.
Some housekeeping for a long trip. A trip thread grows, and a long thread starts to lose its early details: see what a context window is. Once it has sprawled, ask for a tight summary of the confirmed plan, open a fresh thread and paste it in. On a paid account the fixed constraints, allergies, the walking ceiling, the ages of everyone travelling, can be stored as memories, so the brief stops being retyped.
One note on privacy, since a trip brief carries personal detail. We do not train on your conversations. What the provider behind a given model does with them varies by model, and the models where we know of a difference carry a notice on their info card in the picker.
The brief is where the work sits. A model that has your dates, your pace and your refusals will sequence the days sensibly and hand back a shortlist. The shortlist still has to be walked through the pages whose owners answer for the hours and the fares. Use the model to organise the itinerary, then check the opening hours and travel details yourself.