Connect an OpenAI-Compatible Provider to a Tauri App (Opt-In)

The problem

Some of your users have a slow computer, or already pay for a cloud provider and would rather use it. Giving them that choice sounds simple until you remember what is at stake: their records may be about to leave the computer, a key has to be stored somewhere, and a lazy default would quietly turn a private app into one that uploads data. The connection has to be deliberate and hard to trigger by accident.

The kit treats a bring-your-own-key cloud provider as a strict opt-in on top of a local-first default. Any provider that speaks the OpenAI Chat Completions API can be used, and the app only talks to it after the user passes two gates on the server. This guide covers how the user connects one, what the server checks and how you extend the data-sharing controls to your own modules. It applies to the Windows-only kit.

Steps

  1. Enter the connection details in Settings > AI

    The user sets a base URL, a model name and the token parameter their provider expects (max_tokens or max_completion_tokens). The server sends requests to <base URL>/chat/completions. Nothing is sent just because these fields are filled in.

  2. Use a public https address

    The base URL must be public https://, optionally with a path, with no credentials and no query string. Local names such as localhost, .local and .lan, and private, loopback or link-local addresses, are refused when saved and again when connecting. Redirects are refused too.

  3. Save the API key

    The key is saved encrypted on the user's computer, sent only to the provider's host and never included in exports. The model name, base URL and key together are all the provider needs to be reachable, and none of them is used until the user passes the gates below.

  4. Pass the two gates

    Cloud use turns on only through one consent dialog, which also turns on the cloudAi network feature. The dialog lists what leaves the computer and what stays, and the user must tick two boxes: that their data goes to that provider under its privacy policy, and that they pay the provider directly.

  5. Let the user choose data categories

    The user decides which kinds of data a cloud provider may see. In the kit the categories are items, shared by default, and notes, not shared by default. The server enforces this: every model call passes a scope, and a call that names a withheld category throws before anything is sent.

  6. Verify the fallbacks

    Change the base URL and confirm cloud goes back to off, because consent is stored against the exact URL. Break the setup on purpose and confirm the assistant falls back to local, never the other way around.

What a withheld category looks like in practice

A tool for a withheld category returns a not-shared placeholder instead of data and never runs. Earlier turns that used withheld data are dropped from the history sent to the cloud, and only the user's own earlier messages are kept. Local Ollama is trusted, so all categories work there.

Each model call also writes an audit row. For cloud calls it records the host and the category names that were shared or withheld, and free-text context is redacted for known key and password patterns.

Adding categories for your own modules

When you add a module whose data a user might want to keep local, add a category for it in the privacy file and mirror the labels in the settings constants. A page or tool with no category mapping is refused while a cloud provider is active, which makes a forgotten mapping fail safe rather than leak.

Pros and cons

Pros

  • Off by default, with two server-side gates, so a cloud call cannot happen by accident.
  • Consent is bound to the exact base URL, so a changed address resets it.
  • Per-category control is enforced on the server rather than trusted to the interface.
  • Any provider that speaks the Chat Completions API works.

Cons

  • The user's data does leave the computer when it is enabled, which undercuts a pure local story for those users.
  • You must keep category maps complete, or tools are refused under cloud.
  • Providers differ in details such as the token parameter, so setup can take trial and error.
  • The user pays the provider directly, so costs are outside your control.

Frequently asked questions

Is cloud use on by default?

No. It is off until the user passes the consent dialog, and it needs the cloudAi network opt-in as well.

What if the cloud setup breaks?

The assistant falls back to local. It never falls back the other way.

Can an imported file switch cloud on?

No. The generic state route and the importer refuse every cloud setting, so consent only comes from the dialog.

Which providers are supported?

Any provider that speaks the OpenAI Chat Completions API, reached on a public https base URL.