AI configuration
Who runs the models for this organization — your own provider keys, or the platform's. Where it is configured (at Bookbag account, not in Madebook), the two modes, what self hosted involves, and how this differs from the allow-list in Governance.
Madebook holds no provider key and has no AI settings page. Which models can answer for your organization, and whose account pays for them, is configured once in the Bookbag account service — the same place that holds your sign-in, your organizations and your files. Madebook asks it for a model when it needs one; no key is stored here and none reaches your browser.
The same configuration therefore answers in every Bookbag product. One organization, one arrangement.
This page and Providers, models and clients answer two different questions, and confusing them is the most common mistake here.
- This page: which models actually answer, and whose key pays. Configured at Bookbag account.
- The allow-list: which vendors and models an agent here is permitted to use at all. Configured in Madebook, under Governance.
"Anthropic is approved" and "there is an Anthropic key" look alike and are unrelated. Both must agree. A model configured at Bookbag account that the allow-list blocks will not be chosen, and the run says so.
Where it is
On the organization's page at your Bookbag account: AI self hosted, at sso.bookbag.ai/user/organizations/<id>/ai. The organization's page there also holds its members, chat, storage and files.
Madebook used to carry its own copy of this page at /organizations/<id>/ai, in an Organization group of the sidebar. That page is gone. The old address redirects to the organization's page at Bookbag account, and so do the links in Madebook that used to open it:
- add your own key on the AI token meter in the account menu;
- Open the organization at Bookbag account on the notice the Decisions and Architecture Rules pages show when the allowance is used up;
- the AI self hosted link on the Governance page.
The first two open in a new tab. The Governance link still points at the old address and is redirected.
The one decision: who runs the models
This decides whose key every model call is paid with. Neither mode falls back to the other.
| Mode | What it means |
|---|---|
| Self hosted | Your own provider keys and your own models, including your own OpenAI-compatible server. The provider bills you directly. |
| Managed by Bookbag | The platform runs the models and pays for them. Nothing to configure, and no key of yours involved. |
An organization that switched to its own key and then removed it gets an error naming the fix, not somebody else's bill; a managed organization never quietly reaches for a customer's key.
Managed mode cannot be chosen while the platform has no model configured: "Nothing is on offer yet — the platform has no model configured." Until a platform administrator fixes that, self hosted is the only working choice.
Which to pick
- Self hosted if your source code may only go to a vendor you hold the contract with, if you already have a provider account with negotiated rates, or if you want to run a model on your own hardware. For an organization whose whole reason for using Madebook is that it governs where code goes, this is usually the answer.
- Managed if you would rather not hold a key at all.
Either way the allow-list still applies. Managed mode does not bypass governance: an approved-provider list that excludes the platform's provider will refuse the run.
Self hosted
In self-hosted mode the organization's page at Bookbag account has Provider keys, Add a model and Models.
Provider keys
Keys are checked against the provider before they are stored, then encrypted. Only the last four characters are ever shown. Adding a key for a provider replaces the one it already has, and removing a key removes the models bound to it.
Six providers take a key: OpenAI, Anthropic, DeepSeek, xAI (Grok), Google (Gemini) and Azure OpenAI. An Azure OpenAI key also needs the endpoint of your Azure resource, because an Azure deployment has no fixed host. These are the same six vendors the allow-list governs, plus Self-hosted / local for your own server.
What each provider can actually do
Chat is universal. Images and embeddings are not, and the difference matters as soon as something wants more than prose.
| Provider | Chat | Images | Embeddings |
|---|---|---|---|
| OpenAI | yes | yes | yes |
| Google (Gemini) | yes | yes | yes |
| Azure OpenAI | yes | yes, deployment-addressed | yes, deployment-addressed |
| xAI (Grok) | yes | yes | no |
| Anthropic | yes | no | no |
| DeepSeek | yes | no | no |
| Your own OpenAI-compatible server | yes | whatever it implements | whatever it implements |
A no is refused with a sentence naming a provider that can, rather than sent and failed.
Your own server
A vLLM, Ollama, LM Studio or any other server of yours, and any gateway in front of one, works if it answers POST {base URL}/chat/completions in the OpenAI chat-completions shape.
- The server must be reachable from Bookbag, not only from your laptop. The call is made by the account service, from wherever it runs — not by your browser and not by your machine.
localhost, an address on your desk, and anything behind a VPN the platform is not on will all fail however well they work in your terminal. - You type the model identifier rather than browsing for it, because a server of your own may publish no model list.
To use it, approve Self-hosted / local on the allow-list as well, and approve the model by its identifier if you keep an approved-model list. The allow-list ships no catalogued models for self-hosted providers on purpose: nobody but you knows what you called your deployment.
Models
Only active models appear in pickers. The starred default is what a run uses unless it names another, and it must support tools, or nothing that asks for a structured answer can use it.
The identifier is the string that matters. The allow-list matches on it exactly, ignoring case. A model added at Bookbag account whose identifier differs by a character from the one approved under Governance is a model that never runs.
What Madebook records per run is token counts on the run itself: input, output, cache read and cache write. It does not record money. See AI runs.
Managed by Bookbag
There is no key of yours in this arrangement. The platform holds the key, settles the provider bill, and runs its own starred default model. The platform catalog lists what the platform offers organizations; it is reference only, and nothing in it needs a decision from you.
The same catalog is where the model chips on the Governance page come from — the models you can approve without typing an identifier. That is true in both modes: the catalog says what exists, the organization's AI page at Bookbag account says what answers, and the allow-list says what is permitted.
What each mode means for the bill
| Self hosted | Managed by Bookbag | |
|---|---|---|
| Whose provider account is charged | Yours, directly by the provider | The platform's |
| What you paste | A key per provider | Nothing |
| Which models are available | The ones you added | The platform's active models |
| What Madebook charges on top | Nothing | Nothing |
| Counted against the token allowance | Recorded, but as zero | Yes |
| Can be refused for being over it | Never | Yes, before any provider is called |
This switch is what decides whether anything is metered at all. The allowance caps what the platform pays for, not what you may use. See The token allowance.
Madebook's own plan and subscription are unrelated to this switch — see Plans, Stripe and revenue.
Who can change it
An owner or an organization admin, at Bookbag account. Everyone else in the organization can see what is available there, and is told that only an owner or an admin can change it.
In Madebook, approving a provider, model or client on the allow-list needs the same people: the governance.manage_providers capability.
The platform's keys and catalog are a platform administrator's, set at the account service. Madebook's admin area links straight out to both and has no copy of either page. See Platform AI and the model catalog.
When something will not run
Two different families of refusal, and telling them apart saves time:
Nothing is configured. The account service answers that the organization has no usable model, and names the fix. That is fixed on the organization's AI page at Bookbag account.
Something is configured but not permitted. Madebook's allow-list answers:
{model} is not on {organization}'s approved model list.
{organization} has not approved {provider} as an AI provider.
That is fixed on Providers, models and clients. A run is never quietly downgraded to placeholder output for either.
If the AI page at Bookbag account shows "Keys cannot be stored yet", the account service has no encryption key configured. There is deliberately no plaintext fallback, and it is for whoever operates the installation to fix.
Related
- Providers, models and clients — the allow-list, and what happens when it is broken
- The token allowance
- Governance overview
- AI runs — what each invocation recorded
- Platform AI and the model catalog — the platform administrator's side