Skip to main content

Models and vendors

This page covers BYOK (bring your own vendor API key). If you would rather sign in and skip managing keys, read Newton LLM first. Newton and BYOK can coexist.

With BYOK you supply APIs from vendors such as OpenAI, Anthropic, Google Gemini, DeepSeek, Moonshot, or MiniMax, the key is stored on your device, and requests go from your machine directly to the vendor without passing through the Newton platform.

How this differs from metaphysics theory​

ConceptRole
Metaphysics theory (BaZi, tarot, …)Determines the charting, card-draw, or casting path
ModelUnderstands the question, plans, and writes the interpretation

The two are configured separately in the UI.

Adding a model (Settings → Models)​

Three steps are recommended:

  1. Choose a Provider and credentials

    • Enter the API key literally, or the name of a local environment variable for Mystilink to read.
    • Optionally override the Base URL.
    • Use Test connection to confirm it works (a border and message show success or failure).
  2. Choose a model

    • Enter the model ID; you can use the suggestion list or a custom ID.
  3. Add a display name

    • After saving it appears in the "Current model configuration" list.

Primary model and fallback​

  • Set a primary model as the default routing target.
  • With automatic fallback when unavailable enabled, a failed request may try another configured candidate.

Security notes​

  • API keys are not uploaded to Mystilink servers.
  • Requests go from your device to the chosen vendor; usage is shown in the "Usage" section of settings.

Step-by-step configuration guides​

Pick the guide that matches where your API comes from:

SituationGuide
Getting a key from an official platform such as OpenAI, Anthropic, or GeminiOfficial platform API keys
Connecting an OpenAI-compatible third party such as OpenRouter or SiliconFlowOpenAI-compatible providers
Running a local model with Ollama, LM Studio, and similarLocal model deployment

Troubleshooting​

Connection failures, invalid keys, and wrong model IDs are covered in Model connection problems.

Further reading​

Confirming things after a connection is set up​

First verify a conversation with a short message that contains no private records, then verify the tool task you actually need. A passing connection test does not mean every model capability matches. Before adding a second service, check its rates and privacy terms; once fallback is enabled, the backup service can also receive context. If processing must stay local, do not configure a cloud fallback.

The key, the Base URL, and the model ID must belong to the same real service. After setting the primary model, review the active configuration again to avoid still using an old service that remained selected.