AxonFlow v7.8.0 Release Notes

V1 Plugin Pro graduated-freemium release. Builds on the v7.7.0 V1 launch by completing the five Free→Pro differentiators end-to-end. v7.7.0 already shipped the daily-quota and audit-retention dimensions; v7.8.0 adds the remaining three (custom-policy cap, HITL-approval rolling-window cap, LLM cost pre-flight as a Pro-only feature), plus the structured upgrade-prompt envelope on 429 / 403 paths, five new MCP tools the AI assistant can call directly, correct Pro-tier daily-quota delivery, daily-cap routing on every MCP/proxy path, and an explicit success field on tool responses so LLMs no longer have to infer success from ambiguous fields.

Self-hosted deployments are unaffected; the new tools are tier-gated, and the new envelope shape appears automatically on the existing 429 / 403 response paths (no client-side opt-in required — older plugin/SDK clients see the envelope as additional response-body fields they can choose to render or ignore).

V1 customer-facing surfaces shipping in this release:

• Five new MCP tools that the AI assistant can call directly: axonflow_get_tenant_id, axonflow_request_approval, axonflow_create_tenant_policy, axonflow_get_cost_estimate, axonflow_list_pro_features. Tier-gated at dispatch — of the 5 V1 tools, Free callers see 4 in tools/list and Pro callers see all 5; the Pro-only axonflow_get_cost_estimate is filtered out for Free callers and returns feature_pro_only if called directly. (Legacy MCP tools — check_policy, audit_tool_call, list_overrides, etc. — remain unchanged in tools/list for both tiers.)
• Structured Free-tier-limit envelope on every 429 daily-quota and 403 graduated-limit / Pro-only response. Locked shape: error, limit_type, tier, limit, remaining, window, resets_at, upgrade.{tier, wording, compare_url, buy_url}. Plus headers X-Axonflow-Tier-Limit, X-Axonflow-Upgrade-URL, Retry-After. One parser handles every path on the plugin side.
• Pro daily quota delivered correctly at 2,000/day. The PRD has always specified Pro = 2,000 events/day; v7.7.0 advertised it but the enterprise build returned 1,000/day because of a missed file in the build overlay. v7.8.0 fixes the overlay so Pro tenants now actually receive the 10× headroom over Free's 200.
• Daily-cap enforcement now covers every MCP/proxy route. /api/v1/mcp-server, /api/v1/mcp/check-input, and /api/v1/mcp/check-output were skipping the daily-cap middleware in v7.7.0 — plugin pre/post-tool hooks went unbilled. Now wired so all governed routes count toward the tenant quota uniformly.
• Explicit success: true on every V1 MCP tool response body. Cursor + Claude Code runtime testing caught LLM consumers misclassifying clean tool successes as failures because the response shapes lacked an unambiguous success signal. Each of the 5 V1 tools now sets success: true on success; axonflow_request_approval also sets submitted: true + awaiting_review: true; axonflow_create_tenant_policy also sets created: true.

Companion plugin releases (now tagged + published). All four plugins (axonflow-claude-plugin, axonflow-cursor-plugin, axonflow-codex-plugin, axonflow-openclaw-plugin) advance to v1.3.0 / v2.3.0 with envelope-aware error handling, surfacing the Pro upgrade prompt on 429 / 403, and Retry-After backoff. SDK versions are unchanged at v7.1.0 — no SDK wire-shape or behavior change in this release; SDK READMEs received the AXONFLOW_TELEMETRY=off scope clarification only.

5th SDK live — Rust preview at v0.1.0. First-ever AxonFlow Rust SDK shipped to crates.io covering proxy + audit + basic MAP + basic MCP + OpenAI interceptor. Repo: getaxonflow/axonflow-sdk-rust. Quickstart: Rust Getting Started. Foundation contributed voluntarily by Francesco Pierfederici.

No breaking platform changes. Existing v7.7.0 + v7.6.x SaaS Plugin Pro license tokens continue to validate.

What's new

Five new MCP tools — tier-gated at dispatch

Each tool is registered on the agent's /api/v1/mcp-server JSON-RPC endpoint and exposed to the AI assistant via the standard tools/list discovery flow. Tier-gating happens at tools/call dispatch:

Tool	RequiredTier	FreeUsageLimit	What it does
axonflow_get_tenant_id	All	none	Returns the calling tenant's identity, current tier (Free / Pro / Pro-expired), and Pro upgrade URL. Use when the user asks how to upgrade, what tier they're on, or for their tenant ID for Stripe Checkout.
axonflow_request_approval	All	Free = 1 per rolling 7d	Request human-in-the-loop approval before executing a risky operation. Inserts a row into hitl_approval_queue and returns its ID. Free tier supports 1 approval per rolling 7-day window; Pro removes the cap.
axonflow_create_tenant_policy	All	Free = 2 active max	Create a custom tenant-scoped governance policy at runtime. Free tier supports 2 active policies (delete one to make room); Pro removes the cap. Required args: name, connector_type, pattern, action.
axonflow_get_cost_estimate	Pro only	n/a	Pre-flight LLM cost estimate before running a multi-step plan. Proxies to the orchestrator's /api/v1/plans/estimate for canonical per-model pricing data. Free callers receive a feature_pro_only envelope.
axonflow_list_pro_features	All	none	Pure-data tool — returns the locked V1 differentiator list, pricing, upgrade URLs, and tone direction. So a Free user's AI can answer "what would I get if I upgraded?" without reading docs.

tools/list filtering is honest visibility: of the five V1 tools, Free callers see 4 and Pro callers see all 5. The filter is not a security boundary — tools/call re-enforces tier on dispatch — but it shapes the AI assistant's discovery so it doesn't suggest Pro-only tools to Free users.

Full per-tool examples + response shapes at Plugin Pro.

Structured Free-tier-limit envelope

Every Free-tier limit hit (429 daily-quota or 403 graduated-limit / Pro-only) now returns the same envelope shape so plugin consumers parse one shape across every rejection path:

{
  "error": "<short string>",
  "limit_type": "daily_quota | active_policies | hitl_approvals_window | feature_pro_only",
  "tier": "Free",
  "limit": 200,
  "remaining": 0,
  "window": "daily_utc | rolling_7d | null",
  "resets_at": "<RFC3339> | null",
  "upgrade": {
    "tier": "Pro",
    "wording": "<positive-framing string under 200 chars>",
    "compare_url": "https://getaxonflow.com/pricing/",
    "buy_url": "https://buy.stripe.com/bJe28qbztcdVchjdkw8k800"
  }
}

Plus locked headers on every gated response: X-Axonflow-Tier-Limit: <limit_type>, X-Axonflow-Upgrade-URL: https://getaxonflow.com/pricing/, and Retry-After: <seconds> where applicable. Tone direction across all wordings: positive framing, never "denied" / "forbidden" / "unauthorized".

The four locked limit_type wordings:

limit_type	HTTP	Wording
daily_quota	429	"Daily limit reached on Free tier (200 events). Pro raises this to 2,000/day. Resets at midnight UTC."
active_policies	403	"Free tier supports 2 active custom policies. Delete one to make room, or Pro removes the cap."
hitl_approvals_window	403	"1 of 1 HITL approvals used in the last 7 days. Next available {resets_at}. Pro removes this cap."
feature_pro_only	403	"LLM cost pre-flight is a Pro feature — see what a multi-step plan will cost before it runs."

Pro daily quota = 2,000 events/day (delivered correctly)

The Plugin Pro tier has always specified 2,000 events/day; the public landing pricing page has advertised that number since the v7.7.0 launch. The agent's enterprise build, however, was returning Pro = 1,000/day because of a discrepancy between the community and enterprise builds.

Fixed in this release: a Pro tenant on prod actually gets 2,000 events/day for the 90-day window.

Daily-cap routing on every MCP / proxy route

In v7.7.0, the daily-cap middleware fired on /api/v1/audit/tool-call (and a small set of related write endpoints) but not on the plugin's primary surfaces:

• /api/v1/mcp-server (the MCP JSON-RPC endpoint exposing the new V1 tools + the legacy 5 tools)
• /api/v1/mcp/check-input (PreToolUse policy check)
• /api/v1/mcp/check-output (PostToolUse PII / output scan)

Plugins call these routes on every governed tool call, so quota was effectively un-enforced for plugin traffic. v7.8.0 wires the cap onto every governed plugin / SDK route so all tenant traffic counts uniformly toward the daily quota.

Explicit success flag on V1 MCP tool responses

Real plugin runtime testing surfaced LLM consumers misclassifying clean tool successes as failures because the response shapes lacked an unambiguous success signal — for example, axonflow_request_approval was returning status: "pending" (the correct HITL row state — the request was created but awaiting human review) and the model read "pending" as "didn't complete".

Per-tool response-shape additions:

Tool	New fields	Why
axonflow_get_tenant_id	success: true	Pure data tool — explicit signal
axonflow_list_pro_features	success: true	Pure data tool — explicit signal
axonflow_get_cost_estimate	success: true	Orchestrator passthrough — added at plugin layer
axonflow_request_approval	success: true, submitted: true, awaiting_review: true	LLMs were reading status: "pending" (correct HITL row state) as "didn't complete"
axonflow_create_tenant_policy	success: true, created: true	LLMs found enabled: true ambiguous; explicit created: true removes the read

These are additive fields — existing consumers that ignore them continue to work. JSON-RPC error responses (isError: true) are unchanged; the new success field appears on the success-path body only.

Telemetry stream classifier — privacy-policy implementation

The privacy policy on getaxonflow.com committed to a stream-of-origin classifier landing before any future Community SaaS operational stream is wired into the SDK/plugin heartbeat table. v7.8.0 ships that classifier:

• New Stream field on every record on the central telemetry receiver — set unconditionally to heartbeat for the SDK/plugin heartbeat path.
• Reserved community_saas_operational value for the future operational-data stream when wired.
• A separate classification dimension orthogonal to the existing source-of-record classification — together they answer "who generated the ping" and "what data path produced this row" as independent questions.

No customer-visible surface change — this is internal data hygiene that backs the privacy commitment in production.

AXONFLOW_TELEMETRY=off scope — clarified across docs

The opt-out env var has the same mechanics in v7.8.0 as v7.7.0, but the documentation across this docs site, the plugin / SDK READMEs, and the privacy policy now makes the scope explicit:

• On self-hosted and in-VPC deployments, the heartbeat is the only data path the SDK or plugin sends to AxonFlow — AXONFLOW_TELEMETRY=off is the relevant opt-out lever.
• On Community SaaS (try.getaxonflow.com), the hosted service also processes operational data (registrations, audit logs, policy enforcement records, workflow state, plan data, request-header metadata aggregated for usage analytics) as part of running the platform. That operational data flow is governed by the Privacy Policy, not by this env var.

Full scoping note at Telemetry. Privacy policy now lists Community SaaS usage analytics as an explicit Article 6(1)(f) processing purpose.

Security + reliability fixes

• MCP-tool license-tier consistency. The new axonflow_create_tenant_policy and axonflow_request_approval MCP tools now respect the same license-tier caps as the corresponding HTTP API endpoints. Self-hosted Community-tier users invoking these tools will hit the documented Community limits (20 tenant policies; HITL queue requires Evaluation tier or higher) consistently across both paths, matching the published Community vs Enterprise feature matrix.
• CVE-2026-41602 (HIGH) — github.com/apache/thrift v0.22.0 → v0.23.0. Indirect dependency through github.com/apache/arrow-go/v18 and github.com/snowflakedb/gosnowflake. Bumped via go get + go mod tidy; Trivy filesystem scan now passes on every PR.
• PR1 envelope harness payload fix. The runtime-e2e harness was sending a request body that returned 400 (validation failed) at the boundary while the daily-counter still incremented at middleware — the over-cap 429 still landed cleanly, masking a hidden boundary regression. Payload corrected to the canonical ToolCallAuditEntry shape.
• PR1 envelope harness boundary assertion. Even after the payload fix, the harness didn't assert anything about the boundary-request status. Added an explicit expect 200 or 201 before checking the over-cap envelope assertion so the same false-positive class can't sneak back in.
• PR2 MCP tools harness fixes. Wrong registration endpoint path (/api/v1/community-saas/register → /api/v1/register); harness was POSTing a desired tenant_id but the server mints its own (now consumes server-issued credentials); tools/list filter assertion expected all 5 tools visible to a Free caller (correct contract is 4 visible + Pro-only axonflow_get_cost_estimate filtered out — both halves now exercised).

Companion plugin releases

Plugin	Version	Install
OpenClaw (axonflow-openclaw-plugin)	v2.3.0	npm install @axonflow/openclaw@^2.3.0
Claude Code (axonflow-claude-plugin)	v1.3.0	Marketplace install via Claude Code
Cursor (axonflow-cursor-plugin)	v1.3.0	Cursor IDE local install
Codex (axonflow-codex-plugin)	v1.3.0	Codex marketplace install

All four plugins now parse the V1 envelope on 429 / 403, surface upgrade.wording to the user via the plugin's normal notification surface, honor the Retry-After header (back off until resets_at, no retry storm), and reference the 5 new MCP tools in their READMEs / SKILL.md files.

Companion SDK releases

No SDK code changes in this release. SDKs remain at v7.1.0 with documentation-only updates clarifying the AXONFLOW_TELEMETRY=off scope.

SDK	Version	Install
Go	v7.1.0 (unchanged)	go get github.com/getaxonflow/axonflow-sdk-go/[email protected]
Python	v7.1.0 (unchanged)	pip install 'axonflow>=7.1.0'
TypeScript	v7.1.0 (unchanged)	npm install @axonflow/sdk@^7.1.0
Java	v7.1.0 (unchanged)	<version>7.1.0</version> in pom.xml
Rust	v0.1.0 (preview, unchanged)	cargo add axonflow-sdk-rust

Upgrade path

No migration required from v7.7.x — the new tools, envelope shape, and Stream field are additive.

For Plugin Pro buyers on v7.7.0: the agent now correctly delivers 2,000 events/day (was 1,000 due to the build-overlay miss). No buyer action required — the change is server-side and effective on the next governed request.

For plugin operators: upgrading to v1.3.0 / v2.3.0 enables the envelope-aware error handling that surfaces the Pro upgrade prompt to end users on rate-limit / Pro-only-feature hits. Without the plugin upgrade, the new envelope arrives intact on the wire but the plugin doesn't render it — the user sees a generic error.

References

• Plugin Pro — full Pro tier guide including the 5 new MCP tools, structured envelope, and per-plugin token install
• Telemetry — AXONFLOW_TELEMETRY=off scope clarification
• Privacy Policy — Community SaaS operational data flow under Article 6(1)(f)
• Community SaaS deployment — registering a tenant, retrieving credentials, the Free baseline
• v7.7.0 release notes: v7-7-0