Choosing a provider
Newer results are in the latest version of these docs: Self-hosting, AI models, Choosing a local model.
AI runs on a provider you connect. Add one on the AI settings page, or under your account as a personal connection you grant to chosen workspaces. In short: a hosted API (Anthropic, OpenAI, OpenRouter) is the least setup and the strongest models, while a local model (Ollama, an OpenAI-compatible server, or Local AI over the edge bridge) keeps data on your own hardware.
The providers Cobblr ships
- Anthropic (Claude). Your Anthropic API key. Strong on the chat and vision assists.
- OpenAI. Your OpenAI API key.
- OpenRouter (one key, any model). One key that reaches many models behind a single gateway, and you name the model.
- Ollama (local). A model you run yourself with Ollama, reached at its URL.
- OpenAI-compatible (LM Studio, vLLM, and similar). Any server that speaks the OpenAI v1 API. You give the base URL, and the key and model are optional depending on the server.
- Local AI (via edge bridge). Reaches a model on your own device through a live edge channel, for when Cobblr cannot reach the URL directly (the model runs on your laptop or LAN, not on the server). Set it up under personal connections.
Provider details: OpenRouter's trade, tokens, and the edge-bridge option
OpenRouter requests transit OpenRouter's infrastructure, which is the trade for the convenience, and it is stated on the key field rather than hidden.
For Ollama, an optional bearer token covers a remote or proxied endpoint. On both the Ollama and OpenAI-compatible connections, when the URL is on your own machine or LAN, a How Cobblr reaches it option can route the call through your edge bridge instead of directly.
The Local AI connection carries no credential and stays inert until an edge agent connects.
Hosted or local
The choice comes down to a few tradeoffs:
- Quality and effort. A hosted API is the least setup and generally the strongest models. A local model is free to run and keeps data on your hardware, but you provide the machine and pick a model good enough for the job.
- Where the data goes. A hosted provider receives the content each call needs (a photo, a description). A local model, direct or over the edge bridge, keeps that on your own network.
- One key or many. A single provider is simplest. OpenRouter is one key across many models if you want to switch models without managing several keys, at the cost of routing through their gateway.
Per-capability models and budgets
- Pick a model per job. A provider covers several jobs (chat, image classification, text extraction, and so on), and you can pick which model handles each, so a cheap model does the routine work and a stronger one handles the harder calls.
- Set a monthly budget. A provider can carry a ceiling on what it is allowed to spend.
Pinning against a shared connection, and removed pins
Pinning a job needs a provider the workspace owns. When its AI comes only from a shared connection, there is nothing to pin to, and the page says so inline rather than opening an edit that cannot save. A job whose pinned provider is later removed falls back to automatic, with a clear-pin action when you open it.
Which providers let Cobb act
- Tool calling is the requirement. Reading your records and proposing changes needs a provider that supports it. Anthropic, OpenAI, OpenRouter, and any tool-capable OpenAI-compatible or local server all do, and Cobb runs its full loop with them.
- Without tool calling, a provider still chats, but Cobb drops to a simpler one-move-at-a-time mode.
- A backend that runs tools itself (some local backends are agents that only hand back text): the Ollama, OpenAI-compatible, and Local-AI connections carry a How this AI runs tools choice. Leave it on the standard setting for an ordinary model, or set it to "runs tools itself" to give that backend read-only access to the workspace, so Cobb can read your data through it. That path is read-only. To let Cobb make changes, connect a tool-calling provider.
Personal connections
Hold a key on your own account instead of putting it on the workspace, and grant it to the workspaces you choose. The workspace gets the capability and never sees the credential, and the grant comes back whenever you take it back. This is how a shared workspace runs AI on one member's key without handing that key around. See Personal connections.
Turning it off
- Per workspace: owners and admins can turn AI off with the Use AI in this workspace switch on Configuration → AI, though a member's own personal connection still works there.
- Whole install: on a self-hosted install, the operator can disable all built-in AI with one switch regardless of what keys are set.
- That hard floor, and the privacy detail of what each call sends, are on the AI settings page.