octet 0.10.3
A reliability release: a Pi extension can no longer end a session or block your tools. Publication and asset availability must be confirmed on the version-pinned release page; the source version alone does not establish publication. npm publication is separate.
Fixed#
- A context projection that the provider cannot represent no longer fails
request preparation. The request that reached the hook is restored — it has
already passed identity, loadout and host-authority checks — and the run
continues, reporting one notice per session and extension that names the real
validator reason. Previously a large Pi fleet could lose the whole session:
provider context preparation refused: invalid canonical provider context. - A read-only context observation no longer fails when session history contains
an assistant message produced by a different model or protocol. The opaque
reasoning continuation cannot be represented there, and the refusal propagated
into Pi's tool-call guard, which failed closed and blocked every tool call with
unsupported_feature context opaque reasoning continuation: signature producer must match the assistant. Observation now keeps the visible reasoning text and omits only the unrepresentable signature; provider replay and projection stay strict, so continuation state is never altered. --model <provider>/<model>resolves when that provider exposes the model, and an unavailable model no longer claims a resume is in flight.
Known limitations#
@gotgenes/pi-permission-systemin--printmode still stalls a tool call for about 30 seconds before the host request timeout ends it; the run then exits 0. Root cause is identified (a synchronoustools/snapshotwait that headless mode never answers) and the fix is scheduled next.- The published
octet-codemodebundle still ships only its launcher shim, so it cannot start on a machine without a built runner. - Cold startup with a full 23-package Pi mirror can exceed 10 seconds.
Compatibility#
Pi extension API 0.4 bundles are pinned to this host: run
octet extension update <name> for each bundle after updating, since a 0.10.2
bundle is rejected by a 0.10.3 host.