> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bor-os.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

# Providers

BOR is **provider-agnostic**. You bring your own model — or use Bed of Roses credits — and BOR works the same either way. There are five providers, all first-class.

## Provider parity

This is a core principle: **every provider is treated equally.** BOR is never "optimized for one vendor, others get adapters." You pick during onboarding; you can switch any time. The chat loop, tools, surfaces, and bridge all behave identically regardless of which model is behind them.

## The five providers

| Provider                 | id                  | Bring             | Notes                                                          |
| ------------------------ | ------------------- | ----------------- | -------------------------------------------------------------- |
| **Bed of Roses credits** | `bor`               | nothing           | Metered BOR credits — no key of your own.                      |
| **Anthropic**            | `anthropic`         | Anthropic API key | Claude models.                                                 |
| **OpenAI**               | `openai`            | OpenAI API key    | GPT models.                                                    |
| **Google Gemini**        | `gemini`            | Gemini API key    | Gemini models.                                                 |
| **OpenAI-compatible**    | `openai-compatible` | base URL + key    | Any OpenAI-API endpoint: local models, proxies, other vendors. |

## How a provider is wired

Each provider is an adapter under `server/providers/` exporting a common shape:

```js theme={null}
{ id, label, defaultModel, models, signupUrl, needsBaseUrl, stream }
```

* **`stream({ apiKey, model, baseUrl, system, messages, signal })`** — an async generator yielding text chunks. This is the one method the harness calls.
* **`defaultModel` / `models`** — what onboarding offers.
* **`signupUrl`** — where to get a key.
* **`needsBaseUrl`** — whether the provider needs a base URL (OpenAI-compatible does).

Providers are registered in `server/providers/index.js` (`ALL_PROVIDERS`); `publicCatalog()` is what onboarding shows. Shared utilities (`multimodal.js`, `sse-util.js`, `limits.js`) handle image blocks, streaming, and limits across all of them.

## Choosing a model

Onboarding lets you pick a model per provider, and you can change it in config. **Model IDs go stale fast** — new models ship and old ones retire on a months-long cadence. When picking (or when a model 404s), choose a current one from the provider's live docs rather than an old hardcoded id.

> If you're editing the provider adapters in `server/providers/*.js`, fetch the provider's live model docs first — hardcoded ids rot.

## Switching providers

Change the active provider any time:

* Re-run onboarding (`bor onboard`), or
* Ask BOR to switch, or
* Edit `defaultProvider` (and the relevant `providers` entry) in the presence's `config.json`.

Because of [multi-presence](../features/multi-presence.md), you can also run one presence on Anthropic and another on Gemini at the same time.

## Multimodal

All providers go through `server/providers/multimodal.js` for image handling, so attaching a screenshot, generating an image, and the screenshot-feedback used by the [browser](../features/the-browser.md) and [computer-use](../features/computer-use.md) tools work consistently. Vision features (e.g. `locate_screen_element`) require a vision-capable model on your chosen provider.

## Per-provider pages

* [Bed of Roses credits](bed-of-roses-credits.md)
* [Anthropic](anthropic.md)
* [OpenAI](openai.md)
* [Gemini](gemini.md)
* [OpenAI-compatible](openai-compatible.md)