@aglyn/aglyn 1.0.0-beta.219 → 1.0.0-beta.220

package/src/lib/app-utils/plan-entitlements.d.ts

@@ -930,6 +930,75 @@ export declare const INFRA_COGS_PER_SITE_USD = 2;
  * The console keeps importing it from `usage-metering` unchanged.
  */
 export declare const METERED_MARKUP = 1.3;
+/**
+ * What the CDN requests behind ONE page view cost once the platform is past
+ * its hosting plan's included request allowance, at the DEAREST region the
+ * CDN bills, in USD per view (AGL-1879, AGL-3444). A page view billed past a
+ * plan's band is priced at `(perPageView + this) × METERED_MARKUP` — $0.70
+ * per 1,000 — and every `bandwidthGb` band is sized with it counted.
+ *
+ * ## Why a page view needs a second cost term
+ *
+ * `perPageView` prices what a view WEIGHS: the bytes it transfers at the
+ * CDN's per-GB rate, plus the Firestore reads behind the render. The CDN also
+ * charges per REQUEST once the team's monthly allowance is spent — Vercel Pro
+ * includes 10,000,000 a month, then bills $2.00 to $3.20 per million by
+ * region. A cold load of `aglyn.com/` makes 57 first-party requests to settle
+ * (`tools/tenant-page-budget.json`, `wireCalibration.measuredAgainst`), so the
+ * allowance is about 175,000 views of that page a month, platform-wide —
+ * about 169 GB of included bandwidth — where the 1 TB transfer allowance
+ * lasts about 1.4 million. The request allowance runs out first.
+ *
+ * ## Why the dearest region
+ *
+ * The CDN bills a request, and the bytes it transfers, in the region that
+ * SERVES it — the one nearest the visitor — so a site whose audience is in
+ * São Paulo or Cape Town costs what those regions cost, and nothing about a
+ * plan can choose otherwise. The platform's rule is that no plan is under
+ * water at any utilization and that "at cost + 30%" is true of every billed
+ * unit, so both terms of a page view are priced where the CDN is dearest:
+ * transfer at $0.35 per GB (in `perPageView`) and requests at $3.20 per
+ * million (here). Past the allowance a view then costs:
+ *
+ * |                                   | weight     | requests  | cost / 1k | margin at $0.70 |
+ * |-----------------------------------|------------|-----------|-----------|-----------------|
+ * | the page as measured (748.5 KB)   | $0.262148  | $0.182400 | $0.4445   | +36.5%          |
+ * | the priced basis (1012.8 KB)      | $0.354715  | $0.182400 | $0.5371   | +23.3%          |
+ *
+ * — at least 30% over cost in every region, which is the claim `/pricing`
+ * makes.
+ *
+ * ## The figure
+ *
+ * $0.00018374681 is 57.42 requests at $3.20 per million — the measured 57,
+ * with the basis set ABOVE the measurement as the weight basis is — pinned so
+ * the billed price lands on a whole cent: ($0.354715 + $0.1824) × 1.3 is
+ * $0.6982 per 1,000, rounded up to $0.70, and ($0.354715 + $0.183747) × 1.3
+ * is exactly $0.70. Published as "Our cost $0.538462 / You pay $0.70", the
+ * "at cost + 30%" claim stays true of the cost a billed view incurs in the
+ * dearest region, and so in every other.
+ *
+ * ## ⛔ Not in {@link ORG_COGS_UNIT_RATES_USD}, deliberately
+ *
+ * `perPageView` is half of a pair with `ESTIMATED_PAGE_TRANSFER_BYTES` — one
+ * page weight in dollars and in bytes — and `npm run check:page-view-rate`
+ * recovers that weight from the rate. A per-request charge is not
+ * proportional to weight, so folding it into `perPageView` would make the
+ * gate read a page nobody serves.
+ *
+ * ## The INCLUDED bands carry it too
+ *
+ * A view inside a plan's band makes the same requests as one past it, and
+ * once the platform is past the allowance the CDN bills them either way, so
+ * the `bandwidthGb` bands are sized with this term counted: $0.190 per
+ * included GB on top of $0.367 of weight. `tier-margin-floor.spec.ts`
+ * multiplies it in and pins every tier at 100% of every band.
+ *
+ * Lives HERE, beside the markup, for the reason the markup does: the
+ * `/pricing` generator publishes the cost column from it and cannot import
+ * anything under `apps/console`.
+ */
+export declare const PAGE_VIEW_CDN_REQUEST_COST_USD = 0.00018374681;
 /**
  * Monthly unit costs for the meters the rollup already records (AGL-1134).
  *
@@ -953,6 +1022,23 @@ export declare const METERED_MARKUP = 1.3;
  * infrastructure pass-through, and the customer is charged those figures
  * times `METERED_MARKUP`. They therefore appear in `METERED_UNIT_RATES_USD`
  * as well, with identical values, and must be changed in both places at once.
+ * A page view billed past its band also carries
+ * {@link PAGE_VIEW_CDN_REQUEST_COST_USD}, which neither table holds: it is
+ * the per-request CDN charge past the hosting plan's allowance, and this
+ * table's `perPageView` is the weight-proportional half of what a band is
+ * sized against — the request term is the other.
+ *
+ * ## Every Vercel-billed input is priced at Vercel's dearest region
+ *
+ * The CDN and functions bill by region, from $0.15 to $0.35 per GB of
+ * transfer, $2.00 to $3.20 per million requests, and $0.128 to $0.221 per
+ * hour of active CPU (memory $0.0106 to $0.0183 per GB-hour), and a plan
+ * cannot choose where its visitors are. So the Vercel share of every rate
+ * here is priced at the dearest region (AGL-3444): the transfer inside
+ * `perPageView`, the function invocation inside `perFormSubmission`, and the
+ * compute inside `perRun`. The GCP shares — object and Firestore storage, and
+ * the Firestore reads and writes behind a render, a submission or a run —
+ * are priced as they were.
  *
  * Everything else here is a cost-model input ONLY. `dataStoragePerGbMonth`,
  * `perApiRequest`, `perContactMonth` and `perEmailSend` price what an org
@@ -962,9 +1048,11 @@ export declare const METERED_MARKUP = 1.3;
  * "at cost + 30%" claim, which is true of exactly three meters.
  *
  * The first three were corrected 2026-08-09 (AGL-1280) — storage $0.03 →
- * $0.026 and form submissions $0.0005 → $0.00005 — and `perPageView` was
- * re-pegged 2026-09-09 (AGL-2711), from $0.0001 to $0.00016153846. All three
- * MUST be changed here and in `METERED_UNIT_RATES_USD` together. See that
+ * $0.026 and form submissions $0.0005 → $0.00005 — `perPageView` was
+ * re-pegged 2026-09-09 (AGL-2711), from $0.0001 to $0.00016153846, and the
+ * last two were re-priced at Vercel's dearest region on 2026-10-01
+ * (AGL-3444): page views $0.00035471473, form submissions $0.000053846154.
+ * All three MUST be changed here and in `METERED_UNIT_RATES_USD` together. See that
  * table for each figure's basis; it is the one a customer is billed against,
  * so it is the one that carries the working.
  *
@@ -985,8 +1073,8 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      * ⛔ HALF OF A PAIR — see ESTIMATED_PAGE_TRANSFER_BYTES, which states the
      * same page in bytes as this states it in dollars. Both are calibrated
      * against a 1012.8 KB page and neither may move alone: their quotient is
-     * the cost of a gigabyte, and that is what every bandwidthGb band on the
-     * ladder was sized against.
+     * the cost of a gigabyte's weight, and that — with the request term — is
+     * what every bandwidthGb band on the ladder is sized against.
      */
     perPageView: number;
     perFormSubmission: number;
@@ -1010,7 +1098,7 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      */
     perEmailSend: number;
     /**
-     * One workflow or action run — $12 per million.
+     * One workflow or action run — $13 per million.
      *
      * Derived from the run paths at list prices (2026-09-07), because nothing
      * measurable exists yet: runs execute inside the Vercel request that fired
@@ -1029,9 +1117,11 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      *   - writes: the activity row and the counter increment — 2, at $0.18 per
      *     100,000 = $0.0000036
      *   - compute: a few milliseconds of active CPU and memory on Fluid compute
-     *     for the expression evaluation, about $0.000001
+     *     for the expression evaluation, about $0.000001 in the cheapest
+     *     region and $0.0000017 in the dearest ($0.221 against $0.128 an
+     *     hour of active CPU), which is where it is priced
      *
-     * $0.0000118, carried as $0.000012. It scales with the catalog a site holds
+     * $0.0000125, carried as $0.000013. It scales with the catalog a site holds
      * — every `limit(100)` read above is a query that costs one read per
      * document returned — and a step that writes a dataset record or calls a
      * webhook adds to it, so this is the typical figure, not the ceiling.
@@ -1583,10 +1673,10 @@ export declare function checkHostRegisterQuota(org: Partial<AglynOrgBilling> | n
  */
 export declare function resolveTransactionFeePct(org: Partial<AglynOrgBilling> | null | undefined, productType: 'physical' | 'digital' | 'service'): number;
 /**
- * Stripe's processing cost on ONE storefront destination charge, in cents
- * (AGL-2152) — the dearest enabled method's percentage plus the fixed 30¢,
- * rounded UP on the percentage so the answer is never a cent short of what
- * Stripe actually debits.
+ * Stripe's processing cost on ONE destination-charge sale, in cents
+ * (AGL-2152) — a storefront order, a booking deposit — the dearest enabled
+ * method's percentage plus the fixed 30¢, rounded UP on the percentage so the
+ * answer is never a cent short of what Stripe actually debits.
  *
  * WHO PAYS THIS. Every storefront charge is a DESTINATION charge:
  * `payment_intent_data[transfer_data][destination]` names the merchant's
@@ -1612,18 +1702,18 @@ export declare function resolveTransactionFeePct(org: Partial<AglynOrgBilling> |
  * decides the set — and per AGL-2343 that configuration has `klarna` and
  * `affirm` on beside the card family. Pricing this at the card rate would be
  * wrong exactly on the orders where it cost the most, which is the same
- * reasoning `marketplaceBreakEvenUsd` already applies to the listing floor;
- * these are deliberately the SAME two constants so the two cannot drift.
+ * reasoning the marketplace listing floor applies; both are defined from the
+ * SAME processing constants so the two cannot drift.
  *
  * THE ONE-LINE LEVER. On a card-family order this over-recovers by the spread
  * between the two rates. Pinning `payment_method_types` on the storefront
  * sessions to the card family would make 2.9% the true binding rate, and
- * `STOREFRONT_PROCESSING_PERCENT` below is then the single identifier to
+ * `SALE_PROCESSING_PERCENT` below is then the single identifier to
  * repoint. That is a product decision about which payment methods a storefront
  * offers, not this one; it is recorded on AGL-2152 and in the Pricing Decision
  * Log so it can be taken deliberately.
  */
-export declare function storefrontProcessingCostCents(chargeCents: number): number;
+export declare function saleProcessingCostCents(chargeCents: number): number;
 /**
  * The Stripe Connect `application_fee_amount` for ONE storefront sale
  * (AGL-2152) — the platform's advertised take PLUS Stripe's processing cost,
@@ -1656,7 +1746,7 @@ export declare function resolveTransactionFeeCents(org: Partial<AglynOrgBilling>
  *
  * A Stripe Subscription accepts no `application_fee_amount` — only
  * `application_fee_percent`, a rate with at most two decimal places — so the
- * fixed 30¢ that `storefrontProcessingCostCents` adds in cents has to be
+ * fixed 30¢ that `saleProcessingCostCents` adds in cents has to be
  * folded into the rate. `(rate × amount + fixed) ÷ amount` is, with the
  * amount cancelled,
  *
@@ -1673,10 +1763,10 @@ export declare function resolveTransactionFeeCents(org: Partial<AglynOrgBilling>
  * decimal outright, so the only honest direction is over. Integers, because
  * `0.09 * 100` is not `9` in floating point and a percent one ulp above a
  * whole hundredth would round up to the next one. The same two constants as
- * the one-time path, so repointing `STOREFRONT_PROCESSING_PERCENT` moves
+ * the one-time path, so repointing `SALE_PROCESSING_PERCENT` moves
  * both surfaces together. Zero for a charge that is not a charge.
  */
-export declare function storefrontProcessingPassThroughPercent(amountCents: number): number;
+export declare function saleProcessingPassThroughPercent(amountCents: number): number;
 /**
  * The `application_fee_percent` for ONE storefront subscription (AGL-2655):
  * the plan's advertised take PLUS Stripe's processing cost as a percent —
@@ -1723,163 +1813,45 @@ export declare function resolveMarketplaceFeePct(org: Partial<AglynOrgBilling> |
  */
 export declare function bindingMarketplaceFeePct(): number;
 /**
- * What one marketplace sale costs the PLATFORM to process (AGL-2343).
- *
- * NONE OF THESE IS AN AGLYN PRICE. They are Stripe's published US rates and
- * the Texas rate the platform remits, and they exist only as inputs to a
- * figure shown to a publisher while they type. Nothing is billed from them —
- * the charged amounts are `resolveMarketplaceFeePct` and Stripe's own
- * invoicing — so changing one changes a sentence, never a bill.
+ * What one destination-charge sale costs the PLATFORM to process (AGL-2343):
+ * a storefront order, a booking deposit, a marketplace listing. On a
+ * destination charge Stripe debits its fee from the PLATFORM's balance, so
+ * every surface that sells through the platform's account prices its take
+ * against these.
  *
- * WHY THE PLATFORM PAYS THE PROCESSING FEE AT ALL. Marketplace checkout is a
- * DESTINATION charge with a fixed `transfer_data[amount]` and deliberately no
- * `application_fee_amount`, so that the sales tax stays with the platform that
- * owes it (AGL-1544). On a destination charge Stripe debits its fee from the
- * PLATFORM's balance, and it is charged on `amount_total` — the listing price
- * plus the tax added on top of it.
- *
- * So a $1 listing at a 20% take rate is a loss: the buyer pays $1.08, the
- * seller is transferred $0.80, $0.08 is owed to the state, Aglyn keeps $0.20
- * and pays Stripe about $0.33. Net −$0.13.
+ * NONE OF THESE IS AN AGLYN PRICE. They are Stripe's published US rates, and
+ * they exist only as inputs to a platform take and to figures a seller reads;
+ * changing one never changes a price list.
  *
  * THE BNPL RATE IS THE ONE THAT BINDS, and it is not hypothetical: the live
  * default payment method configuration has `klarna` and `affirm` enabled
- * alongside `card`, `cashapp`, `link`, `amazon_pay` and `apple_pay`, and the
- * marketplace session pins no `payment_method_types`, so a buyer may pay by
- * either. Break-even is computed from the dearest enabled method, because a
- * figure computed from the cheapest would be wrong exactly when it mattered.
- * IF BNPL IS EVER TURNED OFF FOR MARKETPLACE SESSIONS, this constant is what
- * has to move with it.
- */
-export declare const MARKETPLACE_PROCESSING_PERCENT_CARD = 2.9;
+ * alongside `card`, `cashapp`, `link`, `amazon_pay` and `apple_pay`, and no
+ * checkout session pins `payment_method_types`, so a buyer may pay by either.
+ * A cost computed from the cheapest method would be wrong exactly when it
+ * mattered.
+ */
+export declare const CARD_PROCESSING_PERCENT = 2.9;
 /** Klarna/Affirm, roughly. See the note above — this is the binding one. */
-export declare const MARKETPLACE_PROCESSING_PERCENT_BNPL = 6;
+export declare const BNPL_PROCESSING_PERCENT = 6;
 /** Stripe's per-transaction fixed component, in cents. */
-export declare const MARKETPLACE_PROCESSING_FIXED_CENTS = 30;
-/**
- * The tax rate the break-even figure assumes. Tax is added ON TOP of the
- * listing price and enlarges the base Stripe charges its percentage against,
- * so it makes the platform's cost slightly worse; the real rate is whatever
- * `automatic_tax` computes for the buyer's address, and this is the
- * platform's own Texas rate as a representative figure.
- */
-export declare const MARKETPLACE_ASSUMED_TAX_PERCENT = 8.25;
-/**
- * The processing rate a STOREFRONT destination charge is priced against
- * (AGL-2152), and the one identifier to repoint if the storefront's payment
- * method set changes.
- *
- * Deliberately its OWN name rather than a direct use of the marketplace
- * constants, while being defined as one of them: the two surfaces share
- * Stripe's published rates and today share the platform's payment method
- * configuration, but they are separate product decisions. A future choice to
- * pin `payment_method_types` on storefront sessions to the card family — and
- * so to recover at `MARKETPLACE_PROCESSING_PERCENT_CARD` — must not silently
- * lower the marketplace listing floor, which is derived from the same figure
- * for a different flow.
- */
-export declare const STOREFRONT_PROCESSING_PERCENT = 6;
+export declare const PROCESSING_FIXED_CENTS = 30;
+/**
+ * The processing rate a storefront or booking destination charge is priced
+ * against (AGL-2152), and the one identifier to repoint if those sessions'
+ * payment method set changes.
+ *
+ * Deliberately its OWN name rather than a direct use of the binding rate,
+ * while being defined as it: every seller shares Stripe's published rates and
+ * today shares the platform's payment method configuration, but each surface
+ * is a separate product decision. A future choice to pin
+ * `payment_method_types` on storefront sessions to the card family — and so
+ * to recover at `CARD_PROCESSING_PERCENT` — must not silently lower the
+ * marketplace listing floor, which is derived from the binding rate for a
+ * different flow.
+ */
+export declare const SALE_PROCESSING_PERCENT = 6;
 /** Stripe's per-transaction fixed component, in cents. Not rate-dependent. */
-export declare const STOREFRONT_PROCESSING_FIXED_CENTS = 30;
-/** Where the money goes on one sale of a paid listing (AGL-2343). */
-export interface MarketplaceSaleEconomics {
-    /** The listing price. */
-    priceCents: number;
-    /** Added on top, and owed to the state. */
-    taxCents: number;
-    /** What the buyer is charged. */
-    buyerPaysCents: number;
-    /** `transfer_data[amount]` — the seller's share of the pre-tax price. */
-    sellerReceivesCents: number;
-    /** The platform's take. */
-    platformFeeCents: number;
-    /** Stripe's fee, debited from the platform on a destination charge. */
-    processingCents: number;
-    /** `platformFeeCents - processingCents`. Negative is a loss on the sale. */
-    platformNetCents: number;
-}
-/**
- * The funds flow for one sale, mirroring what `checkout.ts` actually builds
- * (AGL-2343): tax exclusive and on top, a fixed transfer of the seller's share
- * of the PRE-tax price, and Stripe's fee charged on the buyer's total.
- */
-export declare function marketplaceSaleEconomics(priceUsd: number, feePercent: number, processingPercent?: number): MarketplaceSaleEconomics;
-/**
- * The cheapest WHOLE-DOLLAR price at which the platform does not lose money on
- * a sale (AGL-2343).
- *
- * Whole dollars because every publish route rounds `priceUsd` to one, so a
- * fractional break-even is not a price anyone can actually set. Searched
- * rather than solved algebraically so that it can never disagree with
- * `marketplaceSaleEconomics` — the rounding in there is what decides the
- * answer at these amounts, and a closed form would drift from it silently.
- *
- * THIS IS THE ENFORCED FLOOR: `marketplaceMinPriceUsd` returns this figure
- * and every publish door refuses a paid listing under it. Recorded in the Pricing
- * Decision Log and on AGL-2343.
- */
-export declare function marketplaceBreakEvenUsd(feePercent?: number, processingPercent?: number): number;
-/**
- * THE MINIMUM PRICE a paid marketplace listing may carry (AGL-2343).
- *
- * The floor is not a chosen round number — it is the break-even price itself,
- * the
- * cheapest whole dollar at which `marketplaceSaleEconomics` stops returning a
- * negative platform net, computed at the take rate that breaks even LATEST and
- * the dearest payment method the live configuration enables. Today that is $3.
- *
- * DERIVED, NEVER RESTATED. A second hand-written copy of this number in a
- * publish route or a form is the artifact that decays into a route refusing a
- * price a form invited, so both the server-side validator
- * (`MARKETPLACE_MIN_PRICE_USD` in the marketplace model) and every price field
- * read this. If the payment method set changes, or the plan table's lowest
- * take rate moves, the floor moves with them on the next call.
- *
- * ZERO IS NOT BELOW THE FLOOR. A free listing takes no payment at all, so it
- * costs nothing to process; the floor is a minimum on PAID listings only.
- */
-export declare function marketplaceMinPriceUsd(): number;
-/**
- * Whether a price is a PAID price that the floor refuses (AGL-2343) — the one
- * predicate a form uses to mark its price field in error and hold its publish
- * button, so that the button and the server agree about what is publishable.
- *
- * Rounds first because every publish route does, and a form's value is a
- * string mid-type: `'2.6'` is stored as $3 and must read as allowed here, or
- * the button would refuse a price the route accepts.
- */
-export declare function isBelowMarketplacePriceFloor(priceUsd: unknown): boolean;
-/**
- * The sentence a publish form shows under its price field when the price is
- * below the floor (AGL-2343), or `undefined` when there is nothing to say.
- *
- * NOT ADVISORY ANY MORE. The same figure is enforced by every publish route
- * through `publishPreconditionRefusal`, so this text has to read as a
- * requirement rather than a warning — a publisher who is told "consider
- * raising it" and then refused has been lied to by the form. It still explains
- * WHY, because a bare minimum with no arithmetic behind it reads as an
- * arbitrary tax on cheap listings.
- *
- * Shared by every publish form rather than written into each, because the
- * figure has to be the same one in all of them and the wording is the only
- * place a publisher ever sees it.
- *
- * Quoted at the take rate that breaks even LATEST, so the sentence holds for a
- * free-plan publisher too.
- */
-export declare function marketplacePriceCostNote(priceUsd: unknown): string | undefined;
-/**
- * The standing helper sentence a price field shows when there is nothing wrong
- * (AGL-2343): the minimum stated up front, so a publisher meets it while
- * typing instead of discovering it as a refusal.
- *
- * A capability that is not surfaced in the console does not count as shipped,
- * and that applies to a REFUSAL as much as to a feature: a floor only a route
- * knows about is a trap.
- *
- * @param suffix whatever else that particular form needs to say, appended.
- */
-export declare function marketplacePriceFloorHint(suffix?: string): string;
+export declare const SALE_PROCESSING_FIXED_CENTS = 30;
 /**
  * The cheapest plan whose BASE features include `feature`, in ladder order —
  * the answer to "which plan do I need for this?", which is the one thing an
@@ -1938,6 +1910,15 @@ export { PLATFORM_BRANDING_PROFILE } from './platform-brand';
  * entitlement the stored profile is ignored entirely and the full Aglyn
  * brand is returned — so an org that white-labeled and then downgraded
  * reverts cleanly.
+ *
+ * An org WITH the entitlement that has stored no brand value at all gets the
+ * full Aglyn brand too (AGL-3440). The entitlement is the right to a brand,
+ * not a brand: until the org sets one, every name it shows is the platform's
+ * anyway, so the white-label profile's blanks — no logo, no support link, no
+ * home — conceal nothing and only strip the platform's own header and footer
+ * from mail whose every line already names the platform. Every Enterprise
+ * org carries the entitlement, Aglyn's own included. One field set, and the
+ * rules below apply.
  */
 export declare function resolveBrandingProfile(org: Partial<AglynOrgBilling> | null | undefined): ResolvedBrandingProfile;
 /**
@@ -2450,7 +2431,9 @@ export declare function checkFormSubmissionAbuseCeiling(org: Partial<AglynOrgBil
  * view costs. They are one physical measurement written in two units, and
  * what every `bandwidthGb` band is actually sized against is neither of them
  * alone but their quotient — `(1 GB ÷ this) × perPageView`, the cost of a
- * gigabyte. That quotient is stable even while the page's weight is not,
+ * gigabyte's WEIGHT, to which the band sizing adds the CDN requests the same
+ * views make ({@link PAGE_VIEW_CDN_REQUEST_COST_USD}). That quotient is
+ * stable even while the page's weight is not,
  * which is precisely why moving one half re-prices every band on the ladder
  * without touching a band: a heavier page costs more per view and buys fewer
  * views per gigabyte, and the two cancel.
@@ -2498,11 +2481,13 @@ export declare function bandwidthGbFromPageViews(pageViews: number): number;
  * It is a CAP, not a price, and it is lower than {@link
  * FORM_ABUSE_CEILING_MULTIPLE} because bandwidth is the largest cost line the
  * platform carries and the one a stranger can spend on the customer's behalf.
- * Past the band every 1,000 views bills $0.21 against about $0.16 of real
- * cost, so the tail is no longer a loss — but a scraper, a hotlinked asset or
- * a botnet still bills the account holder for traffic they did not ask for,
- * and the ceiling is what bounds that before staff look at it. At 10× the
- * band that tail was open-ended on Agency; at 3× it is bounded.
+ * Past the band every 1,000 views bills $0.70 against at most $0.54 of real
+ * cost — the dearest region's — once the CDN's request allowance is spent
+ * ({@link PAGE_VIEW_CDN_REQUEST_COST_USD}), so the tail is not a loss — but a
+ * scraper, a hotlinked asset or a botnet still bills the account holder for
+ * traffic they did not ask for, and the ceiling is what bounds that before
+ * staff look at it. At 10× the band that tail was open-ended on Agency; at 3×
+ * it is bounded.
  */
 export declare const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
 /**
@@ -2513,9 +2498,10 @@ export declare const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
  * Free includes 2 GB ≈ 2,071 views; 3× would be ~6,212, which a genuinely
  * successful hobby site (a post that lands on Hacker News) reaches in an
  * afternoon and would be a miserable first experience of the platform.
- * 100,000 views/month ≈ 96.6 GB ≈ **$16 of real COGS** at
- * `METERED_UNIT_RATES_USD.perPageView` — well above the free band, and an
- * order of magnitude below the $162 a million views costs. It is the number
+ * 100,000 views/month ≈ 96.6 GB ≈ **$54 of real COGS** at the dearest
+ * region (`METERED_UNIT_RATES_USD.perPageView` plus
+ * `PAGE_VIEW_CDN_REQUEST_COST_USD`) — well above the free band, and an order
+ * of magnitude below the $538 a million views costs. It is the number
  * that makes "free stays free" true without making it stingy.
  */
 export declare const BANDWIDTH_ABUSE_CEILING_FLOOR = 100000;