v1.5.0

# 🚀 Added

## 🔐 Header-based API-key authentication

Until now, the Roboflow API key travelled to the inference server as the `api_key` query parameter (API v0) or as a JSON-body field (API v1) — which means it could end up in access logs, proxy logs and browser histories. Starting with this release, the server also accepts the key as a standard `Authorization: Bearer <api_key>` header, and the SDK can send it that way (@PawelPeczek-Roboflow, https://github.com/roboflow/inference/pull/2810).

**How to use it.** The SDK gains a new `api_key_transport` field on `InferenceConfiguration` with three modes:
* `legacy` keeps today's behaviour byte-for-byte — key in the query parameter or body, works against every server version
* `both` keeps the legacy channels untouched and adds the `Authorization: Bearer` header on top — safe against every server version, since older servers simply ignore the header and newer servers read it. 
* `header` sends the key **only** in the header — no key in URLs or request bodies, but it requires a server from release 1.5.0 onward; against an older server your requests arrive keyless and fail auth.

```python
from inference_sdk import InferenceHTTPClient, InferenceConfiguration

client = InferenceHTTPClient(api_url="http://localhost:9001", api_key="<KEY>").configure(
    InferenceConfiguration(api_key_transport="both")
)
```

**What are the defaults** 
Nothing changes on upgrade unless you opt in. The SDK default remains `legacy` (you will see a one-time guidance warning nudging you towards the header), the server accepts header-carried keys by default (`ALLOW_API_KEY_FROM_HEADERS=True`), and Workflows blocks that call remote Roboflow APIs default to `both` (`WORKFLOWS_REMOTE_API_KEY_TRANSPORT`, values `legacy`/`both`/`header`). When several channels carry a key, **the server resolves them in the order:** 
* query parameter 
* `Authorization` header 
*  body field 
*  `API_KEY` env var.

**Why `both` is the right mode for now.** `header`-only is the destination, but flipping straight to it couples your client upgrade to your server upgrade and to every piece of infrastructure in between — some proxies and gateways strip or rewrite `Authorization` headers, and hosted endpoints migrate on their own schedule. `both` gives you the security benefit wherever the header is honoured while remaining compatible with everything else, and it costs nothing: the header carries the same key the legacy channel already delivers. Run `both` for the transition period, and switch to `header` once you have confirmed the whole path speaks it.

**Migration sketch** 
1. Upgrade your servers to 1.5.0. 
2. Switch clients to `api_key_transport="both"` — this is safe immediately, even against servers you have not upgraded yet. 
3. Once every server in the path is ≥ 1.5.0 and you have verified that your proxies pass `Authorization` headers through, switch to `"header"` and enjoy key-free URLs and bodies. 
4. One caveat for self-hosted deployments sitting behind an auth proxy that forwards its own `Authorization: Bearer <JWT>` header (oauth2-proxy, GCP IAP and similar): the server will read that JWT as an API-key candidate ranked above body-carried keys. If that is your topology, set `ALLOW_API_KEY_FROM_HEADERS=False` on the server or stop the proxy from forwarding its token and **raise an issue here, we will try to help.**

## 📦 OFFLINE_MODE in `inference-models`, rebuilt around an explicit registry

`OFFLINE_MODE` in `inference-models` (now at 0.36.0) got a ground-up redesign of how offline model availability is decided (@PawelPeczek-Roboflow, https://github.com/roboflow/inference/pull/2833). Previously, offline serving inferred what was usable by inspecting and validating whatever it found in the model cache — an implicit contract that was hard to reason about and, in edge cases, stricter than intended. The new design makes the contract explicit: an **offline-weights registry** inside `INFERENCE_HOME` records exactly which models and packages were proven to load, and offline serving reads that registry through the same auto-negotiation path used online. What is registered loads; what is not, does not — and the error tells you precisely how to fix it.

**How to use it** 
Warm-up and serving are now two explicit, mutually exclusive phases. On a machine with connectivity, run your models once with `OFFLINE_MODE_WARM_UP=True` — every successful load records the model, its packages and its platform-attested metadata in the registry. Then ship `INFERENCE_HOME` to the air-gapped target and run with `OFFLINE_MODE=True`. Setting both flags at once fails loudly at model load, by design. New `AutoModel` classmethods round out the workflow: `list_offline_models()` shows what the registry will serve, `verify_offline_model()` checks a record against the materialized files (optionally with hash verification), and `purge_offline_model()` removes one cleanly.

**What you gain** 
TensorRT engine caching now works under `OFFLINE_MODE`, so warm restarts on air-gapped Jetson-class devices skip engine recompilation — that is minutes saved per model. Warm loads are much faster across the board, because cache-hit loads no longer re-hash every artifact on disk on every startup. Packages compiled and installed with the `inference-compiler` CLI are now first-class citizens of offline serving. And offline cache trees can be mounted read-only — offline serving treats the cache as immutable input and never writes to it.

**Migration guide** 
The registry is the single source of offline truth, which has one important consequence: a cache that was warmed by "just running the models once online" — without `OFFLINE_MODE_WARM_UP=True` — has no registry records, and offline serving will not use it. Before upgrading an air-gapped fleet, re-warm on a connected machine with the flag set and ship the resulting `INFERENCE_HOME`. 

> [!WARNING]  
> Clients running in `OFFLINE_MODE` are responsible for consistency of data on their volumes. Additionally, since it is not possible to verify access credentials in Roboflow API w/o access to the Internet - security posture of the configuration must be ensured externally from the low-level engine running models.


## 🤖 Qwen VLM v2 workflow block

The unified `qwen_vlm@v2` block brings Qwen-tuned OpenRouter plumbing and reasoning control to Workflows, shipped in a fast-track deployment post `1.4.1` release was aligned with `main` and is released now. (@SkalskiP, https://github.com/roboflow/inference/pull/2825).

## 🎯 Visual prompts for SAM3 Video Tracker

The SAM3 Video Tracker now accepts visual prompts, extending prompt-based tracking beyond text (@leeclemnet, https://github.com/roboflow/inference/pull/2787).

## 🧩 String Template block and SequenceJoin UQL operation

Workflows gain a String Template block for assembling text from step outputs, together with a `SequenceJoin` UQL operation (@JoeWayne, https://github.com/roboflow/inference/pull/2812).

## 📊 Usage rows now record the model variant

Usage-tracking rows can be attributed to the exact platform model variant (e.g. `yolov8-n` instead of just the architecture), resolved once at model load so the inference hot path stays untouched (@SolomonLake, https://github.com/roboflow/inference/pull/2811).

## 🏎️ Models that arrived before their invitations

We were apparently moving so fast this release that the code overtook the platform: three new model families are fully implemented in `inference_models`, while their packages are still making their way through platform registration. Consider this the trailer — **Qwen3.8 27B VL** with its `/infer` adapter (@hansent, https://github.com/roboflow/inference/pull/2801), the **Qwen3.8 vLLM proxy** with a `qwen_vlm` workflow variant for base-only serving (@hansent, https://github.com/roboflow/inference/pull/2802), and **Mage-VL**, a codec-native video VLM (@Erol444, https://github.com/roboflow/inference/pull/2820). The engines are on the tarmac; boarding passes are being printed. Coming soon.

# 🔧 Fixed

- **Legacy RF-DETR preprocessing normalized BGR inputs in the wrong channel order** — numpy (BGR) inputs are now normalized in RGB order, matching training (@probicheaux, https://github.com/roboflow/inference/pull/2828).
- **Triton kernel runtime errors now fall back gracefully** instead of failing the request (@dkosowski87, https://github.com/roboflow/inference/pull/2815).
- **Tensor painters hardened against a CUDA SIGABRT** in overlap owner resolution under the tensor-native Workflows path (@hansent, https://github.com/roboflow/inference/pull/2832).
- **`runtime_compatibility_hash` removed from cache-manifest identity**, so runtime-environment drift no longer invalidates otherwise-valid cached packages (@rafel-roboflow, https://github.com/roboflow/inference/pull/2809).
- **Wheel builds no longer import the full runtime** — building the `inference` wheels pulled in the whole package (torch, OpenCV) after the import changes, which broke image builds in slim stages; version resolution in the setup scripts is now import-free (@PawelPeczek-Roboflow, https://github.com/roboflow/inference/pull/2842).

# 🚧 Maintenance

- **GPU build immune to `PYTHONPATH` changes** (@PawelPeczek-Roboflow, https://github.com/roboflow/inference/pull/2823).
- **Post-v1.4.1 fast-track follow-ups** (@PawelPeczek-Roboflow, https://github.com/roboflow/inference/pull/2837).

## 🏅 New Contributors

* @JoeWayne made their first contribution in https://github.com/roboflow/inference/pull/2812

**Full Changelog**: https://github.com/roboflow/inference/compare/v1.4.1...v1.5.0