zuplo 7.3.2 → 7.4.1

package/docs/ai-gateway/apps.mdx

@@ -27,8 +27,8 @@ Each app has three things of its own:
 - **An API key**—authenticates the app's requests when the gateway runs the
   [authentication policy](./policy-chains.mdx#authentication).
 - **A [policy chain](./policy-chains.mdx)**—the ordered policies that run on the
-  app's requests: model access, budgets, caching, guardrails, and custom
-  policies. The chain starts out empty unless the app's team has a
+  app's requests: model access, app-specific budgets, caching, guardrails, and
+  custom policies. The chain starts out empty unless the app's team has a
   [policy template](./policy-templates.mdx).
 
 ## API Keys

package/docs/ai-gateway/custom-policies.mdx

@@ -7,9 +7,9 @@ description:
   push, and add it to an app's policy chain in the portal.
 ---
 
-The AI Gateway's built-in policies cover model access, budgets, caching,
-guardrails, and tracing—but your gateway can run any policy you can write in
-TypeScript. A custom policy lives in your gateway's
+The AI Gateway's built-in policies cover model access, app-specific budgets,
+caching, guardrails, and tracing—but your gateway can run any policy you can
+write in TypeScript. A custom policy lives in your gateway's
 [repository](./source-control.mdx), is declared in `config/policies.json`, and
 from then on appears in the portal's **Add Policy** dialog like any built-in
 policy. Apps add it to their [policy chains](./policy-chains.mdx), and it runs

package/docs/ai-gateway/fallback.mdx

@@ -7,8 +7,8 @@ description:
 ---
 
 Fallbacks let an app keep serving requests when its primary model fails, times
-out, or runs over its usage limits, instead of returning an error to the caller.
-They're configured with the **Fallback Model** policy in the app's
+out, or an applicable usage limit is exceeded, instead of returning an error to
+the caller. They're configured with the **Fallback Model** policy in the app's
 [policy chain](./policy-chains.mdx).
 
 The AI Gateway offers two independent fallback mechanisms, each triggered by a
@@ -17,7 +17,7 @@ different condition:
 | Mechanism              | Triggers when…                                                                                         | Without a fallback set…                     |
 | ---------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------- |
 | **Fallback & Timeout** | The primary fails with a retryable error (`5xx`, `408`, `425`, `429`), a network failure, or a timeout | The gateway returns the error to the caller |
-| **Quota Fallback**     | One of the app's usage limits is exceeded                                                              | The request is blocked with a `429`         |
+| **Quota Fallback**     | An app, team, or gateway usage limit is exceeded                                                       | The request is blocked with a `429`         |
 
 Both are configured entirely in the Zuplo Portal, and either can route to _any_
 provider—the fallback doesn't have to share the primary's provider. Fallback
@@ -57,21 +57,22 @@ is configured, the primary model call runs unbounded.
 ## Quota fallback
 
 The quota fallback routes requests to an alternate, usually cheaper, model when
-one of the app's [usage limits](./usage-limits.mdx) is exceeded, rather than
-blocking the request with a `429`. This keeps an app available after it crosses
-a budget, token, or request threshold, while shifting the overflow traffic to a
-lower-cost model.
+an app, team, or gateway [usage limit](./usage-limits.mdx) is exceeded, rather
+than blocking the request with a `429`. This keeps an app available after an
+applicable budget, token, or request threshold is crossed, while shifting the
+overflow traffic to a lower-cost model.
 
-For the quota fallback to activate, the chain needs the **Budgets and Costs**
-policy after Fallback Model—it detects the exceeded limit and switches to the
-fallback selection. If you leave the quota fallback empty, the app blocks
-requests with a `429` once it goes over quota.
+The **Fallback Model** policy supplies the quota fallback selection. Team and
+gateway limits can activate it whether or not the chain includes **Budgets and
+Costs**. Add Budgets and Costs when the app also needs its own limits, and place
+it after Fallback Model. If you leave the quota fallback empty, the gateway
+blocks requests with a `429` once an applicable limit is exceeded.
 
 :::tip
 
 Point the quota fallback at a smaller, cheaper model so overflow traffic stays
 inexpensive while remaining available. The fallback's own usage still counts
-toward the app's limits.
+toward every applicable limit.
 
 :::
 

package/docs/ai-gateway/getting-started.mdx

@@ -107,7 +107,8 @@ account, Zuplo project, and AI Gateway team roles control access.
    on later teams, letting you nest them. To set gateway-wide spending limits
    across this Zuplo project, open the gateway's **Settings → Usage Limits**;
    for team-specific limits, use the team's **Usage & Limits** tab. See
-   [Usage Limits](./usage-limits.mdx).
+   [Usage Limits](./usage-limits.mdx). Gateway and team limits apply to every
+   app regardless of its policy chain.
 
 5. **Create an app**
 
@@ -117,8 +118,8 @@ account, Zuplo project, and AI Gateway team roles control access.
    In the **Apps & Teams** tab, select the team you just created and click
    **Create App** in the team's header. Give the app a descriptive name (for
    example, "Tennis Chat") and confirm the team that owns it. That's the whole
-   dialog—models, budgets, and other behavior are configured on the app's policy
-   chain in the next step.
+   dialog—models, app-specific budgets, and other behavior are configured on the
+   app's policy chain in the next step.
 
    :::tip
 
@@ -148,9 +149,9 @@ account, Zuplo project, and AI Gateway team roles control access.
 
    :::
 
-   This is also where you add budgets, semantic caching, guardrails, and any
-   custom policies. Changes to the chain apply within about a minute—no redeploy
-   needed. See [Policy Chains](./policy-chains.mdx).
+   This is also where you add app-specific budgets, semantic caching,
+   guardrails, and any custom policies. Changes to the chain apply within about
+   a minute—no redeploy needed. See [Policy Chains](./policy-chains.mdx).
 
 7. **Get the app's URL and API key**
 
@@ -300,8 +301,8 @@ metrics.
 
 ## Next steps
 
-- [Policy Chains](./policy-chains.mdx): add budgets, semantic caching, and
-  guardrails to your app's chain
+- [Policy Chains](./policy-chains.mdx): add app-specific budgets, semantic
+  caching, and guardrails to your app's chain
 - [Custom Policies](./custom-policies.mdx): write your own policy and add it to
   an app's chain
 - [Policy Templates](./policy-templates.mdx): give every new app in a team a
@@ -317,4 +318,4 @@ metrics.
 | 404 "Unsupported AI Gateway endpoint"     | The path must end with a supported `/v1/...` operation—usually the URL is missing its `/v1` segment. Use the app's API URL plus `/v1/chat/completions`, for example |
 | 400 error asking for `providerName/model` | Prefix the model with the provider name configured in the portal—`openai/gpt-5-mini`, not `gpt-5-mini`                                                              |
 | 403 error listing the allowed models      | The app's Model Filtering policy doesn't include the requested model; add it on the app's Policies tab or use a listed one                                          |
-| Budget limit reached immediately          | Check the limits at every level—gateway, team, and the app's Budgets and Costs policy—since any level's limit blocks the request                                    |
+| Budget limit reached immediately          | Check the gateway and team limits, which always apply, plus the app's Budgets and Costs policy; any level's limit can block the request                             |

package/docs/ai-gateway/introduction.mdx

@@ -16,11 +16,12 @@ responses while applying policies, controls, and monitoring.
 Each piece of software that calls the gateway registers as an **app**—your
 support chatbot is one app; an internal coding agent is another. A single AI
 Gateway holds as many apps as you need, and you control exactly which policies
-run for each one. Every app has its own ordered policy chain, so the
-customer-facing chatbot can enforce budgets and guardrails while the internal
-agent runs with none. Beyond the built-in policies, you can write your own in
-TypeScript, and apps add them to their chains like any other policy. Chain
-changes apply within about a minute, with no redeploy. See [Apps](./apps.mdx).
+run for each one. Every app has its own ordered policy chain, so you can give
+the customer-facing chatbot an app-specific budget and guardrails while leaving
+those controls out of the internal agent's chain. Beyond the built-in policies,
+you can write your own in TypeScript, and apps add them to their chains like any
+other policy. Chain changes apply within about a minute, with no redeploy. See
+[Apps](./apps.mdx).
 
 ## Key Benefits
 
@@ -59,15 +60,15 @@ provider. Each app has its own URL, API key, and policy chain, so one gateway
 serves teams with completely different configurations.
 
 Each request arrives at the URL of the app it belongs to. The gateway identifies
-that app, runs its policy chain (model access, cost controls, security
-guardrails), routes to the selected LLM provider, and streams the response back.
-Throughout this process, the gateway captures metrics without exposing
-underlying provider credentials.
+that app, runs its policy chain (model access, app-specific cost controls,
+security guardrails), routes to the selected LLM provider, and streams the
+response back. Throughout this process, the gateway captures metrics without
+exposing underlying provider credentials.
 
-Every control is opt-in. An app whose policy chain is empty proxies requests
-immediately—each request names its own model, and no model restrictions,
-budgets, guardrails, or caching apply until you add the policies that enforce
-them.
+Every app-specific control is opt-in. An app whose policy chain is empty runs no
+app-selected controls: each request names its own model, and no app-specific
+model restrictions, budgets, guardrails, or caching apply. Gateway and team
+usage limits still apply.
 
 ## Core Features
 
@@ -90,9 +91,9 @@ runs, so gateway changes go through your normal review workflow. See
 ### Per-App Policy Chains
 
 Each app runs its own ordered chain of policies—model filtering, fallback
-models, budgets, semantic caching, guardrails, tracing, and any custom policies
-declared in the repository. Team policy templates give new apps a consistent
-starting pipeline. See [Policy Chains](./policy-chains.mdx) and
+models, app-specific budgets, semantic caching, guardrails, tracing, and any
+custom policies declared in the repository. Team policy templates give new apps
+a consistent starting pipeline. See [Policy Chains](./policy-chains.mdx) and
 [Custom Policies](./custom-policies.mdx).
 
 ### Team Hierarchy & Budgets
@@ -113,8 +114,8 @@ Each app gets its own:
 
 - **Unique Gateway URL**: Single endpoint regardless of underlying provider
 - **API Key**: Zuplo-managed key that never exposes provider credentials
-- **Policy Chain**: Model access, budgets, caching, guardrails, and custom
-  policies, applied in the order the app chooses
+- **Policy Chain**: Model access, app-specific budgets, caching, guardrails, and
+  custom policies, applied in the order the app chooses
 
 ### Zuplo accounts and projects
 

package/docs/ai-gateway/managing-apps.mdx

@@ -2,8 +2,8 @@
 title: Managing Apps
 description:
   Create, edit, and delete AI Gateway apps. Apps are created with just a name
-  and a team; models, budgets, and other behavior live on the app's policy
-  chain.
+  and a team; models, app-specific budgets, and other behavior live on the app's
+  policy chain.
 ---
 
 An app represents one caller of your AI Gateway—a service, an agent, or a
@@ -47,7 +47,8 @@ permission to view the Zuplo project that contains the AI Gateway.
 That's the whole dialog. The portal then takes you to the app's **Policies**
 tab. If the app's team defines a [policy template](./policy-templates.mdx), the
 new app starts with that chain; otherwise the chain is empty and the app is
-unrestricted until you add policies.
+subject to no app-specific controls until you add policies. Team and gateway
+usage limits still apply.
 
 ## Restricting models
 
@@ -86,16 +87,17 @@ over—see [Dynamic model routing](./cookbooks/dynamic-model-routing.mdx).
 
 App budgets live on the **Budgets and Costs** policy in the app's chain. Open
 the app's **Policies** tab and configure it with daily or monthly limits for
-spending, tokens, or requests. If you don't set app limits, the team's and
-gateway's limits still apply. See [Usage Limits](./usage-limits.mdx).
+spending, tokens, or requests. Team and gateway limits apply to every app
+automatically, even when the app's chain doesn't include Budgets and Costs. See
+[Usage Limits](./usage-limits.mdx).
 
 ## Editing an App
 
 To edit an app, open the
 [Apps & Teams](https://portal.zuplo.com/+/account/project/ai/apps) tab of your
 AI Gateway project in the Zuplo Portal. Select the app you want to edit. The
-app's behavior—models, budgets, caching, guardrails—is edited on the
-**Policies** tab; the app's name lives on the **Settings** tab. Make your
+app's behavior—models, app-specific budgets, caching, guardrails—is edited on
+the **Policies** tab; the app's name lives on the **Settings** tab. Make your
 changes and click the **Save** button. Policy chain changes apply within about a
 minute.
 

package/docs/ai-gateway/policy-chains.mdx

@@ -8,9 +8,9 @@ description:
 ---
 
 Every request to an AI Gateway app runs down through the app's **policy chain**:
-an ordered list of policies that control model access, budgets, caching,
-guardrails, and tracing for that app. Different apps on the same gateway can run
-completely different chains.
+an ordered list of policies that control model access, app-specific budgets,
+caching, guardrails, and tracing for that app. Different apps on the same
+gateway can run completely different chains.
 
 The chain works in two layers:
 
@@ -24,8 +24,9 @@ The chain works in two layers:
   portal. Chain changes apply within about a minute, with no deploy.
 
 No policy is required. An app whose chain is empty still serves requests: each
-request names its own model, and no model restrictions, budgets, guardrails, or
-caching apply. Every control is something you add.
+request names its own model, and no app-specific model restrictions, budgets,
+guardrails, or caching apply. Team and gateway usage limits apply regardless of
+the app's policy chain.
 
 A request passes through whatever the app selected before the AI Gateway handler
 calls the provider:
@@ -105,14 +106,19 @@ Model Filtering → Fallback Model → Budgets and Costs → Semantic Cache
   never creates one. A chain with Fallback Model but no Model Filtering does
   nothing at all—the policy logs a warning and passes the request through
   unchanged. That's also why a fallback can never bypass the filter.
-- **Budgets and Costs** third: it needs the resolved selection so an exceeded
-  budget can activate the quota fallback.
+- **Budgets and Costs** third: it configures the app's own limits and needs the
+  resolved selection so an exceeded app limit can activate the quota fallback.
 - **Semantic Cache** after Budgets and Costs: cache hits still count toward
   request limits.
 
 Tracing policies work well at the end of the chain, so traces reflect the
 request the earlier policies produced.
 
+Team and gateway limits are enforced outside the app's policy chain. When one is
+exceeded, the app's quota fallback works whether or not its chain includes
+Budgets and Costs, as long as Model Filtering and Fallback Model supply a
+fallback selection.
+
 ## Built-in policies
 
 See the [policies overview](./policies/overview.mdx) for every policy an app can

package/docs/ai-gateway/policy-templates.mdx

@@ -8,9 +8,10 @@ description:
 ---
 
 A team's **policy template** is the policy chain that apps created in that team
-start with. Use templates to make sure every app in a team begins with your
-required policies—Budgets and Costs with a sensible budget, a guardrail, your
-custom compliance policy—while controlling what individual apps may change.
+start with. Use templates to give every app in a team the same app-specific
+controls—such as Model Filtering, Budgets and Costs with an app budget, a
+guardrail, or a custom compliance policy—while controlling what individual apps
+may change. Team and gateway limits don't depend on the template.
 
 ## How templates apply
 

package/docs/ai-gateway/usage-limits.mdx

@@ -83,22 +83,20 @@ requests to that model instead of blocking with a `429`—see
 [Fallback Models](./fallback.mdx). The fallback's usage still counts toward the
 limits.
 
-:::warning
+:::note{title="App, team, and gateway limits are configured separately"}
 
-An app without the Budgets and Costs policy in its chain doesn't enforce
-app-level limits. Team and gateway limits still protect overall spend, but
-per-app budgets need Budgets and Costs in the chain—use a
-[policy template](./policy-templates.mdx) to make sure every app starts with it.
+The Budgets and Costs policy configures and enforces an app's own limits. Team
+and gateway limits apply to every app automatically, whether or not the app's
+policy chain includes Budgets and Costs.
 
 :::
 
 :::caution{title="Budgets fail open by default"}
 
-The Budgets and Costs policy's `throwOnFailure` option defaults to `false`, so
-if the metering service is unavailable the request proceeds unmetered: no limit
-is checked and the request reaches the provider even if the app is already over
-budget. Set `throwOnFailure` to `true` to fail closed instead, so a metering
-outage rejects the request rather than letting it escape the budget.
+The Budgets and Costs policy's `throwOnFailure` option controls how an error
+while checking the app's own limits is handled. It defaults to `false`, so the
+request continues through the gateway. Set it to `true` to reject the request
+instead. Team and gateway limit checks run independently of this policy.
 
 :::
 

package/docs/policies/_index.md

@@ -5,10 +5,10 @@
 | set-query-params-inbound | Add or Set Query Parameters | Adds or sets query parameters on the incoming request. | api-gateway |
 | set-headers-inbound | Add or Set Request Headers | Adds or sets headers on the incoming request. | api-gateway |
 | ai-gateway-auth-v2-inbound | AI Gateway Authentication | Authenticates requests to an AI Gateway endpoint with application API keys.  Add this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header.  When the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires `configuration.id === request.params.app_id` and returns 403 on mismatch. | ai-gateway |
-| ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already) and runs the inbound policy chain from that configuration.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
+| ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already), runs the inbound policy chain from that configuration, and enforces limits inherited from parent teams or the gateway root.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
 | ai-gateway-configuration-loader-v2-inbound | AI Gateway Configuration Loader | Loads the AI Gateway app configuration for the request into the request-scoped channel and does nothing else.  Place this policy on AI Gateway routes before `ai-gateway-configuration-executor-v2-inbound` when you want configuration loading separated from chain execution. When `ai-gateway-auth-v2-inbound` already populated the channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter.  If this policy is omitted, the configuration executor still loads configuration itself before running the application chain. | ai-gateway |
 | ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering. It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |
-| ai-gateway-metering-v2-inbound | AI Gateway Metering | Meters AI Gateway usage and enforces app and ancestor usage limits.  Limits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
+| ai-gateway-metering-v2-inbound | AI Gateway Metering | Meters AI Gateway usage and enforces limits configured by the application.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
 | ai-gateway-model-filtering-v2-inbound | AI Gateway Model Filtering | Matches AI Gateway requests against curated allow lists or open block lists, then stores the winning model reference for the route handler. | ai-gateway |
 | ai-gateway-semantic-cache-v2-inbound | AI Gateway Semantic Cache | AI Gateway Semantic Cache policy. This inbound policy looks up the semantic cache on entry and, on a miss, registers a response-sending hook to write the upstream response back into the cache.  Caching parameters (semanticTolerance, expirationSecondsTtl, namespace, recentMessageCount) come from the policy options, and presence in the route's chain is what enables it. An id from the authenticated app configuration always provides the cache namespace so application-supplied options cannot cross tenant partitions. The cache key covers the system prompt plus the last `recentMessageCount` messages (default 1) — applied when storing and when matching — so multi-turn conversations can hit entries cached from earlier, shorter ones.  Cache outcomes are reported on the response via the RFC 9211 `Cache-Status` header under the cache name `zp-aigw-sem-cache` (hit: `zp-aigw-sem-cache; hit; detail="similarity=0.93"`; miss: `zp-aigw-sem-cache; fwd=miss; stored`). Responses also include the `x-ai-gateway-cache: HIT\|MISS` and `x-ai-gateway-cache-similarity` headers. | ai-gateway |
 | akamai-ai-firewall-v2-inbound | Akamai AI Firewall | Akamai AI Firewall Inbound Policy | ai-gateway |

package/docs/policies/ai-gateway-configuration-executor-v2-inbound/schema.json

@@ -12,7 +12,7 @@
   "requiresAI": true,
   "policyType": "ai-gateway-configuration-executor-v2",
   "products": ["ai-gateway"],
-  "description": "Loads the app configuration for the request (when auth or the configuration loader has not already) and runs the inbound policy chain from that configuration.\n\nPlace this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration.",
+  "description": "Loads the app configuration for the request (when auth or the configuration loader has not already), runs the inbound policy chain from that configuration, and enforces limits inherited from parent teams or the gateway root.\n\nPlace this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {

package/docs/policies/ai-gateway-metering-v2-inbound/doc.md

@@ -1,9 +1,9 @@
 # AI Gateway Metering
 
-AI Gateway Metering records application usage and enforces budgets before the
-provider request runs. It meters spend, tokens, and requests. Each meter has
-independent daily and monthly periods and an optional warning threshold that
-notifies without blocking.
+AI Gateway Metering records application usage and configures the app's own
+budgets before the provider request runs. It meters spend, tokens, and requests.
+Each meter has independent daily and monthly periods and an optional warning
+threshold that notifies without blocking.
 
 When a limit is exceeded, the policy activates the model selection's
 `quotaFallback` when AI Gateway Fallback Model supplied one. Otherwise it
@@ -52,16 +52,16 @@ The supported meters are `costs`, `tokens`, and `requests`. Each meter can have
 
 ## Team limits
 
-Limits configured on a parent team or the bucket root are enforced automatically
-through a server-side hierarchical check against aggregated usage. The
-`options.limits` settings govern only the app running this policy; the server
-walks the ancestor chain and reports the first exceeded limit.
+The `options.limits` settings govern only the app running this policy. Limits
+configured on a parent team or the gateway root are enforced centrally after the
+application's policy chain, whether or not this policy appears in that chain. An
+inherited limit activates the selected model's quota fallback when available and
+otherwise returns `429 Too Many Requests`.
 
-An exceeded team or gateway limit follows the same configured model-fallback or
-429 response path as an app limit. Ancestor enforcement cannot be disabled from
-the app's policy-chain entry. When the hierarchical check is unavailable,
-`throwOnFailure` controls the behavior: the default skips enforcement for that
-request while continuing to meter it, and `true` fails the request.
+An application cannot disable inherited enforcement through its policy chain. If
+the central hierarchical check is unavailable, the request proceeds. The
+policy's `throwOnFailure` option controls failures while checking or recording
+the app's own limits; it does not change inherited-limit behavior.
 
 ## Set limits from custom code
 

package/docs/policies/ai-gateway-metering-v2-inbound/schema.json

@@ -12,7 +12,7 @@
   "requiresAI": true,
   "policyType": "ai-gateway-metering-v2",
   "products": ["ai-gateway"],
-  "description": "Meters AI Gateway usage and enforces app and ancestor usage limits.\n\nLimits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.\n\nThe authentication policy must run before this policy so the app configuration id is available for meter storage and analytics.",
+  "description": "Meters AI Gateway usage and enforces limits configured by the application.\n\nThe authentication policy must run before this policy so the app configuration id is available for meter storage and analytics.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.3.2",
+  "version": "7.4.1",
   "type": "module",
   "description": "The programmable API Gateway",
   "author": "Zuplo, Inc.",
@@ -19,9 +19,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.3.2",
-    "@zuplo/core": "7.3.2",
-    "@zuplo/runtime": "7.3.2",
-    "@zuplo/test": "7.3.2"
+    "@zuplo/cli": "7.4.1",
+    "@zuplo/core": "7.4.1",
+    "@zuplo/runtime": "7.4.1",
+    "@zuplo/test": "7.4.1"
   }
 }