9Router v0.5.55 Adds SSO, Provider Routing, and Security Fixes

9Router v0.5.55 is one of those updates that touches almost every layer of a self-hosted AI gateway. It adds enterprise authentication, new providers, smarter coding-tool routing, better vision payload handling, and several security fixes in the same release. That is useful, but it also means I would not treat this as a blind npm update. Existing users should check authentication and provider settings, then run a small routing and API verification pass after restarting the service. I run 9Router on my local machine at 127.0.0.1:20128 to connect my daily LLM stack — DeepSeek API for direct inference, CommandCode agents for coding workflows, and Antigravity AI for experimental routes. Each provider gets its own combo in 9Router with automatic failover, so I barely notice when one endpoint is slow. Here's what changed for me with v0.5.55.

Info

This article follows the npm release version for v0.5.55 and uses the release changelog for the feature summary. The configuration examples are deliberately conservative: replace placeholder values with the settings supported by your deployment.

What's New in v0.5.55

SAML 2.0 SSO joins OIDC

The headline authentication change is native SAML 2.0 SSO alongside the existing OIDC path. That gives teams using an enterprise identity provider another way to connect 9Router to their login system without putting a separate authentication proxy in front of it. If you run 9Router for yourself, this may not change your day-to-day workflow. For a team deployment, it matters because SAML is still the integration most corporate identity platforms expect for older or more tightly managed applications. Before changing authentication settings, I would verify the following:

The identity provider's callback or ACS URL matches the URL configured for this deployment.
The user identifier and email claims map to the account fields 9Router expects.
At least one administrator still has a recovery path if the SSO assertion is rejected.
The deployment is using HTTPS at the edge, especially when login traffic leaves the local machine.

More providers and model options

The release expands the provider layer in several directions:

Alibaba Token Plan support adds another provider option for users already working in that ecosystem.
GLM 5.3 is available as a model choice.
Kimchi supports both API-key and OAuth authentication, which gives users more flexibility when their account supports either method.
Gemini 3.7 Flash and tiered Antigravity variants extend the fast-model selection.
Fish Audio TTS adds a text-to-speech path for workflows that need audio output instead of only text.

The practical effect is less provider-specific wiring in client tools. I can keep one gateway endpoint while changing the provider or model behind it, but I still need to check credentials, model IDs, quotas, and regional availability for each account.

Better routing for coding workflows

OpenCode-Go requests now receive format-aware routing. That matters when a client expects a particular request or response shape rather than a generic chat completion. The router can make a more informed decision instead of treating every coding request as the same payload. The release also adds Claude quota caching and request deduplication. In a busy workflow, those changes should reduce repeated quota checks and duplicate work. They are operational improvements, not a promise of a specific latency or cost reduction, so I would measure them against my own traffic rather than assume a benchmark result.

Vision-adapter detection for more payloads

The vision adapter now detects image payloads from Hermes, Ollama, and the Vercel AI SDK. This is important when a client sends an image in a provider-neutral format and the selected model expects a different multimodal representation. I would verify this with a small, non-sensitive image after upgrading. The goal is to confirm that the gateway recognizes the image and forwards the request to a vision-capable model. Do not use production documents for the first test.

Security hardening

The changelog also includes fixes around trusted-peer handling, SSRF protection, login behavior, and request-data redaction. These are meaningful defensive changes, but they do not remove the need for safe deployment practices. I would still bind the gateway deliberately, restrict access at the network boundary, avoid exposing administrative endpoints directly to the internet, and review logs for accidental secrets. A security fix improves the default posture; it does not replace an access-control review.

Getting Started: Install 9Router for Beginners

You do not need an existing 9Router installation for this walkthrough. I am using npm for the global install and npx as the no-global-install alternative.

Prerequisites

You need:

Node.js 18 or newer
npm installed and available on your PATH
A terminal with permission to install a global npm package, or permission to run npx
A local port available for the gateway, such as 20128

Check the runtime before installing:

node --version
npm --version

Install the latest published package globally, or use the one-off npx form:

npm install -g 9router
# Alternative: npx 9router@latest --help

Use the global command for a persistent local installation. Use npx when you want to test the package without adding it to the global npm bin directory.

📸 [SCREENSHOT NEEDED] Successful npm install -g 9router output — save it as D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\install-success.png.

Run the help command and check that the CLI responds instead of returning a shell or npm error:

9router --help

You should see the command's usage text and its available commands or options. Save this output if you are troubleshooting a service installation.

📸 [SCREENSHOT NEEDED] 9router --help output showing the installed CLI responding — save it as D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\help-output.png.

Use the configuration command shown by your installed help output to initialize the first config file. If your package exposes a first-run prompt, complete it there and keep the generated file outside your source repository.For a deployment that accepts JSON configuration, the shape below illustrates the values I would verify. Treat it as a representative example, not a drop-in replacement for every provider:

{
  "host": "127.0.0.1",
  "port": 20128,
  "providers": {
    "example": {
      "baseUrl": "https://provider.example/v1",
      "apiKey": "replace-with-a-secret"
    }
  }
}

Do not commit a real API key. If the initializer uses environment variables or another configuration format, keep the same principles: bind the service intentionally, store secrets outside Git, and verify the provider URL and model ID.

📸 [SCREENSHOT NEEDED] First-run configuration prompt or sanitized generated config — save it as D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\first-configuration.png. Remove all API keys before sharing it.

Start the gateway using the command or service definition shown by your installation. Then query the local models endpoint:

curl -sS http://127.0.0.1:20128/v1/models

A healthy response should be an HTTP success response containing the models or provider routes available to your configuration. If the command cannot connect, check the process status, configured port, and local firewall before debugging provider credentials.

📸 [SCREENSHOT NEEDED] Successful local /v1/models API smoke test — save it as D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\api-smoke-test.png.

How to Update

If you already run 9Router globally, update the package first:

npm install -g 9router@latest
9router --help

If your deployment runs as a user service, restart it after the package update:

systemctl --user restart 9router
systemctl --user status 9router --no-pager

Then verify the gateway endpoint:

curl -sS http://127.0.0.1:20128/v1/models

If your service uses a different unit name, container, process manager, host, or port, use that deployment's equivalent restart and health-check commands. The important part is to verify the process that actually serves your clients, not only the npm package version.

Upgrade checklist

Confirm the installed package version and keep the previous configuration backed up.
Recheck OIDC or SAML settings before enabling a new authentication path.
Verify provider credentials, model IDs, and any Alibaba, Kimchi, Gemini, Antigravity, or Fish Audio settings you use.
Test an OpenCode-Go request and confirm it receives the expected format-aware route.
Test a harmless image request with Hermes, Ollama, or the Vercel AI SDK if your workflow uses vision.
Review logs for login errors, blocked requests, or unexpected redaction behavior.
Restart the user service and repeat the local API smoke test.

Warning

Do not paste SSO metadata, API keys, bearer tokens, or production images into screenshots or public issue reports. Sanitize every capture before uploading it to Cloudinary.

Personal Experience Notes

I run 9Router on 127.0.0.1:20128 and route my daily LLM stack through it. Here is what my active provider setup looks like right now:

Provider	Status	Cost	Active Since
DeepSeek API	✅ Active	Pay-as-you-go ($1.70 remaining)	May 2026
CommandCode (×3 accounts)	✅ Active	$4.08/month	April 2026
Antigravity AI (Google AI Spark Pro)	✅ Free tier	Free	May 2026 (expires May 2027)
Cloudinary	✅ Free tier	Free	—
OpenCode Go	❌ Stopped	$5 total (1 month)	Jul 2026 — switched to CommandCode

I keep a full log of every provider and subscription at my expense tracker — it feeds directly into what I write about here.

The breadth of v0.5.55 is welcome, but I am rolling it out in stages. The provider additions are easy to appreciate because they show up directly in a model list. The authentication and security changes deserve a slower check because a small mismatch in an identity-provider setting can lock out the people who need to fix it. My own upgrade order: install the package, confirm 9router --help, back up the current configuration, restart the service, query /v1/models, and only then test SSO, coding-tool routing, and vision payloads. That sequence separates a broken installation from a provider or authentication problem. I would also avoid claiming that every new model or provider is available in every region or account tier. The release can add an integration, while access still depends on the provider's credentials, plan, and endpoint rules.

Screenshot Recap

This draft needs the following captures before publication:

#	Screenshot	Location in Article	Path
1	`install-success.png`	After Install step	`D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\install-success.png`
2	`help-output.png`	After Confirm command step	`D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\help-output.png`
3	`first-configuration.png`	After Create config step	`D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\first-configuration.png`
4	`api-smoke-test.png`	After Smoke test step	`D:\Screenshots\labs\9router-v0.5.55-provider-routing-update\api-smoke-test.png`

Cross-Link

For the broader week-in-review context, continue with the official 9Router changelog.