Capabilities¶
Capabilities enable features such as conversations, tools and file uploads. A capability works only when it is on in two places: in the organisation's ceiling and on the key. How capabilities relate to keys and policy is explained in Keys, capabilities and policy.
The table gives each capability's name in the API, its switch in the console, what it adds and which other capability it requires. A capability with a requirement works only when that one is on as well, in both places.
| Capability | In the console | What it adds | Requires |
|---|---|---|---|
threads |
Store and continue conversations | conversations that outlive one request (Continue a conversation) | |
compaction |
Summarise older messages instead of sending them | summarise a long conversation before it goes to the model (Conversations) | threads |
runs |
Background runs on a thread | run a turn in the background and retrieve its result later (Run a turn in the background) | threads |
schedules |
Fire a turn at a time you set yourself | run a request, an evaluation or a workflow at a set time (Schedules through the API) | runs |
workflows |
Run stored processes of agents, prompts and tools step by step in the background | write a process down as a graph of steps and run it (Workflows through the API, Workflows in the console) | runs, threads |
tasks |
Let a turn start an agent in the background and read its result when it is done | let a tool, an agent or a workflow run in the background while the conversation goes on (Run a tool in the background) | runs, threads |
tooling |
Call tools and MCP servers | let the model call your endpoints, an MCP server, your databases through SQL connectors, a mailbox through a mail connector, a built-in tool, a subagent or your own functions (Tools through the API), and offer many tools through the tool router | |
computer |
Give a turn an isolated computer to run commands in, with files copied in and exported as artifacts | let a turn run code on a computer of its own (Computers through the API), and run your organisation's scripts | tooling |
files |
Upload and attach files | upload bytes for a turn to read (Files and artifacts through the API) | |
artifacts |
Store artefacts the model produced | keep and download what a tool produced | files |
skills |
Register and use skills | packaged instructions you offer the model (Skills through the API) | |
prompts |
Manage prompts with versions | stored, versioned instruction templates (Prompts through the API) | |
agents |
Store agents a call names by name | store model settings and instructions as a versioned agent (Agents through the API) | |
evaluations |
Measure an agent against a stored suite | test agents with reusable scenarios and checks (Evaluations through the API), and read an agent's live check pass rates (Live checks through the API) | agents |
knowledge |
Index and search knowledge sources | your own documents, searchable from inside a turn (Knowledge through the API) | |
memory |
Memory per user | facts that persist across calls (Memory through the API) | knowledge |
datastores |
Keep custom datastores: JSON records with a key, an optional schema and references between them | keep JSON records of your own that an agent reads and writes (Datastores) | |
pseudonymisation |
Replace personal data before the model sees it | replace personal data before the model sees it (Hide personal data from the model) | |
trust_envelope |
Tell the model which text is data: Core's preamble and <untrusted> around everything that cannot be vouched for. Off: the model reads all of it as plain text | tell the model which of the text it reads is data (Tools through the API) | |
subjects |
Hand a person a token narrowed to their own data, and erase one person | issue tokens for a person and inspect or erase their data (Build for people) | |
assist |
Have a piece of configuration written from a description, such as a JSON Schema | have a piece of configuration written from a description, such as a JSON Schema or the schema of a knowledge graph | |
improvements |
Read the organisation’s improvement analyses and act on the changes they propose | read the proposals of improvement analyses, decide on them and apply them (Improvements through the API) | |
product_events |
Deliver your product’s own events to the audit trail | append the events of a product built on Core to its organisation's audit trail (Deliver your product’s own events) | |
management |
Administer this organisation, its keys and the organisations below it | administer your organisation and child organisations through the API (Manage organisations through the API) |
Routes that require a disabled capability return 404. Check GET
/key for the current settings, and ask
your administrator to enable any capability you need.
Where you switch a capability on¶
- An organisation's ceiling: Permitted capabilities on Settings. The administrator of the organisation above sets it, and your operator where there is none above. Core checks the ceiling at the moment it is set; how that works for organisations below one another is on the same page.
- A key: Capabilities on the key's own page. The organisation's own administrator does that, within the ceiling.