Customer pricing

Open Admin → Pricing to manage customer selling prices. Published platform prices in the installation’s configured currency apply automatically to workspaces without an explicit legacy pricing selection. Ordinary customer onboarding does not require publishing or enrolling a price for each workspace. Customer selling prices are distinct from confidential Provider offers and procurement rates.

Publish a standard price

1. Select Publish text price or Publish media price for a registered model.
2. Inspect the current price and history before revising existing terms.
3. Enter the selling rates using the form’s declared billing units. Media prices apply only to their exact model and specification; never substitute a Provider purchase price.
4. Publish the change and confirm the saved revision. If publication is unconfirmed, recover the original submission before attempting another change.
5. Verify the customer’s applicable price, available funds, model access and supply readiness before testing a request.

Rates are versioned. New requests use the applicable platform price and eligible promotion; already admitted operations retain their original price. Price publication creates neither customer funds nor model access. Historical records retain their original currency. Explicit compatibility selections remain supported by the API and are not an onboarding requirement.

Pricing is not spending capacity

Company funds or approved credit, workspace spending caps and API-key caps are separate controls. A customer tariff determines a charge; it does not top up a balance or grant credit. Applicable reservations count toward supported spending limits before dispatch.

Missing usage or unresolved customer pricing must stay explicit. Do not label an unknown charge as free or replace it with an upstream expense. Read usage and billing and the generated customer tariff operations for the contract.

Video/media rate schedules are separate from text token tariffs. Qualify the concrete model and meter before promising a video price or settled charge.

Platform standard prices and finite promotions

Admin → Pricing lists the current text and media standard prices and opens immutable Prices & history, including published promotion terms and retirement cutoffs. Existing media contracts provides company-scoped management of previously configured media rates; ordinary customer onboarding requires no workspace pricing setup. Publish text price creates a text standard; Revise standard edits an existing text identity using its displayed management version. The form includes every text category, request fee, minimum and context tier. Enter a reason; blank optional categories use ordinary pricing and explicit zero remains a rate. A definitive rejection requires closing and refreshing before another edit. An unconfirmed submission keeps the original input and key frozen for exact retry and cannot be dismissed through the form; do not reload or leave the page while recovering it. Recovery after browser reload is not yet supported by this form. Publish media price creates a media standard; Revise standard edits its selling terms while preserving the model, currency, dimensions and meter identity. Choose a registered media model and its available resolution and reference-video options, then enter the selling price and price-per quantity. The form derives the channel and meter from registered model specifications. Decimal scale and rounding are available in advanced calculation settings. Quantities accept decimals or fractions and are reduced before publication; amounts remain exact integer units at the declared scale. Model registration does not discover media capabilities or qualify supply. Media publication uses the same management-version/original-key recovery rules, and recovery after browser reload remains unsupported. Promotions → Publish promotion starts from the current original standard and management version returned together in the state snapshot. Prices & history → Promote this original price selects an older undiscounted revision while retaining the latest displayed management version. Choose All customers or a named company, finite start/end times and explicit result rates. Creation time distinguishes repeated company names without displaying internal references; identical name/time pairs require a name change before selection. Text categories and context thresholds stay fixed, and every resulting rate/fee/minimum must not exceed its original value. Media promotions change only the amount; dimensions, meter, scale, quantities and rounding stay fixed. Times use the browser’s local timezone and publish as exact UTC seconds. Publication preserves the same original-key/form-local recovery rules. Promotions shows the named scope, observed temporal state, original revision, published period and any recorded cutoff. View terms compares complete original/result schedules. Set cutoff shortens future eligibility for a scheduled or within-period publication that has no cutoff; the original end cannot be extended. A cutoff before the start cancels the scheduled period. Enter a reason and save, then confirm the refreshed state. Existing request prices remain unchanged. One cutoff is allowed per publication. Unconfirmed outcomes retain the original input/key for exact retry in the open form; reload recovery remains unsupported. History events alone do not establish current promotion eligibility, especially when older pages have not been loaded.

Discover aliases through listRegisteredRetailModels or NiuAdminClient.listRegisteredRetailModels. This platform-only, paged metadata read includes registered shared vendor aliases and route pools even when disabled, and excludes personal vendor aliases. Registration permits price preparation; it does not establish qualified supply, selling eligibility or dispatch readiness. The existing listPlatformPricingModels endpoint remains the current available-model read for workspace tariff publication. Neither endpoint supplies a media meter, schema or qualified liability bound.

Use the standard publication API or NiuAdminClient.publishRetailStandard to publish selling terms by model alias, currency and text/media identity. These are customer prices; they contain no Provider purchase quote or route credential. Exact monetary values are decimal strings. Text schedules include every category, context tier, minimum and request fee. Media schedules use a declared meter, dimensions, units and rounding; route and liability qualification remain separate.

A new identity uses expected_version: '0'. Subsequent changes use the latest management version. Keep the UUID idempotency key for an exact retry after an uncertain result. The returned version is the original publication’s version, so refresh current configuration before the next edit. List standard prices and inspect immutable history rather than overwriting a stale version.

Choose a named company through listRetailCustomerTargets or NiuAdminClient.listRetailCustomerTargets. This platform-only paged directory includes companies without workspaces or currency accounts and returns creation time for distinguishing repeated names, with no balance or payment details. Use the company reference only in API input, never as a display label. Company discovery does not create an account, enroll a workspace or authorize spending.

Publish a finite promotion as an explicit resulting schedule referencing the exact original standard revision. Explicit customer_organization_id: null means global; a company reference means customer-specific. Start is inclusive, end is exclusive, and both are exact UTC epoch-second strings. Customer rules override global rules without stacking. Same-scope overlapping periods conflict. Discounts preserve token categories/context thresholds or media dimensions/meter/units and cannot increase the supported rates. A later standard revision does not silently cancel already published promotion terms.

Read listRetailPromotions or NiuAdminClient.listRetailPromotions for a bounded status page with full cutoff coverage. Each returned promotion joins its original standard and committed retirement even if the retirement event is outside a history page. The database as_of is UTC epoch seconds. scheduled, within_period and ended describe only the published period after its cutoff: a global rule can still be overridden by a customer rule, and temporal eligibility does not establish enrollment, supply or permission to spend. The current standard and management version are returned together as standard in that snapshot, including after a cutoff changes the version. Each page has its own observation time and snapshot. Pass next_before unchanged; its version identifies a promotion, not an arbitrary history event.

Retirement appends an explicit eligibility cutoff and retains the original rule. Expiry or retirement changes future selection; it must not reprice an existing operation or asynchronous job. The platform preview is advice only, not a spending authorization or settlement snapshot.

Text defaults and compatibility selections

With no explicit selection, a workspace uses the model’s published platform text price in the configured platform currency. No enrollment record is created. The existing workspace enrollment API remains available for explicit compatibility selections and requires platform administration. A selected price requires an existing billing account in its currency; the write creates neither funds nor credit. Explicit null retains legacy workspace pricing for future operations. It differs from an absent selection, which inherits the platform default. Already pinned operation prices remain intact.

Customers can read their own pricing mode and applicable selection without seeing other customers’ rules. Model discovery reports the customer’s applicable selling price with its source; discovery remains advisory until admission binds a concrete immutable revision. Publication, enrollment and a visible price do not establish qualified supply, successful generation or complete billing.

The registry/API/SDK configuration workflow is implemented. The standard-price dashboard forms, current-input text materialization/settlement acceptance and atomic video integration remain pending; continue to treat media qualification and actual job billing as separate acceptance work.

Route media liability evidence

Before a customer-funded video request can reserve funds, its maximum billable quantity must be explicitly qualified for the exact Provider offer, credential, model, schema, dimensions and meter. A video output estimate does not establish this maximum. The qualification carries its evidence revision and SHA-256 reference, finite UTC-second interval and immutable administrator attribution. It contains no purchase or customer selling price.

Platform administrators can publish and read this separate configuration through publishMediaLiabilityQualification, listMediaLiabilityQualifications and retireMediaLiabilityQualification in NiuAdminClient. Their REST paths are under /api/v1/providers/{supplier}/offers/{offer}/media-liability-bounds. Publication uses version comparison and an idempotency key; revocation shortens future eligibility and keeps history. Customers and Provider members cannot use these endpoints.

The registry and its configuration endpoints are implemented. Platform-priced video enrollment and atomic admission are implemented; this configuration alone does not establish a working commercial video flow. Existing jobs retain their original price and liability snapshots.

Media defaults and compatibility selections

Without an explicit selection, a workspace uses the published platform media price matching the configured currency and exact model, channel, resolution, reference-video choice and meter. A price for another specification is never substituted. NiuAdminClient.setRetailMediaEnrollment remains a compatibility API for explicit selections; the selected currency account must already exist. Explicit price_id: null retains legacy media-card selection for future operations instead of inheriting the default. Versions, idempotency keys, reasons and administrator attribution retain configuration history.

getRetailMediaEnrollment returns the caller’s own workspace configuration and advisory effective selling price. An eligible customer promotion takes precedence over an eligible global promotion without stacking; expiry falls back to the next applicable price. These reads contain no Provider procurement information or other customers’ rules. Configuration does not establish a video-capable route or authorization to spend. Platform-priced video admission reselects at database time and binds customer/Provider prices, qualified quantity, provenance and funds in one transaction. Existing saved jobs keep their original snapshots. Complete generation and settlement acceptance remains pending.

A known zero selling tariff uses an exact zero monetary reservation while retaining its qualified quantity and account bindings. It must not invent a positive charge or bypass route/key/account authorization. Later promotion expiry, retirement, standard replacement or workspace unenrollment does not reprice an admitted task. Route or quantity qualification that expires before dispatch blocks unsent egress; already dispatched jobs retain their original price and liability for recovery and settlement.

Provider comparison and net revenue

The commercial-position API keeps nominal charges, recorded balance-credit refunds, net consumed-gift allowance and net customer revenue separate. With complete coverage, charges minus refunds minus gift allowance equals net revenue. For 100 units of consumption, 5 consumed gifted units and no refunds, revenue is 95. This is the requested reporting rule, not a qualified live transaction example. Gifts are sales allowance when consumed, not operating expense.

Net contribution subtracts matching Provider earnings from that net revenue; upstream expense must not be subtracted a second time. Missing source allocation or unresolved charge coverage withholds full revenue. Legacy margin_nanos means nominal charge minus earnings and is retained for compatibility; it is not net income or profit. Recorded balance refunds do not prove an external cash transfer. Personal funding is excluded.

These rows use a dispatch cohort and include its recorded refunds. Use the financial posting summary for posting-period income, verified receipt records and gift issuance. Both endpoints accept either a rolling window (days of 7, 30 or 90) or explicit UTC calendar bounds (from and until RFC 3339 timestamps, up to 370 days). Neither measure alone proves cash profit. Currency rows remain separate; no foreign-exchange conversion is implied. Admin → Financial reports (/admin/reports) supports USD ($) and CNY (¥) and presents a unified financial statement across natural calendar periods (Month to date, Single calendar month, Multi-month range and Rolling window) with automatic prior-period comparison (Current, Prior period and Change in both currency and percentage) and Export PDF print support. The exported PDF renders with an institutional Niu letterhead (brand mark, PLATFORM FINANCIAL REPORTING header, document classification and reporting period/baseline/UTC window/currency control box), an unclipped 4-column executive KPI strip, full multi-page financial statement tables, accounting & attribution notes, and a running brand footer bar pinned to the bottom of the page. Financial statement figures (revenue, costs, payables, cash receipts, balances and deltas) are formatted to four decimal places (0.0000) with $ or ¥, while model unit prices (Agreed offer quote) preserve full significant decimal precision (up to nine decimal places):

• Executive KPI summary: Net recognized revenue, Cost of supply (Provider payable), Platform net contribution (with contribution margin percentage) and Verified cash receipts (with unused prepaid wallet cash).
• Statement of operations (P&L) & Cash receipts, payables & wallet position: Dual financial tables reconciling nominal consumption, recorded refunds, consumed gift allowance, net recognized revenue, Provider payable, net contribution, verified cash receipts, Provider settlement status and point-in-time wallet cash/credit provenance against the preceding comparable period.
• Unit economics by Provider & model: Defaults to Active in period (sorted by customer charges descending so active models appear first) with a toggle for All configured, separating nominal charges, refunds & gifts, net revenue, Provider payable, settled/outstanding liability, recorded upstream cost and net contribution. Unknown full amounts remain blank, with coverage gaps and known partial subtotals identified.

Commercial operation audit

Platform Audit logs include saved standard-price and promotion changes, workspace text/media enrollment, noncash grants and route media-liability qualifications. They use the existing Configuration and Provider categories and source-qualified pagination. Exact publication retries preserve the original event rather than adding an apparent new change.

This metadata projection shows the action, current target/actor names, recorded system actor, revision and timestamp. It does not expose monetary values, price schedules, balances, quantity limits, freeform reasons or credentials. Detailed protected configuration history remains in its own endpoint. These records do not establish a successful generation, settlement or historical audit completeness.

known_upstream_cost_subtotal_nanos adds all recorded upstream costs in the row currency, even when no same-currency customer charge or Provider earning matches. upstream_cost_recorded_attempts counts those records. This is a known partial subtotal, not proof of complete expense coverage. With no recorded cost the subtotal is null; currencies are never converted or combined. The legacy cost_nanos field retains its matched-charge coverage rule.

Cash and credit provenance

The financial summary includes balance_credit_sources, a current wallet snapshot at as_of, independent of the selected posting interval. It distinguishes unused verified cash from outstanding credit consumption. A verified recharge repays exact unpaid credit charges before its remaining amount becomes prepaid cash; repayment does not recognize income again. Refunds restore consumed gifts first, then cancel outstanding credit and restore paid cash. Restored wallet cash is not evidence of an external refund transfer.

Only future debits and refunds receive the new immutable cash/credit split. Historical missing sources, unclassified adjustments and ambiguous funding reversals leave full wallet source totals null. Known subtotals include only completely covered accounts; uncovered_accounts makes the gap explicit. This view excludes external invoice receivables and does not turn approved credit limits into funding. When issuing a new grant, application_policy defaults to future_only. Explicit unpaid_credit_first applies it to exact known unpaid credit charges before reserving the remainder for future consumption. Unknown account provenance rejects the whole publication. Original charge prices and Provider payable remain unchanged. The application is a sales allowance posting, not a second balance credit or a cash receipt. Its refund restoration is already part of the refund gift allocation and must not be counted again.

Cohort cash and unpaid credit

The commercial-position API distinguishes customer_cash_applied_nanos from net revenue: it attributes verified wallet cash and subsequent credit repayments to the original dispatched requests, less recorded cash balance restorations. customer_outstanding_credit_nanos is the remaining wallet credit after repayments, gift applications and credit refunds. It excludes external invoice receivables. These are current cumulative amounts for the selected dispatch cohort, not receipts posted in that interval; balance restorations do not prove an external refund transfer. Gifts never count as cash paid. Missing or ambiguous account provenance, missing refund sources or unresolved traffic withholds the full monetary amount. cash_source_uncovered_attempts identifies charged attempts with incomplete provenance. Admin → Financial statements displays these amounts alongside the uncovered cash request count.

Credit approvals require explicit platform administration. Each new HTTP approval records its authenticated actor and immutable policy revision atomically; Admin Audit API includes approval metadata without amounts. Earlier revisions remain unattributed. Approval changes capacity, never received funds or revenue. Warning-only preferences retain their separate customer-authorized path.

Use the platform-only customer account directory to discover named companies and their currency balances for credit and noncash gift administration. It includes companies with no accounts and never creates funds. Each page uses the same balance arithmetic as customer billing; platform permission remains separate from ordinary customer data access.

Customer account administration

Admin → Account balances displays posted balances, approved credit, outstanding request liability and available capacity by company and currency. Set credit previews the current and proposed limit, preserves the existing warning threshold and uses the displayed policy revision to prevent overwriting another approval. Zero requires prepayment. For a company with no accounts, the form uses the platform currency configured in Admin → Settings; there is no per-account currency choice. Creating a zero-balance account does not receive funds. Historical currency accounts retain their original currency; the dashboard does not convert amounts or let administrators grant credit in a different currency. An unconfirmed write requires closing the dialog and refreshing the account before another change. New approvals retain the authenticated audit record.

Account actions include Set credit, Grant noncash balance and Noncash grants. Enter a positive gift amount, a single-line reason and the application policy, then Prepare grant. Preparation saves the intent without adding funds; Issue noncash grant publishes the saved exact input. Noncash grants separates Issued gifts, including older direct API grants and their independent corrections, from Saved intents, which opens original issued allocations or prepared operations for resumption. Correct unused gift permits a full correction only on an account with no paid request history, consumption, refunds, open request reservations or unknown financial sources. Review the original gift, enter a reason and explicitly confirm removal. Corrections preserve original records and credit policy, and do not create cash refunds or revenue adjustments. Verified cash funding remains a separate operation and must have a real settled payment reference.

Recoverable noncash publication

Use prepareCustomerBalanceGrant before publication to save the amount, reason, currency, application policy and original idempotency key. Preparation adds no funds or revenue. Saved intent is available through its exact-key read and paged history after refreshing or changing browsers. Publish the saved exact input through grantCustomerBalance; changing a prepared amount, reason, currency or policy conflicts. Never choose another key because a publication response was lost. prepared means no matching grant in the read snapshot, not proof that a request still in flight failed. issued returns the original allocation, not current spendable balance. Nothing publishes automatically. Preparation and issuance have distinct authenticated audit records. The browser form rechecks saved state when resuming an intent. If an outcome is unconfirmed, use Check saved status or retry the same saved grant; do not create another grant to replace a missing response. Closing the dialog leaves prepared intent available in the backend list.

The posting summary reports corrected_unused_gifts_nanos separately from gross issued_gifts_nanos. Financial statements show each as its own noncash memorandum row. Correction is excluded from verified cash receipts, consumption refunds and recognized revenue. Platform Audit logs retain its administrator and named company/currency target.

Pricing checks before dispatch

Shared text routes require an explicit Provider cost bound and an applicable customer selling tariff. Missing configuration returns service_not_ready before upstream dispatch; a missing selling tariff rolls back admission without a reservation or charge. An explicitly configured zero price remains valid. Personal routes funded by the customer’s own API key retain their separate owner-funded behavior. Media admission continues to require its applicable customer and Provider rate-card snapshots and liability qualification.

Platform Customer pricing shows Price checks for standard prices, workspace tariffs and promotion schedules. Below Provider cost identifies lower input, output, cache read/write or reasoning unit rates, including context thresholds from either schedule. It is advisory: intentionally discounted prices can still be published. Fixed request fees, minimum charges and usage mix mean a lower unit rate is not proof that every request loses money. Standard-price checks do not replace checks of an applicable promotion or workspace tariff.

Matching media currencies, meters, dimensions, minimum quantities and rounding can be compared using exact rational unit prices. Provider discounts or incompatible/missing dimensions produce Comparison unavailable. No exchange rate, absent price or missing category is invented. No lower unit rates is not a supply-readiness or profitability guarantee. These comparisons use current Provider configuration and must be refreshed after edits; they do not authorize dispatch or reprice existing requests. Relative cost diagnostics, like purchase amounts, are restricted to platform administration.

Price changes during a request

The billing boundary is admission, not completion time. Customer selling prices and applicable Provider purchase terms are stored as immutable revisions bound to the admitted attempt. Settlement and delayed usage reconciliation use those bindings, even if a new price is published while generation is running. New operations admitted after publication select the newly applicable schedule.

Retries within an operation preserve its original customer selling revision; each selected upstream attempt binds its own Provider terms. A changed route or quote during admission must be revalidated or rejected before sending upstream, not silently mixed with an earlier bound. Asynchronous media jobs retain their saved customer and Provider pricing snapshots through recovery. Publishing, retiring or expiring a promotion does not retroactively change an admitted job.

Existing customer media contracts

Use Admin → Pricing → Existing media contracts to select a company and inspect, replace or end previously configured customer-specific media rates. Organization settings does not manage prices. Publish ordinary media prices with Publish media price so they apply across workspaces; historical jobs retain their admitted prices. If an eligible model is missing, open the Provider configuration remedy in its separate tab, then refresh model choices in the original price form.

打开管理后台 → 定价配置（Admin → Pricing）以管理客户销售价格。以安装实例所配置平台币种发布的平台标准价格，会自动应用于未显式选择旧版专属定价的工作空间。常规客户开通无需为每个工作空间单独发布或注册价格。客户销售价格与保密的模型供应商报价及采购费率相互独立。

发布标准价格

1. 为已注册的模型选择发布文本价格（Publish text price）或发布媒体价格（Publish media price）。
2. 在修订既有条款前，先检查当前价格与历史记录。
3. 使用表单声明的计费单位输入销售费率。媒体价格仅适用于其确切的模型与规格；切勿直接填入模型供应商的采购价格。
4. 发布更改并确认已保存的修订版本。如果发布结果尚未确认，请在尝试下一次更改前先恢复原始提交。
5. 在测试请求之前，先核实客户适用的价格、可用资金、模型访问权限以及供应就绪状态。

费率受版本控制。新请求使用适用的平台价格及符合条件的促销；已准入的操作保留其原始价格。发布价格既不会创建客户资金，也不会授予模型访问权限。历史记录保留其原始币种。API 仍支持显式的兼容性选择，但这并非客户开通的必需步骤。

定价不等于可用支出额度

公司资金或已批准的授信额度、工作空间支出限额以及 API 密钥限额属于彼此独立的控制机制。客户价目表仅决定如何计算费用，不会为余额充值或授予授信额度。在请求分发前，适用的额度预留会计入受支持的支出限额中。

缺失的用量或未决的客户定价必须保持明确标记。切勿将未知费用标记为免费，也不要用上游采购支出代替客户费用。有关具体契约，请阅读用量与计费以及自动生成的客户价目表操作。

视频/媒体费率表与文本 Token 价目表相互独立。在承诺视频价格或已结算费用之前，请先完成对具体模型与计量器（meter）的验证。

平台标准价格与限时促销

管理后台 → 定价配置（Admin → Pricing）会列出当前的文本和媒体标准价格，并可打开不可变的价格与历史记录（Prices & history），其中包括已发布的促销条款与提前终止截止时间（retirement cutoffs）。现有媒体合同（Existing media contracts）提供按公司范围管理先前已配置媒体费率的功能；常规客户开通无需配置工作空间专属定价。发布文本价格（Publish text price）用于创建文本标准价格；修订标准（Revise standard）使用当前显示的管理版本号编辑现有的文本价格身份。表单包含所有文本类别、请求费、最低消费及上下文阶梯。请输入修改原因；留空的可选类别将使用普通定价，而显式填写的零仍作为有效费率。如果提交被明确拒绝，需要先关闭并刷新后再进行下一次编辑。若提交结果处于未确认状态，表单会冻结原始输入和幂等键以供精确重试，且无法通过表单直接关闭；在恢复该状态期间，请勿重新加载或离开页面。当前表单尚不支持在浏览器刷新后恢复未确认提交。发布媒体价格（Publish media price）用于创建媒体标准价格；修订标准（Revise standard）可在保留模型、币种、维度与计量器身份的同时编辑其销售条款。请选择已注册的媒体模型及其可用的分辨率与参考视频选项，然后输入销售价格与计价单位数量。表单会根据已注册的模型规格自动推导通道与计量器。小数精度位与取整规则位于高级计算设置中。数量支持输入小数或分数，并会在发布前约分；金额则在声明的小数精度下保持为精确的整数单位。模型注册本身不会自动发现媒体能力或验证供应就绪状态。媒体价格发布遵循相同的管理版本号/原始幂等键恢复规则，且同样不支持浏览器刷新后的恢复。促销 → 发布促销（Promotions → Publish promotion）会基于状态快照中一同返回的当前原始标准价格及管理版本号发起创建。价格与历史记录 → 对此原始价格发起促销（Prices & history → Promote this original price）可选择较早的未打折修订版本，同时保留最新显示的管理版本号。选择“所有客户”（All customers）或指定名称的公司、有限的起止时间以及明确的结果费率。创建时间可用于区分重名的公司而无需显示内部标识符；若公司名称与创建时间均相同，需先更改名称后再做选择。文本类别和上下文阈值保持固定，且每个结果费率/手续费/最低收费均不得超过其原始值。媒体促销仅修改金额；维度、计量器、精度、数量与取整规则保持固定。时间使用浏览器的本地时区输入，并以精确的 UTC 秒数发布。发布操作同样保留原始幂等键与表单本地恢复规则。促销（Promotions）列表会显示命名的适用范围、观测到的时间状态、原始修订版本、已发布的有效期以及任何已记录的终止截止时间。查看条款（View terms）可对比完整的原始价目表与促销结果价目表。设置截止时间（Set cutoff）可为尚未设置截止时间的待生效（scheduled）或生效中（within-period）促销缩短未来的有效期限；原始结束时间无法延长。将截止时间设置在开始时间之前即可取消待生效的促销期。输入原因并保存，然后确认刷新后的状态。已有请求的价格保持不变。每次促销发布最多允许设置一次截止时间。未确认的结果会在打开的表单中保留原始输入与幂等键以供精确重试；刷新后恢复仍不受支持。仅凭历史事件列表本身不足以判断当前的促销适用资格，尤其是在尚未加载较早历史分页的情况下。

可通过 listRegisteredRetailModels 或 NiuAdminClient.listRegisteredRetailModels 发现模型别名。这一仅限平台调用的分页元数据读取接口包含已注册的共享供应商别名和路由池（即使处于禁用状态），但排除个人供应商别名。完成注册仅允许准备价格，并不代表已具备合格供应、销售资格或分发就绪状态。现有的 listPlatformPricingModels 端点仍然是发布工作空间价目表时用于读取当前可用模型的接口。这两个端点均不提供媒体计量器、Schema 或经验证的责任上限。

使用标准价格发布 API 或 NiuAdminClient.publishRetailStandard，按模型别名、币种以及文本/媒体身份发布销售条款。这些均为客户价格，不包含任何模型供应商采购报价或路由凭证。精确的货币数值使用十进制字符串表示。文本价目表包含所有类别、上下文阶梯、最低收费和请求费。媒体价目表使用声明的计量器、维度、单位和取整规则；路由与应付责任上限的验证仍然保持独立。

新价格身份使用 expected_version: '0'，后续修改则使用最新的管理版本号。请保留 UUID 幂等键，以便在结果不确定时执行精确重试。返回的版本号是原始发布的版本，因此在进行下一次编辑前请先刷新当前配置。请通过列出标准价格并检查不可变历史记录来确认状态，而不要直接覆盖过期的版本。

通过 listRetailCustomerTargets 或 NiuAdminClient.listRetailCustomerTargets 选择指定名称的公司。这一仅限平台调用的分页目录包含尚无工作空间或货币账户的公司，并返回创建时间以区分同名公司，且不包含余额或支付详情。请仅在 API 输入参数中使用公司引用标识，切勿将其作为界面显示标签。发现公司记录不会创建账户、不会为工作空间注册定价，也不会授权支出。

将限时促销发布为引用确切原始标准修订版本的显式结果价目表。显式设置 customer_organization_id: null 表示全局促销；传入公司引用则表示针对特定客户的专属促销。开始时间包含边界（inclusive），结束时间不包含边界（exclusive），两者均为精确的 UTC 纪元秒（epoch-second）字符串。客户专属规则会覆盖全局规则，且不会叠加折扣。同一作用范围内相互重叠的时间段会产生冲突。折扣会保留原有的 Token 类别/上下文阈值或媒体维度/计量器/单位，且不能高于原始支持费率。后续发布新的标准价格修订版本不会静默取消已发布的促销条款。

调用 listRetailPromotions 或 NiuAdminClient.listRetailPromotions 可读取包含完整截止时间覆盖状态的有界分页列表。每条返回的促销记录都会关联其原始标准价格以及已提交的提前终止信息（即使该终止事件位于当前历史分页之外）。数据库的 as_of 为 UTC 纪元秒。scheduled、within_period 和 ended 仅描述计入截止时间后的已发布时间段状态：全局规则仍可能被客户专属规则覆盖，且时间上的有效性并不代表已完成工作空间注册、具备可用供应或拥有支出权限。当前的标准价格与管理版本号会在该快照中一并作为 standard 返回（包括在设置截止时间导致版本号变更之后）。每个分页都有其独立的观测时间和快照。请原样传递 next_before；其版本号用于标识促销记录，而非任意历史事件。

提前终止促销会追加一个显式的有效截止时间，并保留原始规则记录。自然过期或提前终止仅改变未来的价格选择，绝不会对已存在的操作或异步任务重新计价。平台价格预览仅供参考，不构成支出授权或结算快照。

文本默认价格与兼容性选择

在未显式指定工作空间定价选择时，工作空间默认使用该模型在已配置平台币种下发布的平台文本价格，且不会创建额外的注册记录。现有的工作空间定价注册 API 仍可用于显式的兼容性选择（需具备平台管理员权限）。所选价格要求所属公司已存在对应币种的计费账户；该写入操作既不会创建资金，也不会授予授信额度。显式传入 null 会将未来的操作保留为使用传统的工作空间专属定价，这与“未设置选择”（自动继承平台默认价格）不同。已锁定的既有操作价格保持不变。

客户可以读取自身的定价模式与适用选择，且不会看到其他客户的规则。模型目录发现会报告客户适用的销售价格及其来源；但在准入控制绑定具体的不可变修订版本之前，发现结果仅供参考。价格发布、工作空间注册以及可见的价格均不代表供应已就绪、生成一定成功或计费已完整。

注册表、API 与 SDK 配置工作流均已实现。标准价格控制台表单、当前输入文本的物化/结算验收以及原子化视频集成仍在推进中；请继续将媒体资质验证与实际任务计费视为独立的验收工作。

路由媒体责任上限存证

在由客户资金支付的视频请求能够预留资金之前，必须针对确切的模型供应商报价、凭证、模型、Schema、维度及计量器，显式验证其最大可计费数量上限。视频输出预估不能确立该最大上限。该资质验证包含其存证修订版本与 SHA-256 引用、有限的 UTC 秒级有效区间以及不可变的管理员归属信息，且不包含采购价或客户销售价。

平台管理员可以通过 NiuAdminClient 中的 publishMediaLiabilityQualification、listMediaLiabilityQualifications 和 retireMediaLiabilityQualification 发布和读取这一独立配置。其对应的 REST 路径位于 /api/v1/providers/{supplier}/offers/{offer}/media-liability-bounds 下。发布操作使用版本比对和幂等键；吊销操作会缩短未来的有效期限并保留历史记录。客户与模型供应商成员无法调用这些端点。

注册表及其配置端点均已实现。按平台定价的视频工作空间注册与原子化准入均已实现；但仅靠此项配置本身并不能建立完整的商业化视频工作流。既有任务会保留其原始的价格与责任上限快照。

媒体默认价格与兼容性选择

在未显式指定工作空间选择时，工作空间默认使用与已配置币种以及确切模型、通道、分辨率、参考视频选项和计量器相匹配的已发布平台媒体价格，绝不会使用其他规格的价格替代。NiuAdminClient.setRetailMediaEnrollment 仍作为用于显式选择的兼容性 API 保留；所选币种的账户必须已经存在。显式传入 price_id: null 会将未来的操作保留为使用传统的媒体价目卡选择，而非继承平台默认价格。版本号、幂等键、原因及管理员归属信息会完整保留配置历史。

getRetailMediaEnrollment 返回调用方自身的工作空间配置及参考生效销售价格。符合条件的客户专属促销优先于全局促销，且不叠加；过期后会自动回退到下一个适用价格。这些读取结果不包含任何模型供应商采购信息或其他客户的规则。完成配置并不代表已具备支持视频的路由或支出授权。按平台定价的视频准入会在数据库事务时间内重新选择，并在同一个事务中绑定客户/供应商价格、经验证的数量上限、资金来源及冻结资金。已保存的既有任务保留其原始快照。完整的生成与结算验收仍待完成。

已知为零的销售价目表会使用精确的零金额货币预留，同时保留其经验证的数量上限与账户绑定。它绝不会凭空产生正数费用，也不会绕过路由、密钥或账户授权校验。后续的促销过期、提前终止、标准价格替换或工作空间取消注册，均不会对已准入的任务重新计价。如果在分发前路由或数量资质已过期，系统会拦截尚未发出的外呼请求；而已经分发的任务则会保留其原始价格与责任上限，用于后续恢复与结算。

供应商对比与净收入

商业头寸 API 将名义费用、已记录的余额/授信退款、已消耗赠金净折让以及客户净收入严格区分开来。在覆盖完整的情况下，名义费用减去退款再减去赠金折让等于净收入。例如，名义消耗为 100 个单位，其中消耗了 5 个赠金单位且无退款，则净收入为 95。这是规定的报表核算规则，而非宣称的实时合格交易示例。赠金在被消耗时作为销售折让处理，而非营业费用。

净贡献（Net contribution）是从该净收入中减去匹配的模型供应商分成（Provider earnings）；切勿将上游采购支出再重复扣减一次。若缺失资金来源分配或存在未决的费用覆盖缺口，系统将暂不展示完整净收入。旧版 margin_nanos 字段表示名义费用减去供应商分成，仅为保持兼容性而保留；它并非净收益或利润。已记录的余额退款并不证明发生了外部现金转账。个人出资的请求不包含在内。

这些数据行按请求分发队列（dispatch cohort）归集，并包含该队列已记录的退款。如需查看按记账期间统计的收入、已核实的收款记录及赠金发放情况，请使用财务记账摘要。这两个端点均支持滚动时间窗口（days 设为 7、30 或 90）或显式的 UTC 日历边界（from 与 until RFC 3339 时间戳，最长 370 天）。单独任何一项指标本身都不能证明现金利润。不同币种的数据行保持独立，不进行任何隐含的外汇换算。管理后台 → 财务报表（/admin/reports）支持 USD ($) 和 CNY (¥)，跨自然日历周期（本月至今 Month to date、单个自然月 Single calendar month、多月区间 Multi-month range 及滚动窗口 Rolling window）呈现统一的财务报表，并提供自动的上一周期环比对照（同时展示金额与百分比形式的 Current、Prior period 和 Change）以及导出 PDF（Export PDF）打印支持。导出的 PDF 采用正式的 Niu 机构信头排版（含品牌标识、PLATFORM FINANCIAL REPORTING 页眉、文档密级以及报告期间/基准/UTC 窗口/币种控制框）、无裁切的四栏核心 KPI 摘要条、完整的多页财务报表表格、会计与归因附注，以及固定在页面底部的品牌页脚栏。财务报表数值（收入、成本、应付款、现金收款、余额及变动额）均使用 $ 或 ¥ 格式化为四位小数（0.0000），而模型单价（Agreed offer quote）则保留完整的有效小数精度（最高九位小数）：

• 高管 KPI 摘要（Executive KPI summary）：净确认收入、供应成本（应付供应商款项）、平台净贡献（含贡献毛利率百分比）以及已核实的现金收款（含未使用的预付钱包现金）。
• 经营损益表（P&L）与现金收款、应付款及钱包头寸表：双财务报表联动对账，将名义消耗、已记录退款、已消耗赠金折让、净确认收入、应付供应商款项、净贡献、已核实现金收款、供应商结算状态以及特定时间点的钱包现金/授信来源与上一个可比周期进行核对。
• 按模型供应商与模型划分的单位经济效益（Unit economics by Provider & model）：默认展示期内活跃（Active in period，按客户费用降序排列以便活跃模型优先显示），并提供切换至全部已配置（All configured）的开关，分别列示名义费用、退款与赠金、净收入、应付供应商款项、已结算/未决负债、已记录的上游成本以及净贡献。未知的完整金额保持留空，同时明确标出覆盖缺口与已知的部分小计。

商业操作审计

平台审计日志涵盖已保存的标准价格与促销变更、工作空间文本/媒体定价注册、非现金赠金发放以及路由媒体责任上限资质验证。它们复用现有的“配置”（Configuration）与“模型供应商”（Provider）分类以及按来源限定的分页机制。完全相同的发布重试会保留原始事件，而不会产生看似新增的变更记录。

该元数据投影展示操作类型、当前目标/执行者名称、记录的系统执行者、修订版本及时间戳，不会暴露具体的货币金额、价目表明细、账户余额、数量上限、自由文本原因或密钥凭证。受保护的详细配置历史仍保留在其专用端点中。这些审计记录本身并不证明模型生成已成功、结算已完成或历史审计记录绝对完整。

known_upstream_cost_subtotal_nanos 会累加当前行币种下所有已记录的上游成本，即使没有同币种的客户费用或供应商分成与之匹配也是如此。upstream_cost_recorded_attempts 统计这些记录的尝试次数。这是一个已知的部分小计，而非完整支出覆盖的证明。当没有任何已记录成本时，该小计为 null；不同币种之间绝不会进行换算或合并。旧版 cost_nanos 字段仍保留其仅统计已匹配客户费用记录的覆盖规则。

现金与授信来源追溯

财务摘要包含 balance_credit_sources，即在 as_of 时间点的当前钱包快照，独立于所选的记账区间。它严格区分未使用的已核实现金与未偿还的授信消耗。一笔已核实的充值会先精确偿还尚未结清的授信扣费，剩余金额才会转化为预付现金；偿还授信欠款不会再次确认收入。退款会优先恢复已消耗的赠金，然后冲销未偿还的授信欠款，最后恢复已支付的现金。恢复至钱包的现金并不构成外部原路退款转账已完成的证据。

只有未来的扣费与退款会采用新的不可变现金/授信拆分机制。历史上缺失来源的记录、未分类的调账以及存在歧义的资金冲回，都会使完整的钱包来源总额保持为 null。已知小计仅包含完全覆盖的账户，并通过 uncovered_accounts 明确标出覆盖缺口。该视图不包含外部账单应收款，也不会将已批准的授信额度上限视为实际资金。在发放新的非现金赠金时，application_policy 默认为 future_only。若显式设为 unpaid_credit_first，则会先将其用于冲抵确切已知的未偿还授信扣费，然后再将剩余部分预留给未来的消耗。如果账户资金来源未知，整个发布操作都会被拒绝。原始扣费价格与应付供应商款项保持不变。该抵扣属于销售折让记账，而非二次余额授信或现金收款。其后续若发生退款，恢复的额度已包含在退款赠金分配中，切勿重复计入。

队列现金与未偿还授信

商业头寸 API 将 customer_cash_applied_nanos 与净收入区分开来：它将已核实的钱包现金及后续的授信还款归因到最初分发的请求上，并扣除已记录的现金余额恢复额。customer_outstanding_credit_nanos 则是在扣除还款、赠金冲抵和授信退款后剩余的钱包授信欠款（不含外部账单应收款）。这些金额是所选分发队列（dispatch cohort）截至当前的累计值，而非在该时间区间内入账的收款额；余额恢复并不证明发生了外部退款转账。赠金绝不计作已付现金。若存在缺失或有歧义的账户来源、缺失退款来源或未决流量，系统将暂不展示完整的货币金额。cash_source_uncovered_attempts 用于标识资金来源不完整的已计费尝试次数。管理后台 → 财务报表会将这些金额与未覆盖的现金请求数量一并展示。

授信额度审批需要显式的平台管理员权限。每一次新的 HTTP 审批都会在原子事务中记录已认证的操作者及不可变的策略修订版本；管理审计 API 会包含不含具体金额的审批元数据。较早的历史修订版本保持未归属状态。批准授信仅改变可用支出容量，绝不代表已收到资金或已确认收入。仅用于预警的阈值偏好设置则继续使用其独立的客户授权路径。

请使用仅限平台调用的客户账户目录来发现命名公司及其各币种余额，以便进行授信额度与非现金赠金管理。该目录包含尚无账户的公司，且绝不会自动创建资金。每个分页使用与客户计费完全一致的余额核算逻辑；平台管理权限仍与普通客户数据访问权限保持分离。

客户账户管理

管理后台 → 账户余额（Admin → Account balances）按公司和币种展示已入账余额、已批准授信额度、未决请求负债以及可用支出容量。设置授信（Set credit）会预览当前与拟议的授信上限，保留现有的预警阈值，并使用显示的策略修订版本号防止覆盖其他管理员的审批结果。授信额度设为零即要求预付费。对于尚无账户的公司，表单默认使用在管理后台 → 实例设置（Admin → Settings）中配置的平台币种，不支持按账户单独选择其他币种。创建零余额账户不会产生任何实际资金。历史多币种账户保留其原始币种；控制台不会进行汇率转换，也不允许管理员以其他币种授予授信额度。如果写入操作未能确认结果，需要先关闭对话框并刷新账户状态，然后再进行下一次更改。新的授信审批会保留经过身份认证的审计记录。

账户操作包括设置授信（Set credit）、发放非现金余额（Grant noncash balance）和非现金发放记录（Noncash grants）。输入正数赠金金额、单行原因及抵扣策略，然后点击准备发放（Prepare grant）。准备操作仅保存发放意图而不会增加资金；点击发放非现金赠金（Issue noncash grant）则会发布已保存的确切输入内容。非现金发放记录将已发放赠金（Issued gifts，包含早期通过 API 直接发放的记录及其独立冲正记录）与已保存意图（Saved intents，可用于查看原始发放分配或恢复已准备但未完成的操作）区分开来。冲正未使用赠金（Correct unused gift）仅允许对没有任何付费请求历史、已发生消耗、退款、未决请求预留或未知资金来源的账户执行全额冲正。请核对原始赠金信息，输入原因并显式确认移除。冲正操作会保留原始记录与授信策略，且不会产生现金退款或收入调整。已核实的现金入账仍然是独立的操作，且必须附有真实已结算的支付凭证引用。

可恢复的非现金赠金发布

在正式发布前，请先使用 prepareCustomerBalanceGrant 保存金额、原因、币种、抵扣策略及原始幂等键。准备阶段不会增加资金或收入。已保存的意图在刷新页面或更换浏览器后，仍可通过精确幂等键读取接口及分页历史记录获取。随后通过 grantCustomerBalance 发布已保存的确切输入；若修改已准备的金额、原因、币种或策略，将产生冲突。切勿因为丢失了发布响应就另换一个新的幂等键。状态为 prepared 表示当前读取快照中尚无匹配的已发放记录，但这并不证明仍在处理中的请求已经失败。状态为 issued 会返回原始分配金额，而非当前剩余可用余额。系统不会自动执行任何发布操作。准备阶段与正式发放拥有各自独立的已认证审计记录。浏览器表单在恢复某项意图时会重新检查已保存的状态。如果操作结果未确认，请使用检查已保存状态（Check saved status）或重试同一笔已保存的发放记录；切勿为了替代丢失的响应而新建另一笔赠金。关闭对话框后，已准备的意图仍会保留在后端列表中。

财务记账摘要会将已冲正的未使用赠金（corrected_unused_gifts_nanos）与发放赠金总额（issued_gifts_nanos）分开报告。财务报表会将这两项分别作为独立的非现金备忘行展示。冲正金额不包含在已核实现金收款、消耗退款及确认收入之内。平台审计日志会保留执行该操作的管理员及目标公司/币种名称。

分发前的定价检查

共享文本路由必须同时具备显式的模型供应商成本上限和适用的客户销售价目表。如果缺失配置，系统会在向上游分发前返回 service_not_ready；如果缺失客户销售价目表，则会回滚准入控制，且不产生任何额度预留或费用。显式配置的零价格仍然有效。由客户自有 API 密钥出资的个人路由则保留其独立的自付行为。媒体请求准入继续要求具备适用的客户与模型供应商价目卡快照以及责任上限资质验证。

平台的客户定价（Customer pricing）页面会为标准价格、工作空间价目表和促销计划显示价格检查（Price checks）。低于供应商成本（Below Provider cost）会标识出低于供应商成本的输入、输出、缓存读/写或推理单价（包含任一价目表中的上下文阶梯阈值）。该提示仅作参考：有意打折的价格仍然可以正常发布。由于存在固定请求费、最低收费以及实际用量结构差异，单价较低并不证明每次请求都会亏损。对标准价格的检查不能替代对适用促销或工作空间价目表的检查。

当媒体的币种、计量器、维度、最小起订数量及取整规则相互匹配时，系统可以使用精确的有理数单价进行比对。如果存在供应商折扣，或维度不兼容/缺失，则会显示无法比对（Comparison unavailable）。系统绝不会凭空捏造汇率、缺失的价格或缺失的计费类别。显示无更低单价（No lower unit rates）并不构成供应就绪或盈利能力的保证。这些比对基于当前的模型供应商配置，在编辑配置后必须刷新；它们不会授权请求分发，也不会对既有请求重新计价。与采购金额一样，相对成本诊断信息仅限平台管理员查看。

请求处理期间的价格变更

计费边界发生在请求准入（admission）之时，而非完成之时。客户销售价格与适用的模型供应商采购条款会作为不可变的修订版本存储，并绑定到已准入的尝试记录上。即使在模型生成运行期间发布了新价格，最终结算与延迟用量对账仍会使用准入时绑定的价格版本。在价格发布之后新准入的操作则会选择新生效的价目表。

同一操作内的重试会保留其最初绑定的客户销售价格修订版本；而每次选定的上游尝试则会各自绑定其对应的模型供应商条款。如果在准入期间路由或报价发生变更，必须在发送到上游之前重新校验或拒绝，而不能静默地与先前的成本上限混用。异步媒体任务在恢复过程中会始终保留其已保存的客户与模型供应商定价快照。发布、提前终止或自然过期某项促销活动，均不会追溯更改已准入的任务。

现有客户媒体合同

使用管理后台 → 定价配置 → 现有媒体合同（Admin → Pricing → Existing media contracts）选择一家公司，检查、替换或终止先前配置的客户专属媒体费率。组织设置（Organization settings）不管理价格。常规媒体价格请通过发布媒体价格（Publish media price）发布，使其自动跨工作空间生效；历史任务仍保留其准入时绑定的价格。如果缺少符合条件的模型，请在新标签页中打开模型供应商配置修复入口，完成后返回原定价表单刷新模型列表。