Skip to content
Joru
On-device AI

The AI runs on your phone. Not on someone else's server.

Almost every AI trip planner sends what you type to a data centre, waits for an answer and bills someone for it. Joru does the reasoning on the phone in your hand. This page explains exactly what that changes — and what it does not.

What “on-device” actually means here

Joru ships with a language model small enough to run on a modern phone. When you fill in the travel form, that model — sitting in the app, on your hardware — reads what you wrote, arranges the days and writes the guide. Nothing about that step involves a network request.

This is a genuinely different architecture, not a privacy setting. There is no toggle to send your data to a server, because there is no server to send it to. An app that processes your prompt in the cloud and promises not to keep it is asking you to trust a policy; an app that never transmits the prompt is not asking you to trust anything.

What leaves your phone, and what never does

Joru is not an offline app, and it would be dishonest to sell it as one. It needs the internet to find real places, load map tiles and read the weather. What matters is the split between the two:

  • Never leaves: your travel form, your preferences, the itineraries the model writes, your budget, your spending log and your notes.
  • Goes out: what a map needs — a place name or a map area — to look up real locations, tiles and forecasts from OpenStreetMap, Wikivoyage and Open-Meteo.
  • Optional, and yours: encrypted sync to your own Google Drive or iCloud, if you turn it on. It goes to your storage, not to a Joru account, because there are no Joru accounts.

Why this changes the price, not just the privacy

Running a language model in the cloud costs money every single time someone presses generate. An app built that way has little choice but to pass the bill on, which is why the category is full of credits, tokens, generation caps and monthly minimums. The meter is not a business decision layered on top of the product — it is the architecture showing through.

When the model runs on hardware you already own, that cost is zero for everyone involved. There is nothing to meter, so nothing is rationed: you can rebuild the same trip fifteen times in an afternoon and it changes nobody's bill. It is also why Joru can offer a one-time purchase next to the monthly plan, which is close to impossible for a planner paying a provider per itinerary.

What on-device AI cannot do, honestly

A model that fits on a phone is not a frontier model, and pretending otherwise would set you up for a bad trip. Joru is built around that limit rather than against it.

The model is never asked to remember whether a restaurant exists, what it costs or when it opens — that is exactly what language models are worst at. Those facts come from open data before the model is involved, and the arithmetic (budgets, the order of your stops, how you get between them) is computed by the app. The model's job is the part it is genuinely good at: arranging a day and writing it up in a way that reads like a person wrote it.

  • It needs a connection to look anything up. The AI is local; the data is not.
  • Generation takes a little longer than a cloud call on a fast server. On Android it keeps running with the app closed and tells you when it is done.
  • Prices, opening hours and travel times are estimates from open data. Check them before you travel or spend.

How to check any of this yourself

Claims about privacy are worth exactly as much as your ability to verify them, so: the privacy policy names every external service Joru contacts and what each one receives. There is no AI provider on that list, because none is contacted.

The place data comes from OpenStreetMap, the area guides from Wikivoyage and the forecasts from Open-Meteo — all open, all checkable against the app's output.

Plan a trip without sending it anywhere

Free to download, free to plan, and no account to start. The full list of questions covers the rest.

Home