Local model deployment

You can point Mystilink at a compatible model service running on your own machine. Local models must be installed, downloaded, and run by you; Mystilink stores the connection settings and will not install models or prepare a GPU environment for you.

First separate this machine, the LAN, and the cloud

localhost or 127.0.0.1 means the computer running Mystilink. A LAN address means a different machine, so processing is not confined to the same device. Some local-model tools also offer cloud models; using such a tool by name does not mean inference actually happens on your machine.

To keep inference local, confirm all three at once: the chosen model runs on this machine, the address points at the local service, and cloud fallback is disabled or removed. Online features such as accounts and licensing keep their own network requirements.

Ollama

Install and start the service following the official Ollama documentation, and download a model that suits your machine and supports the tool capabilities you need. Use the model ID the service actually reports; do not copy someone else's model tag.

Create a custom Provider in Mystilink, set the "API protocol family" to openai-compatible, and use http://localhost:11434/v1 as the default local address example. If the address or port was changed, fill in your actual values. Ollama's local compatibility endpoint uses the placeholder key ollama; that is not your Mystilink account password and it is not access control.

Test the connection, add the exact model ID, save, and set it as the primary model. After a successful connection, still verify one conversation and a real flow that needs tools.

LM Studio

Load a model suited to your device in LM Studio and start the local server; get the address and model identifier from the official compatibility documentation.

If the server port is 1234, an example compatibility prefix is http://localhost:1234/v1; the port is not a fixed requirement. Fill in a key according to the server's current authentication settings, and do not assume every local service is unauthenticated.

Add it through the custom Provider flow in Mystilink, enter the actual model ID, then test a conversation. Having only downloaded the model without starting the server leaves the desktop app unable to connect.

Checks before saving

Check	Why
Service running and address reachable	A model tool's window being open does not mean its API server is enabled
Model loaded and ID correct	File name, display name, and API ID can differ
Required tool-calling support	Successful plain chat does not mean the Agent's tool flow will complete
Context large enough for the task	History, charts, and tool output consume context
Primary model and fallback configured correctly	Avoid silently falling back to a cloud service when local inference fails

Performance and troubleshooting

Local behavior depends on model size, quantization, context, and available hardware; there is no fixed memory number that applies to every model. Pick a model the deployment tool says can run, and when long conversations slow down, narrow the scope or start a separate conversation.

• Connection refused: check whether the server started, whether the port is right, and whether localhost points at the machine you expect.
• Model not found: copy the model ID from the service's current list and confirm it is downloaded or loaded.
• Chat works but tools fail: check tool-calling support for the model and endpoint instead of repeatedly swapping keys.
• Fails after changing computers: the old machine's model and server do not move with the Mystilink workspace.

Do not expose an unauthenticated service to the public internet just to troubleshoot. For LAN deployment, configure authentication and access scope in the service you manage, and confirm the transport path.

Related guides: Models and vendors, Compatible providers, Connection problems, Privacy.