Settings

Start with one model provider on a running instance. Add connections when an outcome needs them. Model and tool changes save automatically. Nothing here locks you to a single vendor stack.

Choose any workers Doso can call

Models are the workers that interpret goals, prepare context, produce answers, and check results. Use any OpenAI-compatible provider and any model you prefer. A provider connection determines which workers Doso is allowed to call; you can swap providers later without rewriting workflows.

• Open Settings → Models and choose Add provider.
• Enter the provider API key and a model name. Keep the suggested base URL unless you use a compatible custom endpoint.
• Leave Extract, Resolve, Chat, and Skeptic on Priority chain.
• When the provider card shows that its key is configured, start a chat and give Doso a concrete outcome.

Priority chain uses the first configured provider that is available and can fall through to another configured provider after a transient failure. One provider is enough for a first run.

Authorize OpenRouter without copying a key

• Add OpenRouter under Models.
• Choose Connect on the OpenRouter card.
• Approve access in the OpenRouter window.
• Return to Doso and confirm that the card shows a configured key.

This grants Doso permission to use OpenRouter workers without a copied API key. You can still paste a key into the API key field if you prefer to manage that credential directly.

Assign workers to each part of the job

Keep every role on Priority chain when one worker handles your work well. Pin a role when a different worker is better suited to that part of the outcome:

• Chat turns your goal and available context into the answer you use. Choose the worker you prefer for reasoning, tone, and response quality.
• Extract prepares reusable context from documents and messages. Choose a fast, consistent worker when you ingest often.
• Resolve decides when names refer to the same thing so context stays coherent. Keep it with Extract unless you see matching errors.
• Skeptic independently checks grounded answers before you rely on them. Use a different provider when you want a genuinely separate review.

To use a larger model for conversation and a smaller model for ingestion, add both providers, set Chat to the larger model's provider, and set Extract and Resolve to the smaller model's provider.

Grant access to the capabilities Doso may use

Credentials and enable switches make a capability available to Doso. They determine which sources and connected services Doso can reach, so configure only the access your outcomes require.

• Firecrawl permits live web retrieval. Add its API key and enable it when an outcome needs current pages beyond your library.
• X search permits retrieval of live posts from X and uses your configured xAI provider key. Leave it off when X is not an approved source for the work.
• Connections authorize Composio accounts and paired desktop runtimes. Enable only the discovered capabilities an outcome needs.

Connect hosted services or a host CLI

Open Settings → Connections to keep account authorization separate from tool behavior. Use your own Composio account for thousands of third-party services, add your own integrations, or pair a desktop runtime for host CLIs. A connection shows where it runs, which account it can use, its health, and each discovered capability. Read capabilities can be enabled directly; writing, sending, deleting, and local-file capabilities still require invocation approval.

• Choose Composio for managed hosted tools through your own account. Doso accepts a project API key for user-scoped native sessions or a ck_ consumer key for Composio Connect MCP. Either key is kept in its encrypted settings store.
• Choose Host CLI for a CLI that must stay on a paired computer. Authenticate that CLI on the host first; tokens remain in its own credential store.
• Create a short-lived pairing code under Desktop runtimes, run the displayed doso-runtime command on that computer, then assign the runtime to the connection.
• Review discovered capabilities and enable only the ones Doso should offer to chats and workflows.

Give consent for consequential actions during work

Capability access does not approve every use of that capability. When a chat or workflow reaches a consequential action, such as sending, publishing, purchasing, deleting, or changing a shared system, Doso pauses for your decision. Choose once for that request, always for future requests within the same boundary, or never to block the action. See Workflows for how consent fits into execution.

Run one instance

Local compose and hosted deploys are the same three boxes: web, API, and Postgres. Sign in even for a single account. On Desktop, choose Settings → Storage → Connect to server and enter http://127.0.0.1:3000 or your hosted https:// origin. The graphs remain yours; hosting is a placement choice.

Version the library in Git

The Git vault is independent of the API database. Keep the repo on the instance, serve it over Git, or point origin at a remote URL. This gives Doso a durable source of context without making any single representation of that knowledge the goal.

Manage credentials and API access

Credentials define which providers, tools, and API clients Doso can connect to. This controls capability access; consent for a specific consequential action is requested separately during the work. Remove or rotate access when Doso should no longer use that connection.

• A provider card shows whether a key is configured and may show a short hint. Doso does not reveal the saved key.
• Paste a new key to replace a saved provider, Firecrawl, connection provider, or Doso API key. Revoke the old credential with its provider when it should no longer work.
• If Doso asks for a Session API key, paste it under Security. Reload or close the page to forget it.