Connect a custom AI model: endpoints, keys and fallback
Configure an OpenAI-compatible model in Mono, test the connection, understand fallback and separate chat from tool support.
A custom model connection lets an app send requests to a server you choose. The model may run on your computer or at a hosted provider; entering your own endpoint does not mean the phone runs the model. Start with a short, harmless text request before testing documents or workflows.
Mono by Reunified lets you bring your own model, and replies from a model you run yourself cost nothing in Mono. Mono is currently on a waitlist. This guide shows the settings and gives you a checklist to use once you have access. Even when a server says it’s compatible, test it with your exact app and model.
1. Collect the right connection details
You need the API base URL, the exact model ID and, if required, an API key. Follow the setup instructions from whoever runs the server. A website address, a model download page or an MCP server URL is not a model API endpoint.
Mono sends text requests to the Chat Completions path under the address you enter, so enter the API base, not the full path. For example, if your provider documents https://models.example.com/v1/chat/completions, enter https://models.example.com/v1. This is a made-up example, not a working service.
Check what else the model supports. Answering text doesn’t mean it supports images, tools, streaming or every request option.
2. Configure one model role
Open Settings, then Integrations, and turn on Text Model under Custom Endpoints. Enter the endpoint URL, API key and model ID in their fields. Keep keys out of chat messages and screenshots. A local server without sign-in may not need a key, but that doesn’t make it safe to open to the internet.
Start with the text model. Mono has separate settings for the text, code and support models, so changing one doesn’t change the others. Note which one you changed, so you know where to start if something goes wrong later.
With a custom text model, some features, such as tools and skills, may not work the same way as with Mono’s built-in models. Test plain conversation first. If a workflow needs skills, a good text answer doesn’t prove that the workflow will work.
3. Decide what fallback should do
Each custom model has a “Use default model if unreachable” switch, and it’s on by default. Don’t assume every feature reacts to a failed server in the same way. Test it: stop your server and see what happens in the feature you use.
If your requests must only go to your own server, for privacy or cost reasons, turn this switch off and test what happens when your server fails. Check where requests actually go; a setting on screen isn’t enough. Changing the text model also leaves the other models and any connected tools to review.
Read the AI privacy checklist and usage-cost guide before sending sensitive material or comparing bills.
4. Run a small connection test
Ask: “Return the three words red, green, blue on separate lines.” Check that the reply arrives, that your server’s logs (if it keeps them) show the model you picked, and that the provider’s usage page matches your test.
Then test one feature you actually need, such as a longer conversation. Change one thing at a time. Note the app version, server version, model ID and date; a result for one combination doesn’t mean every model will work.
For a server on your computer, also test from your phone’s real network. localhost on the phone means the phone itself. Use a connection method with sign-in that your server supports, instead of opening an unprotected service to the internet.
5. Diagnose the first failing layer
| Symptom | First check |
|---|---|
| Connection timeout | Server running, device can reach it, network rules |
| Unauthorized response | Correct key, account and sign-in requirements |
| Not found error | Base URL, and whether the /chat/completions path was added twice |
| Unknown model | Exact model ID available on that server |
| Text works, workflow fails | Tools or other features the workflow needs |
Remove secrets from any logs you share. Signing in on the provider’s website doesn’t prove your API key works, and a working text test doesn’t mean the code model is set up.
6. Keep a reversible configuration
Write down your previous settings, without the secrets. After changing servers, repeat the small test and check costs both in the app and at the provider. Check the other model settings before you call a setup “local” or “private”.
Join the Mono waitlist for release updates. For connecting external services instead of replacing a model, use the separate MCP connection guide.
