Skip to main content
Naïve is runtime-agnostic. An agent profile’s tools work wherever the agent runs — governance is at the tool-call boundary, not in the runtime, so self-hosting does not give up spend caps, approvals, audit, or revoke.

Bring your own runtime (the lead path)

The lowest-friction adoption: keep your existing agent (any framework or your own loop) and just inject the agent profile’s governed tools.
A refund still hits the Naïve gateway — capped, approval-routed above threshold, audited, instantly revocable.

Naïve-hosted (optional)

runtime.pool() is the legacy orchestration runtime — the same runtime runtime.hermes() names on the newer team surface. Everything in this section keeps working. A team declared on runtime.durable() is the current path, and a team that names no runtime is durable; see Choosing a runtime for declaring a team of hermes agents, or one hermes team with durable specialists in it, from the team surface rather than through startSystem.
This surface is deprecated, not removed. A config that declares runtime.pool(), agent-level runtime: "<pool>" strings, or systems: keeps compiling and keeps applying indefinitely — naive up prints one deprecation line naming what it found, and new configs author defineProject with teams: on runtime.hermes() for this hosted lane, which is what naive init scaffolds and the only one an apply places today. runtime.durable() is the path forward and is refused on api.usenaive.ai (runtime_not_configuredis it on this deployment?). The full path over is the legacy orchestration migration guide.
Declare a runtime.pool in naive.config.ts, then start agents on managed containers:
Pools declared under runtime in naive.config.ts (and registered by naive up) are validated on start() — an unknown pool name returns a clear error listing the declared pools.

Per-pool sizing

Give a pool a size (or autoscale: { min, max }) to keep containers pre-warmed so claims are instant:
naive up warms each pool to size / autoscale.min on the shared cluster and a reconciler keeps it at target (refilling containers as they’re claimed, up to autoscale.max); re-running naive up confirms an already-warm pool, and naive down drains it. Omit sizing for a lazy pool (a container is created on the first claim). Each pool draws only from its own warm set — pools never steal each other’s containers. Inside a hosted agent, use @usenaive-sdk/runtime — credentials are injected at boot (never on the agent’s filesystem):
Hosted runtime is enabled per deployment. When it is configured (the orchestration cluster is set), start() claims an isolated agent container for the agent profile — sealed to a per-agent profile scoped key, never your company key — and dispatches the run; startSystem({ system }) is a standing team — it provisions the system’s root + member profiles once (reused on later calls, not re-spawned) under the root’s shared budget, then dispatches the run. When it is not enabled, start() returns a clear error directing you to the BYO-runtime path. Either way, governance is identical: every action the agent takes flows back through the gateway under the agent profile’s policy.
The runtime module wraps the existing managed compute orchestration behind a stable interface, so it stays swappable.

Billing

A claimed hosted-runtime container is duration-metered in credits (runtime_usage): 1.7 credits/vCPU-hour + 0.18 credits/GB-hour, so a default 1 vCPU / 2 GB agent costs ≈ 2.06 credits/hour (~0.10/hrat0.10/hr at 0.05/credit) while its container is up — busy or idle. revoke() releases the slot immediately and stops the meter. Bring-your-own-runtime incurs no runtime_usage (you pay only for the API primitives the agent calls). The shared warm pool that keeps start-up fast is platform overhead and is never billed to you. See Credits.