A team managing model access for its employees needs a different setup from a business selling AI subscriptions and model APIs under its own brand. Start with that choice, then decide what software, deployment work and ongoing resources you need.
Two use cases, with published package prices
XiuAI's published enterprise offer (Chinese), checked on September 8, 2026, lists these annual packages:
| Customer goal | Package | Published annual price | Included product scope |
|---|---|---|---|
| Give a team one place to manage model access, members, quotas and usage | Standard | CNY 9,600/year | Model management platform, model/API integration, member and usage management, ongoing technical support |
| Sell AI subscriptions and provide model APIs using your own brand | Enhanced | CNY 17,600/year | Standard package plus dedicated XiuStore, XiuRouter and management platform; brand/domain configuration, configuration migration and ongoing upgrades |
The annual fee covers the product and technical delivery package. Servers, cloud resources and model resources are separate costs. The customer purchases and owns the server/cloud environment; model resources are billed by token usage or agreed dedicated capacity. Work outside the standard product scope is quoted separately.
For the Enhanced scenario, this means starting with existing storefront, order, payment and model-API products under your own brand. You still operate the business and manage your customers. The brand, domain, customer relationships and business data remain on the customer side.
If you only need model access for an existing app, begin with XiuRouter's usage-based API service. The annual deployment package is for teams that want their own platform or product setup.
These two scenarios make the scoping questions below concrete. Separate four decisions:
- the product and environment the customer owns;
- model resources and usage costs;
- deployment and ongoing technical service;
- procurement, payment, and invoicing.
1. Start with the customer-owned product
Write down what the customer is actually building and where it will run.
- Is the system internal, customer-facing, or both?
- Which cloud account, domain, repository, and data store belong to the customer?
- Who owns the user relationship and the data-retention decision?
- Which parts must remain portable if the model provider changes?
This prevents a service provider from becoming the accidental owner of the
customer's product boundary. It also makes later security and procurement
questions much easier to answer.
2. Separate model resources from application cost
“AI cost” is not one number. At minimum, identify:
- the model family and exact model ID;
- the protocol and client that will send requests;
- input and output usage;
- cache reads and writes when applicable;
- service tier or route;
- currency, unit, and pricing version;
- the budget owner and the alert threshold.
For a multi-model application, the request path matters as much as the model
name. An OpenAI Responses request, an OpenAI Chat Completions request, an
Anthropic Messages request, and a Gemini GenerateContent request are different
protocol surfaces. A working “hello” response does not prove that the
production client is using the intended route.
The practical check is to run a small representative request and compare the
client configuration with the provider-side usage record: model, route,
status, token buckets, and recorded cost.
3. Define deployment and ongoing service separately
Before implementation starts, decide who is responsible for:
- integration and environment setup;
- monitoring and incident response;
- version changes and rollback;
- access-key scope and rotation;
- debugging a failed request;
- documentation and handover.
This is where a model API service and an engineering service meet, but they
should not be presented as the same thing. A gateway can provide protocol
access, scoped keys, pricing visibility, and request records. It does not
automatically become an SLA, a managed application team, or a provider
fallback system.
4. Leave procurement until the scope is clear
Procurement questions are easier once the technical boundary is explicit:
- What is being purchased: software access, implementation, or ongoing service?
- Is the charge usage-based, fixed, or a combination?
- Who receives the invoice?
- Which taxes, service fees, or payment constraints apply?
- What does warranty or support cover, and what is outside the boundary?
Do not hide these facts behind a generic “AI package” label. A buyer should be
able to tell what they receive, how the amount is calculated, and where
support starts and ends.
A small intake that works
Before choosing a vendor or writing a proposal, collect these six answers:
| Question | Evidence to keep |
|---|---|
| What is the customer building? | product owner, users, environment |
| Which protocol does the client send? | SDK configuration and request path |
| Which model and route are required? | model ID, service tier, compatibility note |
| How will usage be controlled? | key scope, quota, budget, expiry |
| Who owns deployment and incidents? | named responsibility and rollback path |
| What is the commercial boundary? | price method, invoice, support and warranty |
If an answer is missing, mark it as an open decision. Do not fill the gap with
a default model, a guessed SLA, or a headline discount.
Where XiuAI fits
XiuAI provides products and technical services for the two use cases above. XiuRouter is relevant when an
application or agent needs model access through native OpenAI, Anthropic, or
Gemini protocol routes, with scoped API keys and request-level usage and cost
records. XiuStore is a buyer-facing service for AI accounts and subscriptions,
where price, delivery form, warranty, and after-sales support need to be clear
before purchase. Neither surface replaces the customer's own product
ownership or the project responsibility agreement.
The right order is simple: define the customer's product, validate the
protocol and usage path, assign deployment responsibility, then settle the
commercial terms. That sequence produces a clearer proposal and a more
testable implementation.
XiuAI and its products are operated by XiuLab Inc, a U.S. corporation.
For a project-specific discussion, see the XiuAI contact page.
Top comments (0)