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.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_configured — is it on this
deployment?).
The full path over is
the legacy orchestration migration guide.runtime.pool in naive.config.ts, then start agents on managed containers:
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 asize (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.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.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.