Release notes

This page lists what changed in every release, newest first, so you can see what you’d be getting — and whether there’s anything to do — before you upgrade.

How versions work

VectorStep and the Gateway are released together, under the same version number, and are supported only as a matched pair — always run the same version of both. A release appears below as one entry (for example v0.1.13), and each item says whether it’s the VectorStep service or the Gateway. See Status & support.
The Service MCP and Gateway MCP servers are versioned independently and published to PyPI. They get their own entries (for example Service MCP 0.1.5) only when something in them changes.
Where to get a release: container images at ghcr.io/bantex01/vectorstep:<version> and ghcr.io/bantex01/vectorstep-gateway:<version> (image tags have no leading v), native Linux tarballs from the VectorStep-Dist releases, and the MCP servers from PyPI.

How to read these notes

Each entry is grouped as Added, Changed, Fixed and Security, plus an Upgrade notes section whenever you need to do something — a setting to change, a behaviour that’s different, or a step to take before or after upgrading. If a release has no Upgrade notes, you can upgrade without changes.

Release notes start with v0.1.15, the first release. Earlier 0.1.x builds were pre-release and aren’t itemised here.

v0.1.21

Added

VectorStep: bulk actions for the work that piles up when many runs finish at once. On Approvals you can tick several pending approvals, or select them all, and approve or reject them together after a confirmation that states how many are affected. On Runs you can grade several finished runs at once (Correct, Partial or Incorrect, with optional notes). On the Marking queue you can mark several steps in one go, including every unmarked item for a step and not just the five shown in the preview. Each approval keeps its own audit entry, and a bulk grade writes one feedback.bulk_submit audit entry. Items that are unknown or already decided are reported per item and never fail the whole request. Bulk actions need the operator role. See Human in the loop and Marking queue.
VectorStep: new API routes for scripting the same actions: GET /approvals, POST /approvals/bulk, POST /feedback/runs/bulk and POST /feedback/steps/bulk. See the API reference.
VectorStep: two new config keys cap the size of a bulk request: approvals.bulk_max (default 200) and feedback.bulk_max (default 500). See the configuration reference.
Docs: new guides for triggering pipelines from Grafana, Datadog and Dynatrace.

Fixed

Gateway: thinking_level on an Anthropic agent no longer fails with an HTTP 400 on newer Claude models such as claude-sonnet-5-5, which reject the fixed thinking budget. On Claude 4.6 and later the Gateway now sends adaptive thinking and uses your thinking_level as the effort setting; Claude 3.x and 4.0 to 4.5 models keep the fixed budget. You don’t need to change any agent config. minimal maps to low effort, and xhigh maps to max on Opus 4.6 and Sonnet 4.6, which have no xhigh level. See Reasoning effort.
Gateway: Anthropic agents with max_tokens above 21,333 no longer fail with “Streaming is required”. The Gateway now streams the response internally, so max_tokens can go up to the model’s output limit. Responses, usage and error handling are unchanged.
Gateway: a Gateway run from a source checkout now reports its version as dev in /health instead of a stale hardcoded number. Release images and tarballs are unaffected.

Upgrade notes

Thinking on Sonnet 5.5 and Opus 5.5: these models reject an explicit “disabled” setting and think by default, so thinking_level: off (or leaving it unset) does not turn thinking off on them. Set thinking_level: low to keep it light.
Adaptive thinking and max_tokens: on models that use adaptive thinking, thinking tokens count against max_tokens instead of being added on top, so leave generous headroom for agents that think. Models on the fixed budget behave as before.
Very long outputs: a response still has to finish within limits.request_timeout_seconds (default 180 seconds). If you raise max_tokens into the tens of thousands, raise that limit too.

Service MCP 0.1.5

Added

Service MCP: bulk_submit_run_feedback and bulk_submit_step_feedback apply one accuracy grade to many runs or step executions in a single call, and list_pending_approvals lists the approval gates waiting for a decision. There is deliberately no tool that approves or rejects a gate. Needs VectorStep v0.1.21 or later.

v0.1.20

Fixed

VectorStep: the Insights Agents page no longer fails with an internal error on installs that use PostgreSQL. Postgres returns token and duration totals as Decimal values, which the page couldn’t turn into JSON, so it failed as soon as any agent had recorded steps. SQLite installs were not affected.

v0.1.19

Fixed

VectorStep: live OpenRouter pricing now picks the right model when a step’s model is already an OpenRouter id (for example deepseek/deepseek-v4-pro, z-ai/glm-5.2, anthropic/claude-haiku-4.5). Previously the fuzzy matcher could choose a near neighbour at a different price (deepseek-v4-pro-0813, claude-haiku-5.5) or fail to match short model names at all. A step with no match showed no cost, and so did any step whose verifier or grounding model went unmatched. An exact id match is now tried first, so these steps show a cost with the green live-pricing badge.

v0.1.18

Added

Kubernetes deployment templates: skills can now be delivered through the GitOps ConfigMap route (route C), alongside pipelines, steps and agents. Each skill is packed into a tarball in a single ConfigMap and unpacked by the config-reloader sidecar, with its nested files and script permissions intact; adding or changing a skill is a ConfigMap update with no pod restart. An unsafe or malformed skill is rejected, keeps its previous version, and fails the CI job. See Changing config on Kubernetes.
Kubernetes deployment templates: shell-scripts.sh helps deliver executor: shell scripts: it prints the sha256 entries to pin, checks on a merge request that every script is pinned, and applies the scripts ConfigMap with a rolling restart. See Shell-step scripts.
Docs: a new Configuration section covers where config lives and how to change and reload it on Docker, standalone Linux and Kubernetes.

Fixed

VectorStep: shell steps no longer fail with FileNotFoundError after a Kubernetes ConfigMap holding the scripts is re-synced. An edited script now fails with a checksum mismatch, which is the correct error, until its pin is updated and the service restarted.
Kubernetes deployment templates: the example scripts volume now sets defaultMode: 0555. Without it the service rejects every script as not executable.

Upgrade notes

Shell steps on Kubernetes: make sure the volume that mounts your scripts ConfigMap sets defaultMode: 0555, and restart the service after changing a script or its sha256 pin. The script list is read once at startup, so a reload does not pick it up.
Route C installs that predate this release: to deliver skills this way, update apply.sh, reloader.py and gateway-patch.yaml, add pack-skills.py, run apply.sh first and then re-apply the Gateway patch (the Gateway restarts once). Follow Upgrading an existing route C install. Installs that don’t use route C need nothing.

v0.1.17

Changed

VectorStep and Gateway: No functional changes in this release.

v0.1.16

Changed

VectorStep and Gateway: The anonymous startup ping is now sent to a new receiver. The data sent is unchanged (version, OS, architecture, install method and a random install ID), and the opt-outs (DO_NOT_TRACK=1, VECTORSTEP_TELEMETRY=false, telemetry.enabled: false) work as before.

v0.1.15

Added

VectorStep and Gateway: First release. VectorStep is in beta; earlier 0.1.x builds were pre-release and aren’t itemised. From here, each release is listed on this page.