Releases

Shipping record.

Versions are permanent. A defect is corrected by shipping a new version, never by rewriting a published one, so anything you install by version number will behave the way it behaved the day it was published.

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?

  • gcc-core was renamed to 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.
  • @gubernaut/core is new: 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 command-line entry point 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.

Install

Pinned here because this table is the version record. Everywhere else the site publishes the unpinned command, which stays correct as these versions move.

PyPIgubernaut-sdkpip install gubernaut-sdk==1.0.1
crates.iogubernaut-corecargo add gubernaut-core@1.0.1
npm@gubernaut/corenpm install @gubernaut/core@1.0.1
npm@gubernaut/plugin-gccnpm install @gubernaut/plugin-gcc@1.0.1
crates.iogcc-corecargo add gcc-core@1.0.1

gcc-core is the superseded name of gubernaut-core. It is listed for readers who already depend on it, not as an install path for new work.

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?

  • 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 attribute 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 it

  • 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.

Gates it passed

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. The wasm build runs bit-exactly against the reference over a 10,000-tick soak with flat memory.

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 taggedv1.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.

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 distinction matters: 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, not a patch to the controller.

Provenance

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.

the corrected one-liner
client = OpenAI(base_url="http://localhost:8000/v1")

The attribute is base_url. The pre-v1openai.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.

Last reviewed 2026-08-07