DEV Community: XiuAI

How to Compare an AI Subscription Before You Buy

Dashu — Fri, 04 Sep 2026 12:20:13 +0000

One month of ChatGPT Plus currently costs US$19.99 at XiuStore in either of two purchase options. If you want to keep using your existing ChatGPT account, only one of those options fits.

Here is the actual comparison, using the public product page, checked on September 19, 2026.

What the same price buys

	Activation on your account	Ready-to-use account
Listed price	US$19.99	US$19.99
Subscription term	One month	One month
Account you use	Your existing, eligible ChatGPT account	A new single-user account supplied with Plus enabled
What the order delivers	A redemption code and instructions	Account sign-in details and instructions
Your next step	Redeem on the account you intend to use	Follow the order instructions, then sign in to the supplied account
OpenAI API credits	Not included	Not included

The practical choice is straightforward. Want Plus on the account you already use? Choose activation on your account. Buying the ready-to-use option will give you a different account; it will not activate your existing one.

If you want a separate account with Plus already enabled, the ready-to-use option provides that. The order instructions explain where to provide the receiving email and how to retrieve the account details when delivery is complete.

Price, currency and support

The catalog also shows CNY 134.93 as a reference amount. XiuStore transactions use USD, so the amount to compare here is US$19.99. The reference conversion and future prices can change. Neither quote establishes a price for a later purchase.

For activation on your own account, the account must be accessible and eligible for redemption. The listed option does not include a renewal service.

Both options describe support for the covered subscription term: if the subscription ends early, unused days are refunded, rounded up to a full day. Account bans are excluded. Support starts from the original order, where the buyer can provide the delivery details and error information for that purchase.

Applying this comparison to another offer

Compare the account you will use and the subscription term alongside the price. In this example, the product name, price and term all match, but the result after delivery is different. A cheaper offer only helps if it delivers the account arrangement you actually want.

The current options and full terms are on the product page. This walkthrough uses XiuStore's own published offers. XiuStore is operated by XiuLab Inc, a U.S. corporation.

A Practical Scoping Checklist for Enterprise AI Projects

Dashu — Tue, 01 Sep 2026 19:07:02 +0000

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.

How to Compare LLM API Gateway Prices Without Mixing Models, Cache, and Routes

Dashu — Tue, 01 Sep 2026 01:53:16 +0000

For a developer using GPT-5.5, a price comparison can be concrete: $35 in the displayed provider-reference column versus $2.45 at XiuRouter's current default rate for the same token counts.

Here is the arithmetic, followed by a method you can apply to your own usage.

September 30 deadline for existing benefit-group users

Update, September 13, 2026: XiuRouter's benefit group is closed to new selection. Existing access remains available for now, but the group will stop completely after September 30, 2026. If your key still uses it, migrate to another available group before then. Retaining a key's old settings does not extend the group's availability.

Recheck the destination model, price and quota before migrating. For Astra, Fast consumes 2.5 times the quota of Standard. Verify a small request and its recorded cost before restoring normal traffic.

Official retirement notice (Chinese) · Current pricing and migration guide

A worked example: $35 versus $2.45

Prices checked on September 12, 2026 in XiuRouter's public pricing catalog. The model is gpt-5.5. The public catalog currently exposes one selectable group, max, so the ordinary price page no longer requires a Value-versus-Managed choice. Historical or account-specific keys may retain other group settings; use the rate available to the key that will make the request.

Assume your application accumulates one million uncached input tokens and one million output tokens across multiple requests. Each request stays within the 272,000-input-token pricing tier.

Token usage	Displayed provider-reference rate	XiuRouter rate
1 million uncached input tokens	$5.00	$0.35
1 million output tokens	$30.00	$2.10
Estimated token cost	$35.00	$2.45

Reference estimate = $5.00 + $30.00 = $35.00
XiuRouter estimate = $0.35 + $2.10 = $2.45
Difference         = $32.55, or 93%

These are USD token-rate estimates using the reference prices displayed by XiuRouter. This example contains no cache reads or writes, and it does not add taxes or other non-token charges. Requests above the input threshold use different rates. No new paid model request was run for this example.

For your own app, replace the token counts with usage from a representative task. Keep the exact model, service tier and applicable input-length band fixed. The worked example below shows why a different input/output mix can change the winner when two routes have different rate ratios.

Why an input discount is not the whole bill

The current gpt-6-astra standard input-length band illustrates the difference. At no more than 272,000 input tokens per request, the September 12 catalog lists an input rate of $0.875 and an output rate of $5.25 per million tokens, against displayed provider-reference rates of $10 and $50 respectively.

That is about 91.3% less for input and 89.5% less for output. Accumulating one million uncached input tokens and one million output tokens across requests costs an estimated $6.125, versus a $60 reference estimate: about 89.8% less in total. It would be inaccurate to advertise this workload as saving over 90% on the whole bill.

The calculation excludes cache usage, tool fees, taxes and other non-token charges. Longer inputs use another pricing band. It is a calculation from the public catalog, not a newly executed or billed model request.

A discount percentage is not a price model

Before comparing two offers, define the exact thing being compared.

A useful comparison tuple is:

model
+ provider or source model
+ service group or route
+ API protocol
+ input price
+ output price
+ cache-read price
+ cache-write price
+ currency and unit
+ pricing version or checked-at time

If one of these fields changes, you may no longer be comparing the same offer.

For example:

A model alias can point to a different upstream model later.
An OpenAI-compatible route and a native Anthropic Messages route can expose different capabilities.
A lower-cost service group can have a different availability boundary.
A cached-input price cannot be compared with an uncached-input price.
A price copied from an old screenshot may no longer match the live catalog.

The first rule is therefore simple: compare a complete route, not a model name.

Separate the token buckets

Token-based APIs commonly charge different rates for several token types.

At minimum, keep these buckets separate:

uncached input tokens;
output tokens;
cache-read tokens;
cache-write or cache-creation tokens.

A normalized cost calculation is:

cost = (
    input_tokens       * input_rate_per_1m
  + output_tokens      * output_rate_per_1m
  + cache_read_tokens  * cache_read_rate_per_1m
  + cache_write_tokens * cache_write_rate_per_1m
) / 1_000_000

Use raw token counts for the *_tokens values and prices per one million tokens for the *_rate_per_1m values. The division by 1,000,000 converts the unit rates into the estimated cost.

Do not add cache-read tokens to uncached input and then charge both rates. Do not apply the input rate to output tokens. Do not assume cache write and cache read have the same price.

Weight the comparison with a real workload

An input-heavy workload and an output-heavy workload can produce opposite results from the same price table.

Consider this hypothetical example:

Route	Input / 1M	Output / 1M	Cache read / 1M
Route A	$0.50	$5.00	$0.05
Route B	$1.00	$3.00	$0.10

Assume one workload uses:

8 million uncached input tokens;
2 million output tokens;
5 million cache-read tokens.

Because these rates are per one million tokens, the quantities in the following equations are expressed in millions:

The weighted costs are:

Route A = 8 × 0.50 + 2 × 5.00 + 5 × 0.05 = $14.25
Route B = 8 × 1.00 + 2 × 3.00 + 5 × 0.10 = $14.50

Route A has the lower input price. Route B has the lower output price. Neither headline tells you the result by itself.

These numbers are illustrative, not current XiuRouter or provider prices. Replace them with the live rates and your own token distribution.

Keep reference prices traceable

A savings claim needs a reference source.

Record:

the reference model;
the provider or published source;
the input, output, cache-read, and cache-write reference rates;
the date or pricing version used;
the gateway route being compared.

If the gateway maps one public model name to another source model, that mapping must be visible in the evidence. Otherwise, the comparison may combine two different products.

XiuRouter's public pricing API exposes a pricing_version and, where available, structured reference_price fields such as input, output, cache_read, cache_write, and source_model. The live response can change as models and routes change, so store the version with the comparison instead of treating one response as permanent.

Use the price available to your API key

Price is not independent of the route that delivers the request.

A gateway can make the same model available through multiple service groups. A cheaper group may have different availability, permissions, or upstream characteristics. A key may also be restricted to only some groups or models.

For XiuRouter, the September 12 public catalog has only max as a selectable group. A single-group account does not need to choose a tier in the interface. If an existing key has a different group or account-specific access, include that group in the estimate and request check.

Do not calculate using the cheapest visible group and then send production traffic through a different group.

Protocol compatibility is a separate decision

Pricing does not prove that a client workflow will work.

OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Gemini GenerateContent have different request shapes and behavior. A model that works through one endpoint does not automatically work through another.

Before accepting a lower price, confirm:

the client sends the protocol you expect;
the route supports the required endpoint;
tool calls and streaming work for the actual client;
the selected key can access the model and service group.

A request that fails cannot be made economical by a lower token rate.

Verify the estimate against a real request

A spreadsheet is only the estimate.

Run a small, non-destructive task through the exact client configuration you plan to use. Then inspect the gateway's request or usage record.

For XiuRouter, verify:

the intended API key;
the intended model;
the intended endpoint;
the selected service group;
request status;
input, output, and cached-token usage;
recorded cost.

If the usage record does not match the estimate, investigate the route before scaling traffic.

Common causes include:

the client used an older provider configuration;
the API key selected a different model or group;
the final request path was not the expected protocol route;
cache usage differed from the assumption;
the catalog changed after the estimate was created.

Include non-token costs explicitly

Token rates are not always the complete commercial cost.

Check whether the comparison also needs:

currency conversion;
prepaid balance or recharge fees;
taxes;
minimum commitments;
subscription fees;
failed-request charging rules;
image, audio, or other non-token pricing units.

Do not hide these costs inside an unexplained multiplier.

A practical comparison checklist

Before choosing a route, confirm:

[ ] The model and source model are identified.
[ ] The service group is fixed.
[ ] The API protocol is fixed.
[ ] Input and output rates use the same unit.
[ ] Cache read and cache write are separate.
[ ] The reference price has a source and checked-at time.
[ ] The gateway price has a pricing version or checked-at time.
[ ] The estimate uses a representative workload.
[ ] Currency, taxes, subscriptions, and recharge costs are included when applicable.
[ ] A real request completed through the expected route.
[ ] The usage record matches the key, model, group, token buckets, and cost.

This method produces a smaller claim than "Gateway A is always cheaper," but it produces a claim that can be checked.

Usage records and conversation content

Cost verification uses statistics such as model, token counts, charges and request status. It does not require saving the prompt or model reply.

XiuRouter's Data Processing and Privacy statement, updated September 12, says that XiuRouter does not store model conversation content, use it for model training or sell user data. Usage statistics and model performance data are retained long term. Model developers process requests under the policies of their respective services; this is not a claim of zero retention across every provider.

XiuRouter sources

Current model and route prices:

https://router.xiu.ai/en/pricing

Machine-readable public pricing response:

https://router.xiu.ai/api/pricing

Protocol and endpoint boundaries:

https://docs.xiu.ai/en/router/api-compatibility/

Prices, models, service groups, protocol support, and reference data can change. Re-run the comparison against the live catalog and verify a real request before using the result for a production decision.

Disclosure: XiuRouter and XiuAI are operated by XiuLab Inc, a U.S. corporation.

How to Verify an AI Subscription Delivery Without Trusting a Status Label

Dashu — Mon, 31 Aug 2026 19:45:28 +0000

If you already use ChatGPT or Claude, choose which account you want to use after buying. Activating a subscription on your current account and receiving a separate account are different purchases, even when the price is the same.

For example, XiuStore currently lists both ChatGPT Plus options at $19.99 USD. Here is what each one delivers.

Choose the account before the price

Option	Price checked September 19, 2026	What you receive
ChatGPT Plus on your own account	$19.99 USD	One month of Plus on the account you choose, with a redemption code and instructions in your order.
ChatGPT Plus with a new account	$19.99 USD	A separate single-user account with one month of Plus already enabled, plus sign-in details and instructions.
Claude Pro on your own account	$20.59 USD	One month of Pro on your existing Claude account, with the activation steps in your order.

If you want to keep using your current ChatGPT account, choose activation on your own account. The ready-to-use account option gives you a different account. For Claude Pro, the current option requires a Claude account you can already access.

You can compare the options, prices, delivery steps, and support on the public ChatGPT Plus page and Claude Pro page before signing in to buy. Prices can change; confirm the selected option's USD total at checkout. Any CNY amount shown is a reference conversion.

ChatGPT Plus is a subscription for using ChatGPT. These Plus options do not include OpenAI API credits for your application or coding tools.

After payment, start with your order

Open My orders and select the purchase.

For Plus activation on your account, retrieve the redemption code and follow the order's redemption link on the ChatGPT account you intend to use. For a new Plus account, follow the receiving-email instructions, then retrieve the account details when the order notification confirms completion. For Claude Pro, open the activation flow attached to that order.

If the order is still being processed, follow its current instructions. Check the original order or contact support before paying for the same purchase again.

Confirm the subscription on the account you will use

Open ChatGPT or Claude itself. Check that you are signed in to the intended account, that the plan says Plus or Pro as purchased, and that the visible subscription dates match the order. Try a feature included in that plan.

If something is missing, open support from the original XiuStore order. Include the order reference, what the provider's account page shows, the time, and the full error message if there is one. That gives support a specific problem to resolve.

The current listings describe subscription support separately from the purchased term. Their early-expiry policy refunds unused subscription days, rounded up to a full day; account bans are excluded. Read the selected option's full conditions before paying. A support period on another product does not, by itself, establish that product's subscription length.

The order and delivery guide explains where to find delivery details and request help. Keep the original order open until the account and plan match the option you bought.

Published by XiuLab Inc, the operator of XiuStore. This guide was prepared with AI assistance and checked against the linked public product pages and delivery guide on September 19, 2026.

How to Connect Codex to a Custom Responses API Provider and Verify the Route

Dashu — Mon, 31 Aug 2026 18:16:44 +0000

Changing an API base URL is not enough to prove that Codex is using the provider you intended.

Codex is an agentic client. It needs more than a model that can return text. The provider must support the Responses API behavior Codex relies on, the API key must reach the process that launches Codex, the selected model must be available to that key, and the final request must arrive at the expected endpoint.

This guide shows a conservative setup for a custom Responses API provider, using XiuRouter as the concrete example. The same verification method applies to other compatible gateways.

The verification task sends model requests and can incur usage charges. "Read-only" refers to filesystem access; it does not make the model calls free. Check the current model and service-tier prices before running the test.

The configuration has four separate decisions

A working Codex provider configuration answers four questions:

Which model should Codex request?
Which named provider should Codex use?
Which base URL should receive the request?
Which environment variable contains the API key?

Keep those decisions explicit. A minimal user-level configuration looks like this:

model = "YOUR_MODEL_ID"
model_provider = "xiurouter"

[model_providers.xiurouter]
name = "XiuRouter"
base_url = "https://router-api.xiu.ai/v1"
env_key = "XIUROUTER_API_KEY"
wire_api = "responses"

Use a model ID that is currently visible to your account. Do not copy a model name from an old screenshot or another user's configuration and assume your key can access it.

The important line is:

wire_api = "responses"

Codex uses the Responses API for its native agent workflow. A provider that only accepts Chat Completions requests may be useful for other clients, but it is not automatically a drop-in Codex provider.

OpenAI's Codex configuration reference also defines base_url, env_key, and wire_api as separate provider settings. Treat them as separate failure boundaries when debugging.

Keep the API key out of `config.toml`

The configuration should name an environment variable, not contain the secret:

env_key = "XIUROUTER_API_KEY"

For a terminal session:

export XIUROUTER_API_KEY="YOUR_KEY"
codex

For Codex Desktop on macOS, the application may not inherit variables from your terminal shell. Set the variable in the launch environment, then fully quit and reopen Codex:

launchctl setenv XIUROUTER_API_KEY "YOUR_KEY"

This distinction matters. A correct key in .zshrc can still produce a 401 if the desktop application was launched outside that shell.

Do not print the key during diagnosis. Check whether the variable exists and whether the request succeeds, not the secret value itself.

Start with a reversible configuration

Do not overwrite a working provider before the new route has passed a real task.

Keep the previous provider block in the file and change only the active model and model_provider lines. That gives you a fast rollback if the custom route fails during a longer agent run.

It is also safer to test the new provider in project-level configuration before promoting it to your user-wide default. OpenAI documents project configuration in .codex/config.toml, while user defaults live in ~/.codex/config.toml.

The practical rule is:

project config for a bounded test;
user config after the provider has passed;
old provider retained until rollback is no longer needed.

Verify the provider in a new task

After changing the provider configuration, restart the client as needed and create a new local task. Tasks that were already open can retain their previous provider, so use the new task to verify the route.

In that task, ask Codex to perform a small read-only operation that requires tool use.

For example:

Inspect this repository, identify the test command, and summarize the main modules. Do not modify files.

This is more useful than asking the model to say hello. A plain text response proves only that one request returned text. A repository inspection exercises the agent loop, tool instructions, streaming, and follow-up turns without creating a destructive side effect.

Then verify the request on the provider side.

For XiuRouter, the usage record should show:

the intended API key;
the intended model;
the Responses path;
a successful status;
usage and cost recorded for the request.

The expected path is:

/v1/responses

If no corresponding record appears, do not assume the request used the new provider. Codex may still be using an older active configuration, or the application may not have inherited the environment variable.

Diagnose failures by boundary

`401 Unauthorized`

Check the process environment first.

Was Codex launched after the environment variable was set?
Does the variable name exactly match env_key?
Is the key valid for the current account?
Is a project-level configuration overriding the user-level provider?

For Codex Desktop, quit the application completely after changing the launch environment.

The model is missing or rejected

Model visibility and key permissions are separate from protocol compatibility.

A gateway can support the Responses API while a particular key still lacks access to the selected model. Recheck the current model catalog and the key's scope instead of changing protocol settings at random.

The request hits the wrong URL

Inspect the final request path.

With:

base_url = "https://router-api.xiu.ai/v1"
wire_api = "responses"

the client should call /v1/responses.

If you see a duplicated path such as /v1/v1/responses, the base URL and endpoint path have both included the version prefix. Fix the configuration boundary that owns the duplicate instead of adding another redirect.

A simple prompt works, but an agent task fails

This usually means the test was too shallow.

Codex needs the Responses API behavior used by its real agent loop. Tool calls, streaming events, multi-turn state, and error handling can fail even when a one-shot text request returns 200.

Use the smallest real task that reproduces the failure. Record:

Codex version;
provider name;
model ID;
final request path;
HTTP status;
whether a usage record exists;
the first failing agent action.

That evidence is much more useful than "the custom provider does not work."

The route works, but long tasks are unstable

Separate initial compatibility from runtime reliability.

Check whether failures correlate with:

long streaming responses;
tool-heavy loops;
upstream model availability;
rate limits;
context size;
client or network interruption.

Do not hide those failures by repeatedly retrying a destructive task. Reproduce them with a read-only task first.

A practical acceptance checklist

Before making the custom provider your default, confirm all of the following:

A new local task reads the intended configuration and provider.
The API key is supplied through the named environment variable.
The selected model is available to that key.
The final request path is /v1/responses.
A read-only tool-using task completes.
The provider records the expected key, model, status, usage, and cost.
The previous provider is still available for rollback.

This is the difference between "the configuration looks right" and "the route has been verified."

XiuRouter-specific setup

XiuRouter's Agent integrations page generates a Codex configuration based on the selected app, operating system, API key, model permissions, and whether the user is creating a new setup or replacing an existing provider. It also keeps the verification step separate from the configuration step.

The public integration guide is here:

https://router.xiu.ai/en/integrations

The current Codex setup and restart instructions are here:

https://docs.xiu.ai/en/router/integrations/codex/

The API compatibility reference is here:

https://docs.xiu.ai/en/router/api-compatibility/

The OpenAI Codex configuration documentation is here:

https://developers.openai.com/codex/config-basic

https://developers.openai.com/codex/config-reference

The product-specific values may change. Recheck the current model catalog, key permissions, and integration output before copying a configuration into a production workflow.

Configuration and product boundaries reviewed against the linked guides on September 19, 2026.

A Delivery Label Is Not a Fulfillment Model

Dashu — Sun, 30 Aug 2026 15:07:39 +0000

Digital products are often sold with one short promise: instant delivery.

That label is convenient until the product behind it changes.

A subscription may require activation on the buyer's existing account. Another
listing may deliver a separate account. A one-time service may require manual
processing. If all three are represented by a free-form string, an old order can
show instructions that no longer match the actual workflow.

We found this class of problem while auditing XiuStore,
our service for AI accounts and subscriptions. The useful lesson is broader than
one storefront:

Product promises, order snapshots, and operational delivery instructions are
related, but they are not the same data.

This article presents a small model for keeping them separate.

The three facts a digital order needs

A digital order usually combines three kinds of information.

1. The offer the buyer accepted

This is the commercial fact at checkout:

product and option
price and currency
stated delivery mode
support coverage
terms shown before purchase

These values should be preserved with the order. If the catalog changes later,
the order must still explain what the buyer paid for.

2. The current order state

This is the transaction state:

created -> paid -> processing -> delivered

The exact states vary by product, but they should describe what has happened to
this order. A status such as paid does not explain where the buyer should go
next.

3. The workflow used to complete delivery

This is the operational route:

activate_existing_account
deliver_account
one_time_service

The workflow determines the next action shown to the buyer. It may point to an
activation form, a delivery page, an order message, or a support path.

The common mistake is to collapse all three facts into one string such as:

Payment completed. Delivered automatically.

That string mixes a transaction event, a fulfillment promise, and an
instruction. It becomes stale as soon as one part changes.

Use a delivery type, not a marketing sentence

A better model starts with an explicit fulfillment type:

type FulfillmentMode =
  | "activate_existing_account"
  | "deliver_account"
  | "one_time_service";

The catalog can still show buyer-facing copy, but the workflow should not depend
on parsing that copy.

function nextStepFor(mode: FulfillmentMode) {
  switch (mode) {
    case "activate_existing_account":
      return { kind: "activation", href: "/activate" };
    case "deliver_account":
      return { kind: "delivery", href: "/orders/current" };
    case "one_time_service":
      return { kind: "support", href: "/orders/current" };
  }
}

This keeps the routing decision structured. Copy can be translated or improved
without changing delivery behavior.

Keep the snapshot, but do not replay every old label

Order snapshots are important. They protect historical price, option, and
support facts from later catalog edits.

But a snapshot should not become an excuse to replay stale operational copy
forever.

For example, suppose a product was once marked as automatic delivery and later
moved to manual processing. An old free-form deliveryLabel may still say
"delivered automatically" even though the current workflow is manual.

The safer split is:

preserve the purchased option, price, and buyer-visible terms in the order;
store or resolve a structured fulfillment mode;
render current instructions from a versioned delivery policy;
keep an audit trail when the operational route changes.

The order remains historically accurate without sending the buyer into an
obsolete workflow.

Render instructions from one policy

Buyer-facing instructions should come from a single mapping rather than being
copied into product cards, checkout responses, order pages, and support
templates.

const fulfillmentCopy: Record<
  FulfillmentMode,
  { title: string; body: string }
> = {
  activate_existing_account: {
    title: "Continue account activation",
    body: "Open the activation step and follow the instructions for this order.",
  },
  deliver_account: {
    title: "Review delivery details",
    body: "Open the order to view the delivered account and first-use checks.",
  },
  one_time_service: {
    title: "Processing",
    body: "The service is being handled. Updates will appear in the order.",
  },
};

This does not require a large workflow engine. A small enum, one mapping, and
tests around the order page are often enough.

Test the buyer path, not only the API response

A successful order API response does not prove that delivery is understandable.

For each fulfillment mode, verify the customer-facing path:

The product page states what the buyer will receive.
Checkout preserves the selected option and current price.
The paid order shows the correct next action.
The destination page matches the order and current language.
The buyer can verify the final result on the relevant provider's official service.
Support coverage is visible without implying guarantees the seller cannot make.

This is especially important for third-party AI services. Regional eligibility,
identity checks, account restrictions, and appeals remain controlled by the
original provider. A store can explain delivery and support, but it cannot
override those rules.

What buyers should see before paying

Good fulfillment modeling should become visible product information.

A digital-product listing should answer:

Is this activation for my existing account, a delivered account, or a one-time service?
What is the current price and availability?
What action will I need to take?
Where will delivery details appear?
What first-use checks should I perform?
What support is included, and what is outside the seller's control?

XiuStore documents this decision process in its guides for
choosing a product and
checking orders and delivery.

The underlying engineering principle is simple: model the delivery contract
before writing the delivery slogan.

A compact acceptance checklist

Before releasing a new digital product or changing its fulfillment method,
check:

[ ] Fulfillment mode is a structured value.
[ ] Product copy matches that value.
[ ] Checkout snapshots the commercial facts.
[ ] Order instructions come from the active delivery policy.
[ ] Old free-form labels cannot override the current route.
[ ] Every fulfillment mode has an end-to-end buyer-path test.
[ ] Support copy does not promise control over a third-party provider.

This separation prevents a small catalog change from becoming a misleading
order page. More importantly, it lets the buyer understand what happens next
without knowing anything about the store's internal implementation.

Disclosure: This article was prepared with AI assistance from XiuAI's current
product documentation and checked against the linked public pages on August 30,
2026.

A 200 Response Is Not Enough: Testing Claude Code Through an Anthropic Gateway

Dashu — Sun, 30 Aug 2026 12:56:41 +0000

A 200 response from an AI gateway proves that one HTTP request worked. It does not prove that Claude Code can discover a model, send the right Messages payload, recover from an optional endpoint failure, and finish a task.

That distinction matters when Claude Code is configured through an Anthropic-compatible gateway such as XiuRouter.

This guide uses a two-layer acceptance test:

Send a small request directly to /v1/messages.
Run a complete short task in Claude Code.

The inference calls in both tests are billed at the selected model and service-tier rates. Check current pricing before running them.

If the first layer fails, debug the gateway configuration. If it passes but the second layer fails, debug the client workflow instead of rotating keys or changing models at random.

Configure the API root, not the Messages path

Claude Code appends /v1/messages to the configured base URL. Set the API root without /v1:

export ANTHROPIC_BASE_URL="https://router-api.xiu.ai"
export ANTHROPIC_AUTH_TOKEN="YOUR_XIUROUTER_API_KEY"
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

ANTHROPIC_AUTH_TOKEN sends a Bearer token, which XiuRouter accepts on the Messages route. Gateway model discovery lets Claude Code load models exposed by the configured gateway.

A base URL ending in /v1 produces the duplicated path:

https://router-api.xiu.ai/v1/v1/messages

That is a configuration error, not a model error.

Test `/v1/messages` before opening Claude Code

Use an exact model ID visible to the intended XiuRouter key. Do not copy a model ID from an old article or another service group.

curl -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "max_tokens": 32,
    "messages": [
      {
        "role": "user",
        "content": "Reply only with: connected"
      }
    ]
  }'

The response should be JSON with a Messages content value. Check more than the status code:

The body is JSON, not an HTML error page returned by a proxy.
The response contains text content.
The model and usage fields are plausible for the request.
The request appears in the expected XiuRouter usage records.

An HTTP 200 with an empty body, malformed JSON, or HTML is still a failed integration.

Then test the Claude Code workflow

Start Claude Code in a non-critical repository:

claude

Use /model and select a model marked From gateway. Run /status and confirm the Anthropic base URL and gateway credential are active.

The test task should exercise the client, not just produce a greeting. For example:

Read package.json and report the package manager, test command, and build command.
Do not edit any files.

A useful pass condition is:

Claude Code discovers a gateway model.
The task starts without an authentication or payload error.
The client receives a usable Messages response.
The task reaches a final answer.
The corresponding gateway request is visible in usage records.

This catches failures that a standalone curl request cannot expose.

Treat `count_tokens` 404 as a workflow signal

XiuRouter does not expose a dedicated /v1/messages/count_tokens route. Claude Code documents token counting as optional and can fall back through the inference endpoint.

Do not classify the connection as broken from that 404 alone. Check what happens next:

If Claude Code falls back to /v1/messages and completes the task, the missing optional route did not block the workflow.
If the task stops after the 404, capture the client version and logs, then diagnose the client behavior.

The pass condition is task completion, not the absence of every warning.

Failure patterns and the shortest useful check

`401` or invalid token

Confirm that the variable is ANTHROPIC_AUTH_TOKEN, the key is active, and the shell that starts Claude Code actually contains the variable.

If Claude Code reports multiple credential sources, run /logout to use the gateway credential, or unset the gateway variables to keep the saved Claude login. Do not leave both paths ambiguous.

Gateway models do not appear

Confirm:

export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY="1"

Restart Claude Code after changing the environment. Also verify that the intended key can see at least one Claude model.

The request path is `/v1/v1/messages`

Remove /v1 from ANTHROPIC_BASE_URL. The correct value is:

https://router-api.xiu.ai

A `400` response names experimental fields

Retry with:

export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS="1"

This is narrower than changing the model, key, and gateway at the same time.

HTTP 200 contains HTML

Inspect the response content-type and body. A CDN, login wall, or proxy can return an HTML page with a successful transport status. The direct curl test should return Messages JSON.

Direct Messages works, but Claude Code still fails

Keep the successful curl response as evidence and narrow the remaining variables:

Claude Code version
selected gateway model
active environment variables
credential-source warning
optional endpoint fallback
experimental request fields

Changing one variable at a time preserves the known-good gateway result.

Roll back without leaving mixed credentials

For the CLI, unset the gateway variables and restart Claude Code:

unset ANTHROPIC_BASE_URL
unset ANTHROPIC_AUTH_TOKEN
unset CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY
unset CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS

Run /status after restart and confirm that the previous connection is active.

For the VS Code extension or Claude desktop Code, restore the previous environment or Third-Party Inference configuration, restart the application, and run the same status check.

References

These references were reviewed on September 9, 2026. Model availability can change, so use the current catalogue and an exact model ID visible to the intended key.

XiuAI and its products are operated by XiuLab Inc, a U.S. corporation.

One API Does Not Mean One Protocol: Chat Completions, Responses, Messages, and Gemini

Dashu — Sun, 30 Aug 2026 10:40:07 +0000

"OpenAI compatible" is useful shorthand, but it is not a complete integration contract.

Two clients can accept the same API key and base domain while sending different request paths, authentication headers, payload shapes, streaming events, and tool-call formats. That difference matters when you connect coding agents, SDKs, or production applications to a multi-model gateway.

At XiuAI, we expose four text-generation routes through XiuRouter:

OpenAI Chat Completions
OpenAI Responses
Anthropic Messages
Gemini GenerateContent

These are protocol routes, not a list of currently available model families. For example, a Gemini GenerateContent route does not establish that Gemini-family models are in the current catalog. Check the model list visible to your key.

The practical rule is simple:

Start with the protocol your client actually sends. Do not choose a protocol from the model name or from an "OpenAI compatible" label.

This article explains how to make that choice and how to verify the integration without turning a small configuration change into a production incident.

1. Choose the client protocol before the model

A model name does not determine the request protocol.

For example, the same model may be reachable through Chat Completions in one service group but not through Responses or Messages in another. A successful Chat Completions request is not proof that the same model and route will support Responses, Anthropic Messages, or Gemini GenerateContent.

Use the client's native behavior as the starting point:

Client or application	Preferred route
Codex configured with a Responses provider	OpenAI Responses
Claude Code, Anthropic SDKs, and Claude-native clients	Anthropic Messages
OpenCode and Vercel AI SDK using `@ai-sdk/openai-compatible`; other Chat Completions clients	Chat Completions
Gemini SDKs and Gemini-native clients	Gemini GenerateContent

The current OpenCode guide and Vercel AI SDK guide use Chat Completions through @ai-sdk/openai-compatible.

If the client documentation is unclear, inspect its official configuration guide or request logs. Do not infer the protocol from a generic compatibility badge.

2. Base URLs depend on what the client appends

An OpenAI-compatible SDK usually appends paths under /v1, so its configured base URL is:

https://router-api.xiu.ai/v1

A Claude client that appends /v1/messages, or a Gemini client that appends /v1beta/models/..., should use the API root:

https://router-api.xiu.ai

This is a common source of duplicated paths such as /v1/v1/messages, especially when a configuration field is called "API URL" without explaining whether it expects a domain, a base path, or a complete endpoint.

For direct requests, use the complete path:

Protocol	Method and path
Chat Completions	`POST /v1/chat/completions`
Responses	`POST /v1/responses`
Anthropic Messages	`POST /v1/messages`
Gemini GenerateContent	`POST /v1beta/models/{model}:generateContent`

3. Authentication is also protocol-specific

OpenAI-compatible requests use a Bearer token:

Authorization: Bearer YOUR_XIUROUTER_API_KEY

Anthropic Messages can use:

x-api-key: YOUR_XIUROUTER_API_KEY
anthropic-version: 2023-06-01

XiuRouter also accepts a Bearer token on the Messages route for gateway clients such as Claude Code.

Gemini GenerateContent can use:

x-goog-api-key: YOUR_XIUROUTER_API_KEY

Gemini's key query parameter is accepted as well, but headers are easier to keep out of access logs and copied URLs.

4. Run one small request on the exact production combination

Before moving application traffic, test the exact combination of:

API key
model ID
service group
protocol
streaming mode
tool or structured-output features you need

First list the models visible to the scoped key:

curl https://router-api.xiu.ai/v1/models \
  -H "Authorization: Bearer $XIUROUTER_API_KEY"

Then send one small request through the route your client will use. For Responses:

curl https://router-api.xiu.ai/v1/responses \
  -H "Authorization: Bearer $XIUROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "input": "Reply only with: XiuRouter connected"
  }'

For Anthropic Messages:

curl https://router-api.xiu.ai/v1/messages \
  -H "x-api-key: $XIUROUTER_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_ID",
    "max_tokens": 64,
    "messages": [
      {
        "role": "user",
        "content": "Reply only with: XiuRouter connected"
      }
    ]
  }'

After the response, verify the same request in usage records: key, model, service group, endpoint, token counts, status, and cost.

The small test is billable. Check the current model and service-group pricing before sending it.

5. Know the compatibility boundaries

A gateway route can support the core text request without implementing every provider feature.

Current XiuRouter boundaries include:

/v1/messages/count_tokens has no dedicated route. Claude Code documents token counting as optional and can fall back through inference, but you still need to verify that the final task completes.
The Responses route is stateless. Stored conversations, previous_response_id, and background mode are outside the current compatibility scope.
Some Responses models can use provider-hosted tools such as Web search. Check the intended model and service group, then verify the tool call count and its separate surcharge in Usage.
XiuRouter exposes Gemini GenerateContent, not the Gemini Interactions API.
Files, fine-tuning, image variations, and some legacy endpoints are not implemented by the current gateway.
Tool calls, structured output, prompt caching, streaming events, and token accounting can differ when an inbound request is converted to an upstream provider format.

These are not edge cases to hide in fine print. They determine whether an agent can finish a task, whether a retry is safe, and whether usage records match the client's expectations.

6. Use scoped keys and keep the rollback small

Create one key per application or environment. Limit models, service groups, quota, expiration, and IP scope where appropriate.

For a migration:

Keep the existing provider configuration available.
Add XiuRouter as a separate provider or environment.
Test a small non-critical task.
Compare output, streaming, tool calls, token accounting, latency, and cost.
Move traffic gradually.
Keep the previous provider as the rollback path until the new route has passed real workloads.

Changing only a base URL is convenient. Treating that change as proof of full protocol compatibility is not.

Reference

The current endpoint table and limitations are maintained in the XiuRouter API compatibility guide. The compatibility guide records its September 5, 2026 verification. This article was checked against the current published guides on September 19, 2026.

XiuAI and its products are operated by XiuLab Inc, a U.S. corporation.

DEV Community: XiuAI

How to Compare an AI Subscription Before You Buy

What the same price buys

Price, currency and support

Applying this comparison to another offer

A Practical Scoping Checklist for Enterprise AI Projects

Two use cases, with published package prices

1. Start with the customer-owned product

2. Separate model resources from application cost

3. Define deployment and ongoing service separately

4. Leave procurement until the scope is clear

A small intake that works

Where XiuAI fits

How to Compare LLM API Gateway Prices Without Mixing Models, Cache, and Routes

September 30 deadline for existing benefit-group users

A worked example: $35 versus $2.45

Why an input discount is not the whole bill

A discount percentage is not a price model

Separate the token buckets

Weight the comparison with a real workload

Keep reference prices traceable

Use the price available to your API key

Protocol compatibility is a separate decision

Verify the estimate against a real request

Include non-token costs explicitly

A practical comparison checklist

Usage records and conversation content

XiuRouter sources

How to Verify an AI Subscription Delivery Without Trusting a Status Label

Choose the account before the price

After payment, start with your order

Confirm the subscription on the account you will use

How to Connect Codex to a Custom Responses API Provider and Verify the Route

The configuration has four separate decisions

Keep the API key out of config.toml

Start with a reversible configuration

Verify the provider in a new task

Diagnose failures by boundary

401 Unauthorized

The model is missing or rejected

The request hits the wrong URL

A simple prompt works, but an agent task fails

The route works, but long tasks are unstable

A practical acceptance checklist

XiuRouter-specific setup

A Delivery Label Is Not a Fulfillment Model

The three facts a digital order needs

1. The offer the buyer accepted

2. The current order state

3. The workflow used to complete delivery

Use a delivery type, not a marketing sentence

Keep the snapshot, but do not replay every old label

Render instructions from one policy

Test the buyer path, not only the API response

What buyers should see before paying

A compact acceptance checklist

A 200 Response Is Not Enough: Testing Claude Code Through an Anthropic Gateway

Configure the API root, not the Messages path

Test /v1/messages before opening Claude Code

Then test the Claude Code workflow

Treat count_tokens 404 as a workflow signal

Failure patterns and the shortest useful check

401 or invalid token

Gateway models do not appear

The request path is /v1/v1/messages

A 400 response names experimental fields

HTTP 200 contains HTML

Direct Messages works, but Claude Code still fails

Roll back without leaving mixed credentials

References

One API Does Not Mean One Protocol: Chat Completions, Responses, Messages, and Gemini

1. Choose the client protocol before the model

2. Base URLs depend on what the client appends

3. Authentication is also protocol-specific

4. Run one small request on the exact production combination

5. Know the compatibility boundaries

6. Use scoped keys and keep the rollback small

Reference

Keep the API key out of `config.toml`

`401 Unauthorized`

Test `/v1/messages` before opening Claude Code

Treat `count_tokens` 404 as a workflow signal

`401` or invalid token

The request path is `/v1/v1/messages`

A `400` response names experimental fields