Bring your own model
Add your own model to Nebula — a routing alias to a vendor model, or any OpenAI-compatible endpoint, including one running on your own machine.
You can point Nebula at a model of your own: a vendor model it already knows about, or any OpenAI-compatible endpoint you control — including one running on your own hardware.
What you can add
Add a model in Settings → Workspace brain → Models opens two routes, and they solve different problems.
Pick a vendor model Nebula already knows about and make it selectable in this workspace. This is how a workspace grows its catalog — you're choosing from a list, not supplying an address.
Point Nebula at a URL you control. You supply the address, the model id to send upstream, and any credentials it needs. Use this for a self-hosted model, a provider Nebula doesn't list, or a gateway your team already runs.
Adding a custom endpoint
Open Settings → Workspace brain → Models and choose Add a model, then the Custom endpoint tab.
Give it a Display name — this is what you'll see in the model picker and in the composer chip, so make it something you'll recognise.
Enter the Base URL of your OpenAI-compatible endpoint, and the Model id to send to it. The id is what your endpoint expects, not what Nebula shows you.
Add Auth headers if the endpoint needs them. These are your credentials for your own endpoint, and they're stored for that model rather than shared around the workspace.
Choose whether to restrict it to a device, then who can use it. Save, and it appears in the picker alongside everything else.
Who can see it
Every model you add is either private to you or shared with the workspace.
| Only me | Everyone in this workspace | |
|---|---|---|
| Who can select it | Just you | Any workspace member |
| Shows in the catalog | Only in yours | In everyone's |
| Can be the workspace default | No | Yes |
| Who can delete it | You | You, as its owner |
A private model carries an Only me badge in the table, so it's obvious at a glance which rows the rest of your team can't see.
Pinning a model to one machine
You can restrict a custom model to a single device. When you do, only that machine runs it — a turn from anywhere else fails outright rather than quietly falling back to something else. That's deliberate: silently answering on a different model than the one you pinned is worse than an error.
This is what makes a model on your own computer work. Point the endpoint at an address on your machine — a local Ollama server, say — and lock it to your local device. Nebula routes the call through the helper already running there, so an endpoint that isn't reachable from the internet still answers.
A model reached this way replies all at once rather than word by word. The answer is the same; it just arrives complete instead of streaming in. Everything else about the conversation behaves normally.
A model locked to a local device is always private — that machine is yours, so the model can't be shared with people who can't reach it. Neither a private model nor a device-locked one can be the workspace default, since the default has to work for everyone.
From the command line
The CLI manages the same models, which is handy when the endpoint you're adding is on the machine you're already typing on.
| Command | What it does |
|---|---|
models custom list | List custom models visible in this workspace |
models custom add | Add one — see the flags below |
models custom remove <model-id> | Delete a custom model you own |
models custom add takes --alias <model-id> for a routing alias to a catalog model, or
--base-url <url> with --model-id <id> to point at your own endpoint. Add
--auth <value> for an authorization header, --device <device-id> to lock it to one
machine, and --share to make it visible to the whole workspace. See the
CLI reference.
FAQ
Related
Models and defaults
Choose which model Nebula runs on — switch tiers from the composer, pin one to a thread, curate the workspace catalog, or bring your own endpoint.
Tools and integrations
Connect Slack, Discord, Gmail, GitHub, and 4,000+ tools and integrations to your Nebula workspace so your agents can act on real systems.