Pricing and purchase

Yes, but we do not invent prices merely to make the catalog look larger. Every new tier must define a stable public SKU, long-lived marketing display price, formal entitlements, and server price version. The current page shows only the personal professional and standard team plans that align with formal prices; later site versions may add basic, professional, or higher tiers.

The published standard team plan is a fixed team package displayed and quoted at quantity=1, not an unpublished per-seat offer. It can be purchased after login; actual member limits, allowance, and governance follow formal server entitlements. Seat selection appears only after the admin system publishes a per-seat SKU, billing unit, and bounds. Teams needing contracts, corporate payment, invoices, private deployment, or custom delivery continue through procurement.

Website prices are stable marketing displays shipped with the site content. Anonymous visitors do not log in or request the server price catalog. At checkout, the server reads the current formal price by public SKU, cycle, and quantity and returns a time-limited quote. WeChat Pay and Alipay are collection channels, not product-pricing systems; they collect only the amount submitted by the server-created order.

Payment orders, purchasing entity, tenant, current entitlements, repeat-purchase restrictions, and delivery account all depend on signed-in identity. The site opens login first for signed-out visitors and requests a formal server quote only afterward. If the quote differs from the display price, checkout stops before creating a QR code and requires explicit confirmation.

Prices do not mechanically follow upstream costs weekly or monthly. Qiniu, OpenRouter, direct model providers, and other relay costs vary by model, context, cache, exchange rate, discount, and service level, but those are internal costs. Public prices should remain stable. If an adjustment becomes necessary, the site display version and formal server price version are published together, while existing orders continue under their frozen snapshots.

No. Software subscriptions, seat entitlements, and model usage are accounted for separately. Hosted-model calls are subject to allowance, model retail price, and fair-use rules. Heavy users may use their own model keys where supported to avoid accumulating intermediary costs.

No. A scan, QR page, browser event, or frontend parameter cannot activate entitlements. The site only queries server order status. The payment service must verify WeChat callbacks, match merchant ID, order number, and amount, actively query when controlled, and post idempotently. The site shows success only after the server returns success.

No. The site currently creates real one-time WeChat Native QR payments only and does not enroll users in automatic renewal by default. Any future renewal agreement will be disclosed prominently and require active confirmation before activation.

The server validates current entitlements, plan-switching rules, and pending orders to block disallowed repeat purchases or downgrades. Permitted upgrades follow server rules; changes to billing entity, seats, or contract boundary move to procurement support.

Persistent AI team templates and personality-driven role recommendations remain Preview. Marketing pages describe only confirmed capabilities as currently available. Preview is not a formal delivery promise, and formal entitlements follow the plan terms and server order snapshot at purchase.

View the status returned by the server on the Orders page. For duplicate charges, nondelivery, or orders eligible under the refund policy, contact [email protected]. See Payment Information and Refund Policy for the criteria.