Settings reference
AI features and which model each one uses
Pick a model per feature, decide what the AI may do on its own, and who pays for each call.
A model per feature
In the portal: Admin, Settings, AI
Each AI feature has its own model setting. Once a provider is set up under AI providers, the fields become pickers that list what that provider offers. A model is written provider/model, for example openai/gpt-5 or ollama/qwen3-coder:30b. A name without a provider is a Claude model.
You do not have to fill them all in. Model for reading a repository is the one the others fall back to; the rest are under Advanced for when you want a cheaper or a stronger model for one job.
AI inside published apps
Apps never hold a key. An app asks the platform, the platform makes the call and counts what it costs, per app. Model published apps get is what an app gets when it does not ask for one.
Under Advanced you can limit:
- which models an app may ask for;
- how many tokens one app may spend per day (0 is no limit);
- how long one answer may be, and how long the platform waits for it.
An owner can also choose that their app runs on each user's own key instead of the company's. Then every colleague connects their key under Profile; see personal keys.
What the AI may do
In the portal: Admin, Settings, What the AI may do
Every feature has its own switch. Nothing the AI writes reaches a running app without the owner's approval, except a fix for a deploy that never started. The ceilings under Advanced (attempts per day, rounds per session, quiet time between attempts) keep a stuck app from turning into a large bill.
| Switch | What it does | Paid by |
|---|---|---|
| The chat in the portal | Answers questions and acts for the signed-in colleague, with the same tools a coding agent gets over MCP. | The platform key |
| The catalog’s opening card | A question or tip for the colleague reading it, once a week (or once a day). | The platform key |
| The coding agent | Changes an app’s code from the portal; every session ends as a pull request the owner approves. Needs the GitHub App. | Each colleague’s own key, or nobody on a model server of your own |
| Diagnose an app that crashed | Reads the logs and the code of an app that crashes or returns server errors, and proposes a fix the owner approves. | The platform key |
| Fix a deploy that never starts | The same for an app that never came up. There is no live version to protect, so the fix goes in directly. | The platform key |
| Resolve merge conflicts for the owner | When an owner approves a change that conflicts, cyantula resolves the conflict instead of asking them about git. | The platform key |
“The platform key” means the provider of the model that feature uses. A feature whose model has no provider set up is simply not offered.