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.

Gateway MCP 0.1.3

Changed

• Gateway MCP: the package’s “Changelog” link on PyPI now points to these release notes. No functional changes.

v0.1.23

Added

• VectorStep and Gateway: log lines can now be matched to traces, and runs to their log lines. Every line carries [trace_id=… span_id=… run=… step=…], set per run and per step or branch, so lines from concurrent runs and parallel or fan-out branches stay apart. The service sends the run and step to the Gateway with each agent call, so the Gateway’s lines carry them even with tracing off. A new logging.format: json writes one JSON object per line, which also includes the pipeline name. The run’s trace ID is stored, returned by GET /runs/{id} and shown on the run page. Set observability.otel.trace_url_template to turn it into a link to your tracing backend. See Correlating logs with traces.
• VectorStep and Gateway: logs can be exported over OTLP to your collector, in addition to stdout, with observability.otel.logs.enabled (off by default). Records carry the trace and span IDs, vectorstep.run.id, vectorstep.step and vectorstep.pipeline.name, and use the same service.name as traces, so your backend can go from a trace to its logs and back. Export runs on a background thread, so an unreachable collector never slows a run, and records are scrubbed of known credential shapes. See Exporting logs over OTLP.
• VectorStep: opt-in step output capture with observability.otel.logs.capture_content: output (or output_and_prompt). Each finished step and branch sends its output, and optionally its rendered prompt, to your log backend as a vectorstep.step.output record, truncated at capture_content_max_chars. Captured content never goes to stdout or the log files. Step output can contain customer data, so read the warning in the docs before turning it on.
• Gateway: POST /reload (and SIGHUP) now refreshes the tool lists of running MCP servers, so a tool added to or removed from a sidecar is available without restarting the Gateway. The response gains mcp_tools with added, removed, failed and warnings. A server that is down keeps its previous list, and an agent that names a tool its server no longer offers still loads, with a warning. Adding or changing a server still needs a restart. See MCP tool servers.
• VectorStep and Gateway: the agent loop limit and the per-LLM-request timeout can now be set per agent and per step, so one heavy agent no longer forces you to raise them for every agent. Use limits: {max_iterations, request_timeout_seconds} in agent.yaml, or max_iterations and request_timeout_seconds in a gateway step’s executor_config. The step value wins, then the agent’s, then the Gateway default. Both are capped by the new Gateway settings limits.max_agent_iterations_ceiling (default 100) and limits.request_timeout_ceiling_seconds (default 1800), and a value above a ceiling is capped with a warning at load. A step whose timeout_seconds is shorter than its request_timeout_seconds is flagged at validation. See Per-agent limits.
• VectorStep: a warning when grounding can’t see what the Gateway sends it. If a step’s executor_config.trace_max_chars is higher than its grounding.max_trace_chars (or verifier.max_trace_chars in critic mode), validation and startup warn and name both settings, because the service would cut every tool result back down and grounding scores would look low. At run time, a step whose trace the service truncated logs a warning. See Fixing grounding accuracy.
• Docs: new and expanded sections on loop_until and its loop.* variables, addressing fan-out branches in templates, hyphenated step names, data and context_template.include for generic webhooks, what a rerun rebuilds, LLMOutput rules, skills deployment order, roles on read routes and GET /runs filters.

Changed

• VectorStep and Gateway: the text log line has a new field block before the message: [trace_id=… span_id=… run=… step=…]. Anything that parses the old line needs updating; see Upgrade notes.
• VectorStep: ${VAR} is now substituted anywhere inside a string in executor and check config, for example Authorization: Bearer ${TOKEN}, matching the Gateway. Previously it only worked when ${VAR} was the whole value. Write $${ for a literal ${. An unset variable still becomes an empty string, and the service now logs a warning naming it. The webhook executor’s url is now expanded too. Only your configuration is expanded, never run data such as agent output or an alert payload. See Environment variables in config.

Fixed

• VectorStep: a rerun, or a replay in rerender mode, of a pipeline with a fan_out registered the branch outputs under the wrong names, so {{ steps['check-upstreams/0'] }} was empty after a rerun and two fan-outs in one pipeline overwrote each other. Branches now keep their <fan_out name>/<index> names, as in a live run. Parallel-group branches are unchanged.
• VectorStep: on any startup that applied a database migration, the service lost its own logging set-up for the rest of that process: the log format reverted, service.log stopped being written and OTLP log export stopped until the next restart. Logging now stays as configured.
• VectorStep: the agent detail page (/ui/agents/{executor}/{agent}) no longer fails with an internal error on Postgres for agents with production step history.

Security

• VectorStep: a secret placed in a notify or webhook step’s URL could reach the log, the run record and the step’s error message. The notify executor logged the URL after ${VAR} expansion and stored it in a testing-stage step’s summary, and an HTTP error from either executor included the full expanded URL. Both now log, store and report the URL as written in config, with any user:password@ and query string removed. Telegram bot and Slack webhook URLs were already masked. If you put other secrets in a notify URL, check your logs; see Upgrade notes.

Upgrade notes

• Upgrade VectorStep and the Gateway together. Per-step limits, and run and step names on the Gateway’s log lines, need the new Gateway. An older Gateway ignores them: limits fall back to the Gateway’s own settings and its lines show run=- step=-.
• Log parsers: if anything parses the text log line (a log shipper’s regex, an alert rule), update it for the new [trace_id=… span_id=… run=… step=…] block, or switch both services to logging.format: json. Access-log lines are unchanged.
• Literal ${…} in executor or check config now expands. If a header, URL or payload value contained a literal ${...} that should be sent as written, escape it as $${...}.
• Database migration: a nullable trace_id column is added to pipeline_runs automatically when the service starts. Earlier runs, and runs made with tracing off, have no trace ID. To roll back to v0.1.22, first run alembic downgrade 0010_cache_tokens with the v0.1.23 image (for example kubectl exec deploy/vectorstep -c vectorstep -- sh -c 'cd /app && alembic downgrade 0010_cache_tokens'), then switch images. v0.1.22 won’t start against the newer schema.
• Log export needs a logs pipeline in your collector. If your OpenTelemetry Collector only has traces and metrics pipelines, add a logs pipeline with the otlp receiver and your backend’s exporter, or the records are dropped at the collector.
• Per-agent limits and calibration: adding a limits: block to an agent changes its version, so its calibration buckets start again from empty. Agents you don’t change keep their version.
• Long generations: the v0.1.21 advice to raise the Gateway-wide limits.request_timeout_seconds for very long outputs still works, but you can now raise it for just the agent or step that needs it.
• Secrets in notify URLs: if you put a credential in the path of a notify step’s URL (other than a Telegram or Slack URL), earlier versions may have written it to service.log and to run records. Rotate it.

v0.1.22

Added

• VectorStep and Gateway: prompt-cache tokens are now reported, stored and priced. Anthropic bills cache reads and writes at their own rates and leaves them out of the normal input token count, so the cost of an agent that uses caching was understated. Steps now record cache read and write tokens (shown on the run page and in GET /runs/{id}), and you can price them with the optional cache_read_per_mtok and cache_write_per_mtok on a pricing.models entry. Live OpenRouter pricing picks the rates up automatically. If cache tokens have no matching rate, the step’s cost is left unknown rather than undercounted. Two new metrics, vectorstep_pipeline_cache_tokens_total and vectorstep_gateway_llm_cache_tokens_total, export them; the existing token metrics are unchanged. See Cost accounting.
• VectorStep: POST /pipelines/validate now returns warnings, and the service logs the same warning at startup and after a reload, when a budget.max_usd cannot trip because a gateway step’s model (or one of its fallbacks) has no price. The valid field is unaffected.
• VectorStep: GET /runs/{id} now includes each step’s cost and a run-level cost block. Add ?include=trace,prompt,cost for the heavy fields, and use the new GET /runs/{id}/steps/{step} to fetch one step in full. Unknown cost is null, never zero. See the API reference.
• VectorStep: the Runs list and the Pending approvals list refresh themselves every 10 seconds. Polling pauses while the tab is hidden, rows are selected, or a filter has focus.
• Installer: if VECTORSTEP_TELEMETRY or DO_NOT_TRACK is set when you run install.sh, it is now written into the install’s .env so the services start with the anonymous startup ping already off. See Anonymous usage reporting.

Changed

• VectorStep: budget.max_usd and budget.max_tokens now apply after a step that fails with on_failure: continue. Previously the failed step’s spend was counted but the check was skipped, so a pipeline whose steps all failed could never trip the budget.
• VectorStep and Gateway: a generation cut off at the model’s output-token limit is now reported as such (output truncated: the model stopped at its output-token limit) instead of as a JSON parse error, and is not retried, because the same request would truncate the same way. This needs the matching Gateway; an older Gateway keeps the generic parse error. See Step failed with “output truncated”.

Fixed

• VectorStep: a gateway step that failed after the model had answered (for example no payload contained valid JSON) was saved with no trace, tokens or cost, and its spend never counted towards budget.max_usd. It now keeps all three. With retry:, usage is summed across attempts onto the one step row.

Security

• VectorStep: earlier versions could write the Telegram bot token to the service log, because the Bot API puts the token in the request URL and a failed poll or send logged the raw error. Log output is now scrubbed of known credential shapes, including in exception tracebacks, and the run event log shown in the UI is scrubbed too. See Secrets in logs.

Upgrade notes

• If you use Telegram approvals or notifications, rotate your bot token. Open BotFather, run /revoke, update the token wherever you store it, and delete old service.log* files and anything that collected them (a log shipper, a cluster log store). Fixing the code does not remove tokens already written to logs.
• Upgrade VectorStep and the Gateway together. Cache-token pricing and the output-limit error need the new Gateway. With an older Gateway they simply don’t appear: cache tokens are not recorded and the generic parse error is shown.
• Database migration: the new nullable cache-token columns are added automatically when the service starts. Existing rows stay empty (NULL means “not reported”).
• Budgets can now trip where they didn’t before if you use on_failure: continue. Check any pipeline whose budget you set low.
• API clients: the validate response has a new warnings key, and GET /runs/{id} has new fields. Clients that ignore unknown keys are unaffected.

Service MCP 0.1.6

Added

• Service MCP: get_run takes include (trace, prompt, cost) and returns per-step and run-level cost, and the new get_step_trace(run_id, step_name) returns one step’s trace, rendered prompt, usage and cost. validate_pipeline now documents the warnings list. Needs VectorStep v0.1.22 or later; against an older service include is ignored and get_step_trace returns 404.

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.