The slow-binding test used a 250 ms compute budget, which is below the instrumented worker startup cost seen intermittently in the four-worker Windows coverage job. That startup activity could exhaust the budget before the program settled into the awaited binding, making the timing assertion depend on runner load. Use a one-second compute budget and a two-second binding delay. The awaited wall time still exceeds the busy-time allowance by a clear factor, so the test continues to prove that binding wait time is not charged while leaving enough headroom for worker initialization under coverage.
code-runtime/ — code-execution capability family
The code-execution capability seam (see capability seams): an abstract runtime interface for executing one model-written program against host-provided async bindings, capturing what it printed and returned. The consumer is the tool registry's Code Mode (tools: { mode: code } — the run_code tool and the generated TypeScript SDK); design in the Code Mode RFC. Product packages.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Abstract code-execution seam (interface + vocabulary) | ctx.codeRuntime |
code-runtime-worker/ |
Worker-thread backend: fresh worker per run, TypeScript via host-side type-strip (annotations advisory, never type-checked), port-bridged bindings, budget/heap containment | registers ctx.codeRuntime |
The interface lives at code-runtime/code-runtime/; the shipped backend at code-runtime/code-runtime-worker/. Backends differ by execution substrate (worker thread, process, container) and by source language — both readonly descriptors on the service — and register ctx.codeRuntime without touching the interface or its consumer; that split is what makes a hardened backend a drop-in later.