HexaEight LLM Router r4 — Bridge 1.9.24 + macOS startup crash fix

Rebuilt on HexaEight.Bridge 1.9.24, plus a macOS startup crash fix.

Why this release exists

r2 and earlier carried Bridge 1.9.14. Its integrity rows were captured for Linux and Windows,
but never for a self-contained macOS build — so on Apple Silicon the platform did not recognise the
library chain and returned a decoy, which surfaces as:

HexaEight identity: <your-identity>
License verification: Failed
License verification failed. Check env-file + hexaeight.mac.

The confusing part, and the reason this took a while to find: hexaeight-activate verify-env passes
on the same machine, in the same folder, with the same env-file and hexaeight.mac. The tool runs
on the shared .NET runtime with current libraries; the router shipped self-contained with an older
Bridge. Same identity, different bytes being attested.

If you saw a router licence failure on macOS while the agent and the activation tool both worked,
this is that bug.

Linux and Windows were unaffected — 1.9.14's rows exist there, which is why the same identity
licenced correctly on those platforms.

Downloads

See HASHES.md for SHA-256 per file, and verify before running.

platform	file
Windows x64	hexaeight-router-win-x64.exe
Linux x64	hexaeight-router-linux-x64
macOS Apple Silicon	hexaeight-router-osx-arm64

Or let the tool do it:

dotnet tool install --global HexaEight.Activate
hexaeight-activate install-router     # downloads, verifies, and checks your upstream config

Run it from the identity folder

Every HexaEight command reads env-file and hexaeight.mac from the current working directory.
Starting the router from anywhere else gives the same License verification: Failed, for an
entirely different reason. If you share one identity across folders, hardlink both files — a
copy of hexaeight.mac is a second machine binding and will not verify, and a copied env-file
goes stale the moment a licence is renewed.

Bedrock

Unchanged from r2: translate: "bedrock" converts an Anthropic-shape request to the Bedrock Converse
API inside the router, and one upstream entry serves every Bedrock model — the url is the runtime
root and the model id is appended per request.

The credential is read from ~/.bedrock_api_key rather than the environment, because HBIA's
credential firewall strips variables whose names contain KEY from a supervised child. Exported by
hand such a variable works; started by the agent it arrives empty, which looks like a wrong key
rather than a removed one.

Before you deploy

The router bootstraps with an allow-all policy and says so:

[policy] WARNING: this router allows EVERY sender to use EVERY model.
[policy] Anyone who can reach this port can spend your upstream credit.

Set requireIdentifiedCaller: true in router.yaml before exposing the port, and narrow the policy.

Also fixed: the router died printing its own address

After licence verification passed and the router was already listening on 5100, it resolved the
machine's hostname to print a LAN: line. On a Mac whose hostname is not in /etc/hosts that
throws:

System.Net.Dns.GetHostAddresses(...)
SocketException: nodename nor servname provided, or not known

and the process exited. The router was fully up and serving at the moment it was killed by a
cosmetic line. It now reports LAN: (this machine's hostname does not resolve - localhost above still works) and carries on.

Linux and Windows resolve their own hostname, which is why this only ever appeared on macOS.

HexaEight LLM Router r3 — Bridge 1.9.24 (fixes macOS licence verification)

Rebuilt on HexaEight.Bridge 1.9.24, the version the agent already ships.

Why this release exists

r2 and earlier carried Bridge 1.9.14. Its integrity rows were captured for Linux and Windows,
but never for a self-contained macOS build — so on Apple Silicon the platform did not recognise the
library chain and returned a decoy, which surfaces as:

HexaEight identity: <your-identity>
License verification: Failed
License verification failed. Check env-file + hexaeight.mac.

The confusing part, and the reason this took a while to find: hexaeight-activate verify-env passes
on the same machine, in the same folder, with the same env-file and hexaeight.mac. The tool runs
on the shared .NET runtime with current libraries; the router shipped self-contained with an older
Bridge. Same identity, different bytes being attested.

If you saw a router licence failure on macOS while the agent and the activation tool both worked,
this is that bug.

Linux and Windows were unaffected — 1.9.14's rows exist there, which is why the same identity
licenced correctly on those platforms.

Downloads

See HASHES.md for SHA-256 per file, and verify before running.

platform	file
Windows x64	hexaeight-router-win-x64.exe
Linux x64	hexaeight-router-linux-x64
macOS Apple Silicon	hexaeight-router-osx-arm64

Or let the tool do it:

dotnet tool install --global HexaEight.Activate
hexaeight-activate install-router     # downloads, verifies, and checks your upstream config

Run it from the identity folder

Every HexaEight command reads env-file and hexaeight.mac from the current working directory.
Starting the router from anywhere else gives the same License verification: Failed, for an
entirely different reason. If you share one identity across folders, hardlink both files — a
copy of hexaeight.mac is a second machine binding and will not verify, and a copied env-file
goes stale the moment a licence is renewed.

Bedrock

Unchanged from r2: translate: "bedrock" converts an Anthropic-shape request to the Bedrock Converse
API inside the router, and one upstream entry serves every Bedrock model — the url is the runtime
root and the model id is appended per request.

The credential is read from ~/.bedrock_api_key rather than the environment, because HBIA's
credential firewall strips variables whose names contain KEY from a supervised child. Exported by
hand such a variable works; started by the agent it arrives empty, which looks like a wrong key
rather than a removed one.

Before you deploy

The router bootstraps with an allow-all policy and says so:

[policy] WARNING: this router allows EVERY sender to use EVERY model.
[policy] Anyone who can reach this port can spend your upstream credit.

Set requireIdentifiedCaller: true in router.yaml before exposing the port, and narrow the policy.

HexaEight LLM Router r2 — Bedrock upstreams

Adds Bedrock as a first-class upstream, translated inside the router.

Built self-contained and single-file for all three published platforms; nothing needs to be
installed to run one.

What changed since r1

Bedrock upstreams. translate: "bedrock" converts an Anthropic-shape request to the Bedrock
Converse API in the router, so an agent speaking /v1/messages reaches a Bedrock model without
knowing anything about it. One upstream entry serves every Bedrock model: the url is the runtime
root and the model id is appended per request.

r1 shipped before this work and cannot route to Bedrock at all — a config naming it loads, and then
fails per request in a way that reads as a provider error rather than a missing feature. If you are
running r1 with a Bedrock upstream, this is the fix.

Reading the key from a file. Bedrock's credential is read from ~/.bedrock_api_key rather than
the environment, because HBIA's credential firewall strips variables whose names contain KEY from
a supervised child. Exported by hand such a variable works; started by the agent it arrives empty,
which looks like a wrong key rather than a removed one.

Downloads

See HASHES.md for SHA-256 per file, and verify before running.

platform	file
Windows x64	hexaeight-router-win-x64.exe
Linux x64	hexaeight-router-linux-x64
macOS Apple Silicon	hexaeight-router-osx-arm64

Or let the tool do it:

dotnet tool install --global HexaEight.Activate
hexaeight-activate install-router     # downloads, verifies, and checks your upstream config

install-router now also names every ${VAR} your upstreams.yaml expects and says which ones the
current shell would not supply. Those are substituted at config-load time, so an unset one does not
stop the router starting — it fails later, on the first request routed to that upstream, as the
provider's own authentication error.

Before you deploy

requireIdentifiedCaller decides whether the router can meter per caller or only per agent. An
agent may decline to name its callers, and the session is then attributed to the agent rather than a
person — right for a router someone else runs, wrong for one you are accountable for. Set it in
router.yaml before deploying; changing it afterwards changes what your existing records mean.

Not gated on approved builds

The download is verified against a hash shipped inside HexaEight.Activate. The second question the
agent asks — whether a peer will accept traffic from this build — does not apply to the router yet.
Deliberate, and stated here so nobody assumes a gate is protecting them that is not.

HexaEight Bridge LLM Router r1

First public release of the HexaEight Bridge LLM Router.

The router sits between your agents and your model providers. Agents reach it over DDE — the same
encrypted, identity-proven path they use with each other — and it forwards to whichever upstream you
have configured, with your key never leaving the router.

.NET 8 self-contained, single-file. Nothing to install.

Downloads

platform	file	SHA-256
Windows x64	hexaeight-router-win-x64.exe	9CFBA78EE06F9D7E9F8B579BE635F915A17C5A2A65D73740BD13A41DFD487AE5
Linux x64	hexaeight-router-linux-x64	E63F6A38138263FC21C23492EF59AE826628B4E9CD9A19C0EC67A1F12494C3F1
macOS arm64	hexaeight-router-osx-arm64	DC508A94AA192F45FFBB2D84D00E4D996D9E75B549BE33C7C59558160137ACD8

Upstreams

anthropic, openai, azure, bedrock, openrouter, ollama — configured in router.yaml.
Bring your own key; the router holds it so your agents never do.

Opaque sessions — the setting worth understanding before you deploy

An agent may decline to name its callers, sending :opaque: instead of a user identity. The router
then attributes the session to the relaying agent rather than to an individual.

This is a feature, not a gap. Whoever runs a router may be a third party, and an agent's user
list is its own business — a customer roster should not have to be disclosed to a model provider as
the price of routing through it. Nothing is weakened: the relaying agent is a real,
cryptographically-proven identity that was already authorised, and it is the party the router has a
relationship with and bills.

The trade is explicit and the agent's to make: choose opacity, and the router can meter and gate per
agent rather than per caller. Per-caller accounting stays inside the agent, where the callers
are actually known.

A router may refuse opacity, and a self-hosted one usually should:

requireIdentifiedCaller: true

The two deployments want opposite things. A third-party router has no business knowing an agent's
customer list, so permitting opacity is the right default there. An internal router — run by a
department accountable for what its models are used for — needs to see the source, and an agent that
could opt out of being seen would defeat the gating that router exists to apply.

It is the router operator's switch, not the calling agent's, and it lives in the config file next
to the upstreams so it can be read, reviewed and version-controlled. It rejects rather than
quietly downgrading: an operator who asked for per-caller gating must never end up with per-agent
gating and no indication that is what they got.

Install

dotnet tool install --global HexaEight.Activate
hexaeight-activate install-router