01
Taste extraction
The model reads your brief and extracts your actual preferences: what you love, what you want to avoid, how you pace a day and what kind of trip this is. Vague preferences are turned into planning constraints.
How the AI works
Taste in, paced plan out
Designing a personalized, walkable itinerary from a few fuzzy preferences is a genuine language-model task. It is the core of Wander, not a bolt-on. Here is how it works, honestly.
Three jobs
What the model actually does
Turning a destination, dates, a budget and a handful of tastes into a day-by-day itinerary with real pacing, walkable clusters and honest notes is a writing and reasoning task. A regular algorithm cannot do it: the output needs to feel personal, and the notes need a voice. A language model is exactly right for this.
There are three distinct jobs: understanding your taste and constraints, designing a paced plan around them, and adapting that plan when you change your mind. Each step gets the right model at the right cost, and none of them is asked to do something a simpler system could handle.
The pacing rules, the walkability constraint and the Zod validation schema are all in code. The model designs the plan. The code enforces it and rejects anything that does not pass. If the model fails completely, a built-in planner in code produces a basic plan as a floor. You always get something back.
Part A
Understanding your taste and constraints
Your brief, written in plain English, destination, dates, budget, pace, and a sentence about what you love, is passed to the model with a structured prompt that explains the rules: one walkable area per day, honest notes only, tags must be earned, nothing sponsored.
02
Constraint validation
The output is required to conform to a Zod schema: one area per day, stops with tags (worth-it, optional, skip), a note for each, rough timings, and a day-level summary. Anything that fails validation is rejected and regenerated.
03
Honest notes
Every stop gets a short note in a real voice: a reason, a time, a trade-off. The model is prompted to say skip when something is not worth it, because a plan that cannot skip is not honest.
04
Walkability check
Each day is checked against the walkability rule in code: all stops in one area, no cross-city transit. A day that fails the check is flagged and either regenerated or rebuilt by the cluster algorithm.
Part B
Model-agnostic routing
The application code asks for a task, not a model: it calls complete({ task: "design" }) and gets a plan back. Which model answers, which lab provides it and what the fallback chain is are configuration decisions in one file. Changing a route is one line. Adding a lab is one case in a switch statement.
This matters because labs change prices, add rate limits, and occasionally have bad hours. Wander routing through one provider forever makes a lab's policy your product's problem. The model-agnostic layer means it is a configuration change instead.
In this deployment the OpenAI adapter is live. The other providers are declared with their real model names and switch on the moment their key is present.
Routing
The table, generated from the code
This is not a diagram somebody drew. It is rendered from the same routing configuration the planning engine reads. If it is wrong here, it is wrong in production.
| Task | Model | Provider | Tier | USD per M tokens |
|---|---|---|---|---|
| Design the full day-by-day itinerary from your brief | gpt-4.1-mini | openai | balanced | $1.60 |
| Rebuild the affected day after you tweak the plan | gpt-4.1-mini | openai | balanced | $1.60 |
Fallback chain
If the routed model fails or returns nothing, the call walks a chain of candidates: gpt-4.1-mini, then claude-sonnet, then gpt-4.1, then gpt-4.1-nano. Providers with no key configured are skipped silently. One provider having a bad hour should not lose a customer their trip plan.
The built-in planner
If every model in the chain fails, a deterministic planner in code produces a basic day-by-day plan from your brief. It will not write notes or cluster stops as well as a language model, but it means you always get something back. It is the honest floor, not the intended product.
Candidates
What is wired, and what is one key away
Every model below sits behind the same interface. Adding a provider is one case in one file. The models that are one key away switch on the moment that key is present in the environment.
gpt-4.1
frontieropenai · 1,000,000 token context
- long multi-city routes with many constraints
- balancing an unusual mix of tastes across many days
gpt-4.1-mini
balancedopenai · 1,000,000 token context
- designing a paced day-by-day itinerary
- writing honest worth-it and skip notes
gpt-4.1-nano
fastopenai · 1,000,000 token context
- a quick single-day rebuild after a small tweak
claude-sonnet
frontieranthropic · 200,000 token context
- careful, natural travel writing
- nuanced pacing judgement
gemini-flash
fastgoogle · 1,000,000 token context
- high-volume planning at low cost
llama-open
openmeta · 128,000 token context
- self-hosted planning for privacy-first deployments
No model is trained on your trip data, by us or by our providers, under the API agreements we use.
Honesty
What the planner cannot know
Saying this is the most useful thing on this page.
Hours and prices change
Wander plans from a broad knowledge of places and how they fit together. Hours change, places close and prices move. Every itinerary says so. Confirm the specifics, opening times, tickets and reservations, before you rely on them.
A plan is not a guarantee
An itinerary is a well-paced starting point designed around you. It is a suggestion, not a contract. The place may be closed, the queue may be long, the weather may change. Wander designs the trip. You decide how to run it on the ground.
Nothing is sponsored
A worth-it note was earned by the place, not paid for. Wander makes money from subscriptions. That is the only business model that keeps the honesty real, because a plan that steers you somewhere for money is not honest.
The explanation is written, not computed
The language model writes the notes and the plan. Notes can be poorly phrased. Recommendations can miss something a local would know. Nora Bishop, our Head of Travel Editorial, sets the standards the model is prompted to meet. The model does not always clear that bar.
Wander's itineraries are suggestions, not guarantees. The full stance is on the Care page.
No training on your trips
Your trip data is sent to a language model to produce your itinerary and for nothing else, under agreements that prohibit training on that traffic.
Nothing sponsored
No stop in your plan is paid placement. Wander earns from subscriptions. That is the only model that keeps the notes honest.
Export or delete anytime
Your trips belong to you. Export as PDF or delete from Settings at any time.