How it works

Say something like:

• New York but warmer winters
• Tokyo but less humid summers
• Seattle but sunnier

Just a city name works too ("Tokyo" returns climatic twins), and so does a description without a starting city ("somewhere hot and dry"). The template is starting city + what to change; either half is optional.

Every one of the 230 reference cities has a detailed climate fingerprint: monthly averages of 8 weather variables (temperature, humidity, rainfall, wind, sunshine, cloud cover, pressure, dewpoint) for each month of the year. That's 96 numbers per city, built from hourly observations over 2023–2024 from the Open-Meteo ERA5 archive.

Your query gets converted into a modified fingerprint: start from the fingerprint of your anchor city, then shift the numbers your query asked about. "Sunnier" bumps up sunshine and cloudiness dims. "Warmer winters" only bumps the December/January/February temperatures.

The app then ranks all 230 cities by how close their fingerprints are to your modified target. Dimensions you explicitly asked about carry more weight, but every dimension influences the final score.

Two ranking algorithms sit behind the Auto mode:

• Classical.Looks up your anchor city's climate fingerprint, shifts the dimensions you asked about (warmer, drier, sunnier, etc.), and finds the cities closest to the modified target. Best when you mention a city or any specific climate adjustment.
• Smart (Contrastive). A small neural network trained on 10,000 example queries that maps both your free text and each city's climate fingerprint into a shared 32-dimensional space, then ranks by how close they sit. Best when the query is pure description — "alpine vibes", "Mediterranean climate" — with no structured tweak the classical lookup can use.

Auto picks for you. The rule: if we can extract a city or any specific climate adjustment from your text, we use the classical lookup. If we can't extract anything structured, we fall back to the smart model. We evaluated both rankers across 3,150 synthetic queries against a closed-form measure of how well each one moves along the dimensions you asked about — the classical lookup wins decisively whenever the vocabulary covers your intent, which is the common case.

You can override the router with the toggle next to the search box, or add ?compare=1 to the URL to see both rankings side-by-side on every query.

The recommender refuses to fake an answer in three cases. Each one shows you a message instead of a ranking that pretends to satisfy your query:

• City not found. "Hogwarts but sunny" — we caught "Hogwarts" but couldn't place it on the map. You get a did-you-mean list rather than a ranking around a fictional anchor.
• You contradicted yourself."Drier and more humid" pulls in opposite directions on humidity, so any ranking would be unreliable. We tell you which two adjustments contradict and ask you to pick one.
• You're already at the extreme."Singapore but more humid" — Singapore is at the top of our humidity scale, so the closest neighbors are slightly lesshumid than Singapore itself. We surface a "you're already there" message rather than misleading you with cities that look reasonable but don't actually satisfy the request.

These guards together reject roughly 5% of queries — the ones where any ranked answer would have been quietly wrong. The other 95% benefit from the same evaluation that decided when to surface them.

The score is deliberately honest. If you ask for an extreme change (e.g. "Seattle but much sunnier"), even the top match will show a modest percentage — because no real city has Seattle's climate and desert-level sunshine. The ranking still tells you which city is closest to your intent; the score tells you how close that best match actually is.

Expand any city card in the results to see a list of dots, one per weather dimension. They mean:

• ●Green — fits. If you asked to change this dimension, the city moved the way you asked. Otherwise, the city stays close to your starting city here.
• ●Gray — trade-off.The city is noticeably different from your starting city on this dimension — enough to count as a real trade-off, not just normal variation between cities. The +/− shows which way it differs, not whether that's good or bad.

The numbers beside each dot are real averages in real units (°C, %, mm/h, km/h) — not LLM-generated prose. That's the whole point of the breakdown: you can sanity-check the ranking against actual climate data.

The Explorer projects all 230 cities from their 96-number fingerprints down to a 3D scatter so climatically similar cities sit close together. You can rotate the plot by clicking and dragging. The three axes are automatically named (e.g. "Summer heat and humidity", "Mild overcast winters", "Big seasonal swing") based on which monthly features drive them, so the map is readable without a statistics background. Type a query on that page and a red marker appears where your modified target lands — useful for seeing visually which cluster fits your intent.

• Only the 230 canonical cities are ranked. If you anchor to a city outside that list ("Beirut", "Cedar Rapids"), the app fetches its data on demand — expect a ~10-second wait the first time that city is ever requested.
• One modification per query is still the sweet spot. Two-vibe queries ("warmer winters anddrier summers") work — the direction stays right — but each adjustment applies at full strength, so the resulting ranking moves about 10% less in σ-space than a single-vibe query. Outright contradictions ("drier and more humid") get caught by the conflict guard before they reach the ranker.
• The dataset covers 2023–2024. It's current but not a 30-year climate normal, so an unusually hot or cold year nudges every fingerprint a bit.
• This is about climate, not weather. It won't tell you about next Tuesday.

Historical weather data from Open-Meteo. Natural-language parsing via OpenAI with constrained structured outputs. Source code at github.com/YardenMorad2003/weather-ml-v2.