AISIX 1.7.0: Turn AI Spend Into an Operating Boundary

An AI bill is not yet a useful operating signal if finance sees a total while engineering cannot answer which department, business group, or subsidiary produced it. That gap also makes it difficult to make a budget or rate limit follow the same ownership boundary as the spend it is meant to control.

AISIX 1.7.0, released October 22, 2026, adds cost-attribution tags to API keys, teams, and organization members. For an authenticated request, AISIX resolves one value per tag key and carries the result into usage attribution. Those tags can also select and split conditional rate-limit policies; the release adds organization-level Cost Analysis and pricing changes that make the resulting usage data more useful for cost operations.

This is an AISIX gateway and control-plane workflow, not a claim that AISIX replaces a provider invoice. It attributes gateway-recorded usage and applies gateway policy. Provider billing, contracts, and any provider-side controls remain separate sources of truth.

In the dashboard, this starts with a concrete question: which department generated the recorded spend? The Cost Analysis view below groups usage by Tag: Department, so a platform team can compare engineering and support before choosing a budget or rate-limit boundary.

AISIX Enterprise 1.7.0 demo, captured October 28, 2026. These are real product screenshots from requests to simulated providers. Displayed costs use the demo's configured model prices and are rounded; they are not provider invoices.

Key Takeaways

• A key, its team, and its owning member can each provide tags. For the same tag key, the API key wins, then the team, then the member; different tag keys can come from different levels.
• AISIX does not take these attribution tags from a caller request. Missing tags are not silently invented.
• A conditional rate-limit policy can match tag:<key> and split its counters by a tag. A request without a required group_by tag is not subject to that policy.
• Before upgrading, review pricing and reporting assumptions: response-cache hits are priced at zero in AISIX 1.7.0, and Overview and Usage use hourly rollups with defined timing and precision limits.

Make Ownership Travel With the API Key

Consider a shared AI platform. The platform team owns the gateway, while an R&D department operates an internal assistant and a regional subsidiary operates a customer workflow. Giving every key a complete duplicate taxonomy is brittle; putting all metadata at one organizational level makes local exceptions difficult.

AISIX resolves tags per key when a request authenticates. A member can provide a default such as subsidiary: emea, a team can add business_group: support, and a key can override department for a specific workload. For one repeated key, the nearest defined value wins for each key; the effective set is not three conflicting copies of the same dimension.

The API keys view makes each application's configured department visible. In this demo, Support app carries department=support and Engineering app carries department=engineering; neither key has a team or member binding. This screenshot demonstrates explicit key tags, while the precedence rules above describe how tags can also be inherited. To configure your own vocabulary, declare a tag key and set resource values in the cost-attribution setup guide.

The implementation and schemas make two boundaries explicit. Tags are resolved from the API key, its referenced team, and its referenced member—not from request input—and are not used for authentication or routing. An absent or empty tags object adds no tags. This matters when designing chargeback: a caller cannot relabel a request merely by presenting an HTTP field, and a workload with no value for a dimension should remain visibly unclassified rather than being assigned an assumed owner.

Use the Same Dimension for Limits and Cost Review

Attribution is more useful when an organization can apply a policy at the same boundary it reviews. In 1.7.0, conditional rate-limit policies can match a tag dimension such as tag:department; group_by can give each tag value its own counter. For example, a policy can match a selected business group and give each department its own requests-per-minute bucket.

That does not create a universal limit for untagged traffic. If a matched request lacks a group_by dimension—for example, it has no department value for tag:department—AISIX does not subject it to that policy. Keep a separate default policy if unclassified traffic must also be bounded.

The release also adds organization-level Cost Analysis and lets tags drive budgets and rate limits. Use that combination to create an explicit operating contract:

1. Define a small, durable tag vocabulary such as department, business_group, and subsidiary.
2. Put defaults on members or teams, then use API-key tags only for genuine workload exceptions.
3. Test a key with inherited tags, a key-level override, and a key missing the policy's tag before relying on a tag-based limit.
4. Review usage and Cost Analysis by the same dimensions used by budgets and policies.

The Cost Analysis table provides the request and token counts behind the chart. In this captured demo, engineering accounts for 100 requests and 16,000 tokens; support accounts for 42 requests and 6,720 tokens. Together, the rows account for 142 requests and 22,720 simulated tokens. That makes the cost grouping something the team can inspect against its test traffic.

The same demo's usage breakdown. The displayed $0.02 engineering cost, $0.01 support cost, and $0.03 total are rounded dashboard amounts, not a precise ratio between the two groups. Cost Analysis and managed budgets are available in AISIX Enterprise and Cloud.

Use the budget guide to configure a budget for the cost owner you reviewed. Budget decisions use reported usage and cached checks, so allow for in-flight spend when verifying a hard stop; the chart itself does not establish that enforcement has occurred.

Upgrade the Cost Model Deliberately

AISIX 1.7.0 changes more than tag fields. It introduces organization currency choices, input-length tiers, Model Group pricing, off-peak Model Group discounts, upstream service-tier prices, and a default one-hour Claude cache-write rate that is twice the applicable input rate. These are pricing-model changes, not provider-invoice guarantees.

Two behavior changes deserve a dashboard review. First, every usage event with cache_status: hit is priced at zero in AISIX, so it no longer adds to spend or budgets; replayed token counts and cache-hit-saved fields do not disappear. Second, Overview and Usage values are computed from whole UTC-hour rollups. Usage events are assigned to their occurred_at hour, latency percentiles are approximate, and incoming usage can trail by about five seconds. Do not compare a pre-upgrade dashboard to a post-upgrade one without accounting for both semantic changes.

For a phased deployment, also read the 1.7.0 mixed-version notes. Decision endpoints require 1.7.0 gateways, and older gateways in a 1.7.0 control-plane environment do not report service_tier for the related policy behavior. Upgrade and verification must therefore include the gateways that will enforce and report the contract, not just the control plane.

Turn Attribution Into an Operating Decision

AISIX 1.7.0 makes it practical to answer a cost question with the same identity boundary used to govern traffic: which organizational owner initiated this gateway usage, and which policy should apply? The answer is strongest when tag inheritance, budget/reporting views, and rate-limit dimensions are designed together—and when teams keep untagged traffic, cache pricing, rollup timing, and provider billing boundaries visible.

Read the AISIX 1.7.0 release notes before upgrading, then validate representative keys and policy outcomes in a non-production environment before applying spend controls to production traffic.