Managed capabilities
A managed capability is one Novo operates end to end. You turn it on with a single field; Novo provisions, secures, meters, and reaps the underlying infrastructure. There is nothing for you to host, register, or rotate secrets for.
Together with default subagent delegation, managed capabilities are the product surface: developers get built-in delegation plus browser, workspace, media, document, MCP, GitHub, approval, durable stream, and signed callback primitives that can be embedded into their own products.
This is the counterpart to customer-owned integrations like remote workspaces and tool servers, where you run and secure the backend yourself. Managed capabilities trade that control for zero operational surface.
The family
| Capability | Enable with | What the agent gets | Billing |
|---|---|---|---|
| Managed browser | capabilities: { browser: true } | A real cloud browser it can navigate, act on, read, and screenshot. | Per session-minute; browser action-selection tokens bill as normal run inference. |
| Managed workspace | workspace: { type: 'managed' } | A durable filesystem, shell, and optional preview ports. | Per compute / transfer / storage. |
| Managed document processing | workspace: { type: 'managed' } (default) or workspace: { type: 'managed', documents: false } to opt out | Office/PDF tools over real workspace files: read, create, edit, render, export to PDF, fill PDF forms, and inspect OfficeCLI help. | Processor creation, compute, and transfer, reported as managed_document_processor. |
| Managed media generation | capabilities: { media: true }, or a per-modality subset like capabilities: { media: { image: true, speech: true } } | Novo-hosted image, video, speech, music, and sound-effect artifacts with optional export handlers. | Per generated artifact unit; see pricing. |
| Managed media editing | workspace: { type: 'managed', shell: true, mediaEditing: true }; requires Novo media binary provisioning | Image, audio, and video editing over real workspace files using a Novo-provisioned shell toolchain. | Managed-workspace compute. |
Each managed capability follows the same contract below, so enabling another one is a one-field change with no new infrastructure on your side.
How they work
The agent loop always runs in Novo Cloud. Model calls and provider API keys never enter a managed runtime; only the capability's actuation does: a browser command travels to the managed browser, a shell command to the managed workspace, and an Office/PDF job travels to Novo's document processor. Inference stays inside Novo.
This keeps the security boundary identical to the rest of the platform:
- Provider keys never leave Novo. A managed runtime sees actuation, not credentials.
- Trust follows the capability boundary. Browser page text and default-untrusted HTTP/tool-server output are wrapped as external content. First-party workspace files and registered GitHub repositories are treated as customer-controlled context, so keep allowlists, egress policy, and approvals tight when a workflow may ingest outside text.
- Control URLs are bearer secrets. Live-view URLs (browser) and preview URLs (workspace) grant access on possession. Browser live-view URLs are fetched only through authenticated no-store reads; workspace preview URLs are delivered over authenticated channels. Control URLs never appear in model-visible output. Treat them as secrets: do not log or persist them.
Billing model
Managed capabilities are metered per use and debited from the same wallet as inference, with standard Novo-managed runtime pricing. They are not bounded by a run's budgetCents or maxDurationMs. Those bound model inference, while a managed resource (a browser session, workspace, or document processor) is thread-scoped and can outlive any single run, including across approval/input pauses. Each capability's own idle timeout is the real bound. Usage shows up in /v1/usage, /v1/usage/events, and the Billing console.
Lifecycle
A managed resource is thread-scoped and lazy: Novo creates it the first time a run in that thread needs it, keeps it warm across the thread's runs, and reaps it after an idle window. Thread deletion destroys the resource, so treat delete as data destruction. See each capability's page for its specific idle window and retention.