Xinity Runtime v0.23.0

Xinity Runtime v0.23.0 is out. This release has a theme, and it is predictability. Whether a model will fit, how many requests it can serve, why a deployment is blocked, who touched what: v0.23.0 answers these questions before you commit hardware to them.

Here is what changed.

Capacity estimation: numbers instead of trial and error

Until now, sizing a model deployment on your own hardware involved a certain amount of educated guessing. Deploy, watch it under load, adjust.

v0.23.0 moves that work up front. The infoserver now estimates concurrent capacity and per-request throughput for any model on any node, before you deploy. Behind that sit several new data points in the model catalog:

• A GPU class table with bandwidth and compute figures for each accelerator

• KV cache cost per token, recorded per model

• Weight precision per catalog entry

• Active weight figures for Mixture-of-Experts models, so sparse models are sized by what actually runs, not by their total parameter count

The daemon uses the same estimates at runtime: the run-model plan now reports estimated concurrency, and vLLM concurrency is capped at the estimated sweet spot instead of being left to find its limits in production.

For teams running inference on fixed hardware budgets, this is the difference between provisioning on data and provisioning on hope.

Reasoning models, properly supported

Reasoning models are becoming standard in open-weight releases, and the gateway now treats them as first-class citizens. It forwards the reasoning_effort parameter to the engine and returns reasoning output on responses. A fix in the same release makes sure every reasoning item is completed when a response holds several.

If you are building agents or evaluation pipelines against your Xinity deployment, reasoning traces now flow through the gateway the way you would expect from any hosted API. The difference: they never leave your infrastructure.

A Model Hub that explains itself

The model picker got a full redesign, and most of it is about reducing noise and surfacing what matters:

• Variant grouping. Model variants now sit behind one card with a variant picker, instead of cluttering the list. A variant group is judged by its most deployable variant, so one incompatible quantization no longer drags down the whole family.

• Engine filters. Filter models by engine, with model types the engine cannot serve marked as such. The dashboard shows the engine per model instead of a driver preference.

• License terms up front. Every model in the current catalog format carries a license, the dashboard shows the terms, and deploys are gated on restricted ones. Compliance checks happen where the deploy decision is made, not in a spreadsheet afterwards.

• Freshness signals. Recently added models are flagged and release dates are shown. Creation and registration dates are now required on every catalog entry.

• Unlisted models. A model can be unlisted without becoming unusable, kept out of the picker behind a toggle.

• A direct line to us. The selector now links out to the model request form. If a model you need is missing, tell us there.

When something cannot deploy, you now know why

This is a small line in the changelog and a large improvement in daily use. When a model cannot deploy, the infoserver now reports which constraint blocks it, and the dashboard shows it. No more blaming capacity for every undeployable model: if the actual blocker is an engine version, a license restriction, or a format requirement, that is what you see.

Placement is also smarter about engine versions. Instead of a simple version floor, models are now gated on an engine version range, matched with semver semantics. The dashboard explains which engine release blocks a model, and an engine version range can carry a note about what it means for that model.

Audit events, ready for your SIEM

Sovereignty is not only about where inference runs. It is also about being able to prove what happened on your platform.

v0.23.0 mirrors dashboard audit events to Loki for SIEM ingestion, with the bundled monitoring stack pointing an audit forwarder at Loki and charting audit events out of the box. Audit records now capture the transport channel and the real caller behind each event, and buffered events are flushed cleanly through shutdown. License features are listed in the instance license view.

If your security team asks how AI platform activity feeds into the existing SIEM, the answer is now: natively.

A sturdier model catalog underneath

Less visible, but foundational: the model catalog moved to a current format that is served as a snapshot with a digest, with a per-engine model format and the v1 format kept available for legacy setups. Required fields like license, maxContextLength, and registration dates make catalog entries complete by construction. When a catalog moves ahead of a build, that build keeps the entries it understands instead of breaking.

The release also ships a set of fixes across the CLI, daemon, and dashboard, including a timeout on the vLLM health check, corrected H100 and H200 TFLOPS figures, and corrected Qwen3.6 sizing.

Get it

One command, on your own hardware:

curl -fsSL "https://github.com/xinity-ai/xinity-ai/releases/download/v0.23.0/install.sh" | bash

curl -fsSL "https://github.com/xinity-ai/xinity-ai/releases/download/v0.23.0/install.sh" | bash

curl -fsSL "https://github.com/xinity-ai/xinity-ai/releases/download/v0.23.0/install.sh" | bash

Full changelog: github.com/xinity-ai/xinity-ai/releases/tag/v0.23.0

Your models, your hardware, your data. Sovereign by architecture, not by contract.

Drafted by AI, edited by the Xinity team.