Shipping record.

1.0.1-sync

2026-08-07 · Apache-2.0 · crates.io and npm · current

A rename and a new package. The Rust crate is now gubernaut-core, the JavaScript controller @gubernaut/core is published for the first time, and the ElizaOS plugin moved to 1.0.1. No controller code changed: the compiled WebAssembly is byte-identical across the rename, so every measured figure on this site still describes the binary that ships today.

What changed in 1.0.1-sync?

• The Rust crate was renamed. gcc-core became gubernaut-core. The old name was unsearchable: typing "gcc" into a developer search returns the GNU Compiler Collection. Because crates.io cannot rename a crate, the old name became a forwarding address rather than being abandoned, and it still publishes, still installs and re-exports the new crate. An existing build keeps working with no change.

• A JavaScript controller shipped. @gubernaut/core is the same controller compiled to WebAssembly and bound for JavaScript, in-process, with no proxy hop and no dependencies. It runs where a local proxy process cannot, in a serverless function, an edge worker or a browser. It decides, it does not intercept. Acting on a REGROUND posture is the caller's job, which is the one thing the proxy does that this does not.

• The documented entry point changed name. It is now gubernaut-proxy. This is a documentation change and not a packaging one: both console scripts have shipped since 1.0.0 and both still work, so no existing command breaks. The gcc_proxy import package and the x-gcc-posture header are unchanged.

• A version-drift gate was added on both sides. The site's register now carries a per-package version and fails its own build if a bump lands in one field and not another, and install commands in prose are unpinned so they cannot go stale.

What do I install today?

Five packages are current, and the versions below are pinned because this table is the version record. Everywhere else the site publishes the unpinned command, which stays correct as these versions move.

gubernaut-sdk

The proxy. The front door, and the only package that governs by itself.

gubernaut-core

The controller as a Rust library, and the source of the wasm build.

@gubernaut/core

The same controller, in-process for JavaScript. No proxy, no dependencies, runs on the edge.

@gubernaut/plugin-gcc

The ElizaOS plugin, for agents built on that runtime.

gcc-core

Deprecation shim. Re-exports gubernaut-core so existing builds keep working.

gubernaut-sdk 1.0.1

2026-08-03 · Apache-2.0 · PyPI only

Documentation only. No behaviour changed and no controller constant moved. The published quickstart did not run, in three separate ways, and each of them failed either silently or with an error that did not name its cause. All three were found by executing the snippet against the released 1.0.0 wheel in a clean virtual environment rather than by reading it.

What did 1.0.1 fix?

• The documented port was wrong. launch_proxy(upstream=...) binds an ephemeral port, so a reader who then pointed a client at the documented port got a refused connection. Pass the port explicitly, or read the proxy's own base URL back.

• The module-level base URL needs a trailing slash. Without one the client builds a malformed path and the proxy correctly returns 404. Setting it on the client object works either way, and that is the form now shown everywhere.

• Reading the posture off a plain completion call raised an error, because that call returns a parsed object carrying no headers. This was the step whose whole purpose is proving the governor sits in the request path.

Every worked integration in the repository was already correct. Only the copy-paste path was broken, which is the path a new reader takes first. Version 1.0.0 remains published and is not withdrawn: its defects were in its documentation rather than its behaviour, so a reader who wires the proxy correctly gets the same governed request path from either release. npm and crates.io were unaffected by this release and stayed at 1.0.0 until the 1.0.1-sync release above.

1.0.0

2026-07-29 · Apache-2.0 · first public release

The first public release. Gubernaut 1.0.0 published to three registries simultaneously and the source repository went public, which together make the controller installable and inspectable by anyone.

What is in 1.0.0?

• The full deterministic controller: the Python proxy engine, the Rust core, and the ElizaOS plugin.

• A wasm build of the deciding core that runs in edge runtimes, callable over an allocation-free FFI shim.

• Adapters and worked demos for the OpenAI SDK, LangChain, LlamaIndex, AutoGen and ElizaOS.

• Apache-2.0 licence files across all three artifacts, and the concept DOI embedded in package metadata.

Which gates did it pass?

Five engineering gates ran against the release, and each one asserts something a reader can check in the published receipts rather than a summary of how it went.

Token-free boundary

324/324 constructed telemetry-matched payload pairs (plain vs injection) committed byte-identical x-gcc-* postures across DEFAULT/INHIBIT/REGROUND; the meta level rejected every non-numeric input at the type boundary (5/5).

Framework adoption

5/5 frameworks (OpenAI SDK, LangChain, LlamaIndex, Microsoft AutoGen, ElizaOS). All five adopt in one line, hard-stop a loop, and fail closed on a dead proxy, installed from the wheel/tgz only.

Concurrency isolation

240 concurrent mixed hostile/benign requests with 0 posture cross-contamination and 0 dropped requests; upstream hit exactly 120/120 (the non-hard-stop count).

Fail-closed behaviour

0 fail-open leaks. Deny-by-default route policy, malformed body fails closed, strict boolean parse, typed header-carrying proxy errors, Node fetch timeout. Neither SDK ever falls back to a real upstream.

Rust parity

The compiled Rust core reproduces the Python controller bit-exactly. 10,000-tick soak bit-exact (0 divergence) with flat memory in workerd, a Node worker, and Node main.

What was added after publication?

Four things were added to the repository after 1.0.0 shipped, and none of them changes a line of the published packages. The release is tagged v1.0.0 against the tree as published, so checking that tag out reproduces the artifacts on the registries. The repository was restructured into per-language packages without altering their contents. A reproduction guide was published with 4 levels, the first three of which need no API key and cost nothing. The raw engineering receipts were published unedited, including the fail-safe round that found 4 fail-open leaks in Gubernaut's own code before the hardened round recorded 0.

Every published version is byte-for-byte what it was on release day, and none is withdrawn. Publishing a tag and publishing a package are different acts, and only the second one can change what you install. A defect in a released version is corrected by shipping the next one, never by rewriting a published artifact.

• The reproduction levels
• The engineering receipts

What are the disclosed limits?

One sensor limit ships with this release and is worth knowing before you deploy it. The local v0 lexicon IGL under-reads calmly-worded, non-lexicon hostility (5/5 missed-INHIBIT on that corpus). This is a sensor-recall limit, not a control-boundary breach. False-sever on benign was 0/30 and the repetition/loop veto caught 10/10 calm loops.

The control boundary held in every adversarial test, and what under-reads is the appraisal layer feeding it. A more accurate affect sensor is the next research step rather than a patch to the controller.

Where did the 1.0.0 binary come from?

The controller code in 1.0.0 is unchanged from the previous internal build and the wasm binary is byte-identical to it. This release added the licence files, the DOI, and the version string, and the Python artifact was rebuilt once immediately before publication to correct the adoption one-liner and add repository metadata.

client = OpenAI(base_url="http://localhost:8000/v1")

The attribute is base_url. The pre-v1 openai.api_base is ignored silently by current SDKs, which is a failure mode worth naming because nothing errors when you get it wrong.

How do I verify what I installed?

Compare the artifact against the published checksums, and re-run the test suites against the installed package rather than the source tree. The repository ships the golden traces the Rust core is checked against, so parity between the compiled core and the Python reference is something you can reproduce rather than take on trust.

• Source and checksums
• The paper, DOI 10.5281/zenodo.21303518
• The install guide

Last reviewed 2026-08-07