AI assist (bring your own key)

AI assist is optional. Where it can reach a cloud provider it is bring-your-own-key, and one surface — asking about a trip — is local-only by design. All of it is built so that a provider can never receive your confirmation codes or traveler names, and so that nothing is ever sent without you seeing it first.

Providers

Under AI providers you can choose between two paths, and there is no wrong one — Voyalier stays fully usable with neither:

• On-device via a local Ollama. Detection runs only on this device, and on-device runs never leave it. If no Ollama is found, a guided setup walks you through it — see On-device setup.
• Cloud, by adding your own OpenAI or Anthropic key. The key is stored in your operating system keychain — never in Voyalier’s files, database, logs, or any request body. It is read only to place it in that request’s authorization header, and the interface only ever shows whether a key is set, never its value. See Adding a cloud key.

On-device setup, step by step

When no Ollama runtime is detected, the On-device AI panel offers a short, three-step wizard rather than sending you to hunt for docs:

1. Install Ollama — a link to download it; it is free and runs locally.
2. Start Ollama — open the app (on macOS it lives in your menu bar and usually starts on its own after installing).
3. Get a model — pick one of the recommended models below.

For each recommended model you have two ways to get it. Copy command copies its ollama pull <tag> command to paste into your terminal, and once Ollama is running, Download pulls the model in-app with a progress indicator (keep the app open — it can take several minutes). The model tag is prefilled but editable, so you can adjust it or Add another model with a tag of your own.

Everything here runs on this device. Detection, downloading, and later use all stay local — always on this device, always your choice.

Adding a cloud key

In the AI providers panel, paste your OpenAI or Anthropic key and choose Validate & save. Voyalier checks the key with the provider before storing it, so a typo or an expired key is caught up front rather than at the moment you send a request. If it validates, the key is saved and verified; if the provider can’t be reached to confirm it, Voyalier tells you it saved the key but couldn’t verify it right now, so you’re never left guessing.

Don’t have a key yet? The How to get a key helper expands into the exact steps and links straight to each provider’s API-keys page. Either way, the key only ever lives in your OS keychain.

Preview before anything is sent

The Preview an AI request panel builds, on your device, the exact request Voyalier would send: the fixed system prompt and the grounded trip details, plus a clear “leaves your device / stays on your device” signal for the chosen provider. It reuses the same redaction as the shared brief, so confirmation codes and traveler names are excluded by construction and could never reach a provider; imported document text is withheld too. The preview also cites what it is grounded in and shows a rough token estimate.

Nothing is transmitted until you choose to send the previewed request.

Running a request, and the log

When you send it, the same redacted request goes to your chosen provider (on-device Ollama, or OpenAI/Anthropic using your keychain key). A fixed system prompt forbids inventing high-stakes facts — entry, visa, health, and safety details are quoted from cited sources, never generated — and every reply carries a non-authoritative disclaimer.

Each successful run is recorded in a per-trip activity log that stores metadata only (provider, model, time) — never the prompt or the reply.

Ask about this trip

Ask about this trip is a conversation about one trip, answered by a local Ollama model on your own machine. Nothing leaves the device.

Local only, and that is deliberate

OpenAI and Anthropic are not offered for chat, even when you have a working key saved. The preview above is the reason. A single request can be shown to you in full and sent only once you agree; a conversation is many sends, and previewing every one of them is unusable. The alternative is a standing “always send” permission — and that is not a promise Voyalier is willing to make quietly. So chat stays on your device, and your cloud keys stay with the one-shot flow that can still show you every byte.

If no local model is found, the panel says so and points you at On-device setup, rather than offering an input box that could not answer you.

What it is given, and what it is refused

Each question is answered from the trip’s own material: your confirmed flights and stays, plus the most relevant of your documents and saved resources, found with the same deterministic search the search box uses. The reply lists what it was grounded in.

Confirmation codes and traveler names are withheld from the model, exactly as they are with cloud assist. The model running on your own hardware does not change that — so it cannot tell you your booking reference, and asking it will get you a plain statement that it does not have one.

Pointer cards on high-stakes questions

Ask about visas or entry, health, safety, or prices and Voyalier puts its own pointer card above the reply, linking to where the real answer lives. The card is added to the reply, never swapped in for it: the model’s answer is still shown, so you can see both what it said and where to go and check it. Every reply carries the same non-authoritative framing as the rest of Voyalier’s AI.

Where a conversation goes, and where it does not

Conversations are saved per trip, encrypted at rest, and can be cleared.

Transcripts are deliberately kept out of search, out of the shareable brief, and out of exports. The search exclusion is the load-bearing one: if an answer were searchable, a later question could retrieve it as grounding, and the model would start citing itself as a source. If an answer is worth keeping, Save to notes copies it into the trip’s notes — where it becomes something you decided to write down, rather than something the model found lying around.

Filling lodging-date gaps on-device

If a booking you imported has lodging dates that the deterministic parser didn’t pick up, Fill gaps with on-device AI can propose them from your own imported text. It is Ollama-only and runs entirely on this device — nothing leaves — and you can Preview what it reads before running it.

Every proposal is a draft, not a save. Suggestions are routed into the same review dialog you use for imported candidates, so nothing changes on the Blueprint until you confirm it. Voyalier drafts dates from your imported text; it never invents prices, visas, health, or safety details.

Customizing the AI instructions

For those who want it, Customize AI instructions lets you view and override the system instructions Voyalier uses, each with a Reset to default:

• Assist & preview instruction — used when you preview or run an AI request.
• Lodging-date draft instruction — used when the on-device AI drafts missing lodging dates.

Two guardrails hold regardless of what you write. The lodging-date draft stays schema-locked to dates — it only ever accepts dates, whatever the instruction says — and every AI reply is still marked not official. Instructions are stored on this device and change only future requests; they never change what leaves your device beyond the instruction text you already see in the preview.