AISIX 0.7.0

Release date: July 31, 2026

This release lets the AISIX gateway generate MCP tools for supported operations described in a REST API's OpenAPI 3.x document, without requiring a separate MCP server. Available in both the open-source AISIX gateway and AISIX Cloud, this capability calls the API and injects the configured credential. MCP servers also gain a per-caller rate limit scoped to a single server. AISIX Cloud adds a review workflow that can require approval before a server reaches callers. Alongside them, every model now has an upstream deadline even when none is configured, and usage records separate what the upstream took from what the caller actually waited for.

Behavior Changes

• Usage event latency fields are renamed to make their scope explicit, and a new field records the caller-facing wait. latency_ms becomes upstream_latency_ms and ttft_ms becomes upstream_ttft_ms; both remain scoped to a single attempt. upstream_ttft_ms is now measured from the start of that attempt rather than from request entry, so it is directly comparable with the latency beside it. The new downstream_latency_ms is scoped to the whole request. On the OpenTelemetry export the span attribute aisix.ttft_ms becomes aisix.upstream_ttft_ms, and aisix.downstream_latency_ms is added, so any dashboard or alert reading those names needs updating. The control plane accepts both the old and the new names, so a gateway managed by AISIX Cloud needs no change. See Metrics and Logs.
• Models that configure no timeout are no longer unbounded. A new deployment-wide upstream.timeout_ms defaults to 6000000, that is 6000 seconds, and applies to any model that sets neither timeout nor stream_timeout. Previously such a model had no upstream deadline at all, so an upstream that accepted the connection and then went silent held the request open indefinitely. The default is deliberately generous, so it is a backstop rather than a responsiveness target. To restore the previous behavior deployment-wide, set upstream.timeout_ms: 0; a single model opts out with timeout: 0. See Configuration Files.
• The timeout and stream_timeout fields on a model group previously had no effect, because members only ever used their own values. They now apply to members that set neither, resolving from the member, then the group, then the deployment default. A model group that already carried these fields starts applying them after this upgrade.
• proxy.request_body_limit_bytes now defaults to 0, which means no cap, instead of 10 MiB. Providers accept larger requests than any fixed gateway default, so a client that worked directly against the provider could break when routed through the gateway. This applies only when the setting is absent from the configuration file; a deployment whose file carries the value explicitly keeps it. To keep a cap on a configuration that omits the setting, set request_body_limit_bytes: 10485760. The value 0 previously meant "reject every request that has a body" and now means "no cap".

New Features

MCP Gateway

• Both the open-source AISIX gateway and AISIX Cloud support MCP servers backed by plain REST APIs. Setting a server's type to openapi and supplying an OpenAPI 3.x document makes the gateway generate one MCP tool per supported operation and execute each tool call as an HTTP request against the API. The gateway holds the configured credential, injects it into outbound calls, and does not expose it to the calling agent. See Expose a REST API as MCP Tools.
• Generated tools go through the same gateway controls as tools from a real MCP upstream, including tool access policies, rate limits, guardrails, and usage records.
• In AISIX Cloud, operators can paste the OpenAPI document, provide a URL for the control plane to fetch once, or load a local file through the dashboard. Each OpenAPI-backed server has a tools page for inspecting the generated tool names and operations.
• AISIX Cloud can require review before publishing an MCP server. A submitted server stays invisible to callers until an approver accepts it, and a change proposed to a server that is already live waits for review without taking the running server offline. See Review MCP Servers Before They Go Live.
• In both products, an API key can carry per-server rate limits, so an agent looping on one MCP server does not consume the same key's allowance for another server. Limits are expressed per second, minute, hour, or day, plus concurrency, and only tool calls are metered, so a client can still connect and list tools after a server-specific allowance is exhausted. The key's own rate limit still applies on top. See Rate Limits and Budgets.

Timeouts

• Two new gateway settings, upstream.timeout_ms and upstream.stream_timeout_ms, provide deployment-wide defaults for the request deadline and the maximum gap between streaming chunks. Deadlines resolve from the model, then the model group, then these defaults, and apply across every endpoint rather than only the chat path. See Configuration Files.
• Model groups expose timeout and stream_timeout in the control plane and dashboard, and an explicit 0 on a model is now preserved rather than normalized away, so a model can opt out of the deployment default.

Observability

• Usage records now report what the caller waited for, measured where the gateway hands bytes to the client rather than where the upstream chunk arrives. Under an output guardrail that masks the response, the stream is held back until the whole response scans clean, and only the caller-facing figure reflects that wait. The dashboard's latency percentiles use this figure and count only successful requests. See Metrics and Logs.
• Subtracting the upstream time-to-first-token from the caller-facing latency isolates the wait the upstream did not account for, which makes gateway-side overhead visible without correlating two systems. On a request that retried, that difference also contains the earlier attempts and the delay between them.

Audit Log

• The audit log supports free-text search across an event's actor, action, and target, an absolute time range, page-by-page navigation, and export of the current result set. See Logging and Auditing.

Deployment

• The data planes page offers a real Helm installation tab alongside the manifest-based one, so a data plane can be installed from the published aisix chart with the environment's connection settings already filled in.

Improvements

• An idle gateway stays in service. The readiness endpoint previously reported a gateway unready once its configuration watch had gone five minutes without an event, which an environment whose resources are not changing produces routinely. Under Kubernetes every replica crossed that threshold at the same moment and the service lost all its endpoints while perfectly healthy. Readiness now reports only whether the gateway is draining and whether configuration has been applied. Configuration freshness remains observable through the health endpoint, the configuration status endpoint, and the aisix_config_* metrics. See Config Status.
• The aisix data-plane Helm chart now uses that readiness endpoint on the proxy port for its readiness probe.
• Requests that exceed a configured body limit return the same error envelope on every route that accepts a body. Previously several JSON endpoints and both raw-body endpoints returned a plain-text rejection, multipart uploads reported a generic client error, and the MCP and agent endpoints returned a bare 400. Malformed JSON on those endpoints likewise now returns the standard envelope. See Headers and Error Codes.
• Amazon Bedrock models honor their configured deadline and connect timeout. The AWS SDK was building its own HTTP client with its own defaults, so a Bedrock model's timeout was not enforced.
• MCP upstream connections honor the gateway's upstream connection settings, including the connect timeout, TCP keepalive, and connection pool sizing.
• Prometheus metric memory no longer grows without bound, and metric series handles are resolved once and cached instead of being looked up on every request.
• Released gateway binaries keep their symbol table, so a profile taken against a shipped image is readable without a special build.
• The overview page shows the full model name in its top-models list instead of truncating it.

Fixes

• The latency recorded for the attempt that succeeded is scoped to that attempt. A request that failed over previously reported the winning attempt's latency measured from request entry, so it included every earlier attempt and the delay between retries, which made a successful failover look like a slow upstream.
• Renaming an MCP server carries its per-server rate limits along, and deleting the server removes them. Previously the limits stayed behind under the old name and silently stopped applying.
• An approver editing an MCP server publishes it instead of taking it offline.
• Providers that the gateway supports natively but the public model catalog does not list can be configured again. They were being rejected during validation.
• Regional provider base URLs match the catalog's provider identifiers, so a region-specific default resolves instead of falling through.
• Audit records are no longer lost when a client disconnects mid-request. The control plane rolls back cleanly, records the disconnect once, and returns a consistent response body.