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, #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.

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, #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, #2825).

🎯 Visual prompts for SAM3 Video Tracker

The SAM3 Video Tracker now accepts visual prompts, extending prompt-based tracking beyond text (@leeclemnet, #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, #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, #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, #2801), the Qwen3.8 vLLM proxy with a qwen_vlm workflow variant for base-only serving (@hansent, #2802), and Mage-VL, a codec-native video VLM (@Erol444, #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, #2828).
• Triton kernel runtime errors now fall back gracefully instead of failing the request (@dkosowski87, #2815).
• Tensor painters hardened against a CUDA SIGABRT in overlap owner resolution under the tensor-native Workflows path (@hansent, #2832).
• runtime_compatibility_hash removed from cache-manifest identity, so runtime-environment drift no longer invalidates otherwise-valid cached packages (@rafel-roboflow, #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, #2842).

🚧 Maintenance

• GPU build immune to PYTHONPATH changes (@PawelPeczek-Roboflow, #2823).
• Post-v1.4.1 fast-track follow-ups (@PawelPeczek-Roboflow, #2837).

🏅 New Contributors

• @JoeWayne made their first contribution in #2812

Full Changelog: v1.4.1...v1.5.0