SEAOTTER Hobby: 2.83s to 0.16s after we doubled CPU

The pod is faster now. We measured it.

Same loop. Same gVisor sandbox. Same per-agent shape in us-central1. We raised the request from 0.5 CPU to 1 CPU (burst 2). The integer loop that took 2.83 seconds on a starved pod now takes 0.16 seconds. That is about 1.5× a laptop, not 25×.

After the bump · 1 CPU request · same gVisor pod

Python loop now

0.17 s

was 2.83 s

Vs laptop

1.5×

was 25×

Vs starved pod

17×

faster on the same loop

Loops per second

6.1

was 0.35

SEAOTTER is the managed control plane for Hermes Agent. Paid is $99 per agent / month on this shape. 7-day trial, no credit card, one agent.

2.83s is the 2026-08-20 run on the 0.5 CPU pod, with cron and chat also fighting for the core. 0.16s is the mean of three runs on 2026-08-21 after the bump (0.159s, 0.170s, 0.165s). Laptop mean the same morning: 0.11s. Checksum matched on every run. nproc on the pod is 2, which is the new 2000m limit. sandbox_verified is still runtimeClassName=gvisor.

gVisor did not go away. We added CPU because the sandbox has to stay.

0.16 seconds. That is the bump.

Python loop after 1 CPU (seconds, lower is faster)

Same loop, now ~1.5× a laptop0.17s

2.83s at 0.5 CPU became 0.17s at 1 CPU. Still gVisor. About 1.5× a Mac, not 25×.

LaptopBare metal

0.11 s

Hobby at 1 CPUAfter the bump

0.17 s

Hobby at 0.5 CPUBefore · measured

2.83 s

Python loops per second on Hobby (higher is faster)

Throughput on the pod17×

0.35 loops/s at 0.5 CPU. 6.1 loops/s at 1 CPU. Same sandbox. About seventeen times the work per second.

sum(i * i for i in range(3_000_000))

0.5 CPU

0.35 /s

1 CPU now

6.06 /s

Read the 1 CPU bar next to the laptop bar. They almost match. The 2.83s bar is the before. We did not try to beat a Mac. We stopped starving a sandboxed core.

A standing Hermes agent lives in local Python: skill loaders, JSON, the interpreter under the gateway. At 0.5 CPU that work crawled. At 1 CPU it does about 17× the loops per second.

Hobby CPU: 0.5 → 1. The pod is much faster.

Guaranteed CPU for the loop2×

Same gVisor pod. Same per-agent shape. Twice the request floor, twice the burst. Local Python is no longer scheduled at half a core.

CPU request (guaranteed)

Before

0.5 CPU

AfterLive Hobby now

1 CPU

CPU limit (burst)

Before

1 CPU

AfterHeadroom for overlap

2 CPU

1 CPU request and 2 CPU burst is why the loop went from 2.83s to 0.16s. nproc is 2. RAM was never the bottleneck.

Burst went to 2 CPU. Memory went 3 Gi → 4 Gi with the catalog. The starved pod was using 0.7 Gi of 3 Gi. RAM was never the speed fix.

Why we bought CPU, not RAM

Memory used

23%

0.7 Gi of 3 Gi

CPU request floor

Starved

0.5 CPU guaranteed · loop bound

What 0.5 CPU felt like

We did not re-time hermes doctor after the bump. Doctor talks to the network. The loop does not. Here is the local CLI on the starved pod, so the before is not a mystery:

What 0.5 CPU felt like (seconds)

hermes insightsLight read

5.30 s

hermes logsExec path on a starved core

18.8 s

hermes prompt-sizeLocal Python + skill inventory

21.8 s

hermes doctorConnectivity checks + npm audits

43.8 s

Model calls are a different clock. A 2–21 second Nous round-trip does not shrink because the pod has another core. Huge threads do not either. Local Python does. That is the work that is fast now.

The public shape is 1 agent · 1 CPU (2 burst) · 4 Gi RAM · 8 Gi disk. Extra always-on agents are +$99 each after convert. Public numbers: pricing.

Why we still run gVisor

Hobby is multi-tenant. Each agent gets its own Kubernetes namespace (agent-{id}), NetworkPolicy, and PSA restricted. Inside that namespace the product still runs untrusted work: a terminal, skills, cron, sometimes a browser.

If those syscalls hit the host kernel, one tenant becomes every tenant’s incident. New agents run under GKE Sandbox (gVisor). runtimeClassName: gvisor. Provisioning fails closed on sandbox_verified if the Ready pod is not sandboxed.

Isolation stack (required, not optional)

1. 01

   Your agent

   Hermes, skills, terminal, cron. Untrusted code on purpose.

2. 02

   gVisor (runsc)

   Userspace kernel. Syscalls stop here instead of on the node.

3. 03

   GKE node

   Shared Autopilot host. Must not see another tenant’s process.

gVisor is a userspace kernel. The workload talks to runsc, not to the node. Hermes terminal.backend stays local. We put a kernel boundary under that model.

That is why 0.16s is not 0.11s. The sandbox costs something. Half a core on top of the sandbox, plus contention, cost 2.83s. A full core with burst to two costs 0.16s. We buy CPU so the sandbox can keep up. We do not sell an unsandboxed fast lane.

gVisor is not a hypervisor. Firecracker-class isolation is a later track. It is not a substitute for namespaces or write-only secrets. Sandbox plus 0.5 CPU is a slow pod. Sandbox plus 1 CPU is ~1.5× a laptop on this loop.

What the numbers are

Laptop 0.11s — three runs on 2026-08-21: 0.114, 0.110, 0.110. Mean 0.111s.

Hobby 2.83s — measured 2026-08-20 on the 0.5 CPU request / 1 CPU limit pod, gVisor, us-central1, sum(i * i for i in range(3_000_000)), with other agent work on the box.

Hobby 0.16s — measured 2026-08-21 on the 1 CPU request / 2 CPU limit pod, still gVisor: 0.159, 0.170, 0.165. Mean 0.165s. Same checksum. Same expression. ~1.5× the laptop, ~17× the starved pod.

The 25× gap was the before picture. The leftover 1.5× is gVisor plus cloud, not a starved quota.

No free tier. Trial is 7 days, no credit card, one agent. Paid is $99 per agent / month. Custom is book a call. Region today: us-central1 only.

A full core, still sandboxed

Purpose-built for Hermes. Isolated per agent. gVisor on every new pod. Hobby now has the CPU to match.

• What is SEAOTTER? · Provisioning lifecycle
• Honest tradeoffs: Self-host vs managed Hermes
• Isolation for retainers: one isolated Hermes per client