Purchasing and API integration FAQ

Practical answers for teams evaluating the API or wiring it into an existing product.

1. 1

   Which models can I call?

   Every model listed on Model Square is available through the API, covering chat, reasoning, vision and video generation from Chinese vendors. The catalogue is the source of truth: if a model has a listing with pricing, it is enabled on the platform.

2. 2

   Where do I find the model ID?

   Open the model’s entry in Model Square and copy the identifier shown there. Pass that exact string as the model value in the request body. IDs stay stable; when one is retired we keep it routable for a notice period so existing integrations have time to migrate.

3. 3

   Which API formats are compatible?

   Three request shapes are supported: OpenAI-compatible Chat Completions at /v1/chat/completions, Anthropic Messages at /v1/messages, and Gemini-style generateContent. Pick whichever your existing SDK already speaks; text, image input and tool calls all work through the same endpoint.

4. 4

   How do I authenticate?

   Create a key in Console → API Keys. Send it as Authorization: Bearer … for OpenAI- and Gemini-shaped requests, or x-api-key for Anthropic-shaped ones. Keys belong to your account, can be named per environment, and can be revoked at any time without affecting other keys.

5. 5

   Is streaming supported?

   Yes. Set stream: true and the response arrives as server-sent events in the same delta format as the compatible API you chose. Tokens already emitted are billed even if the client disconnects early, so close the stream deliberately when you cancel.

6. 6

   Can I use tool calling and function calling?

   On models that support it, yes. Pass tools in the OpenAI request shape and read choices[].message.tool_calls. Through the Messages endpoint the same capability surfaces as tool_use blocks. Tool support is listed per model — do not assume every model accepts tools.

7. 7

   Can I request JSON or schema-constrained output?

   Models with a native JSON mode accept response_format. Where the upstream model has no strict mode, the schema is passed as an instruction instead, which improves consistency but does not guarantee it. Validate every response before parsing, regardless of the model.

8. 8

   What context window does each model have?

   The maximum input and output sizes are shown on each model’s listing in Model Square. Requests that exceed the window fail with a 400 and a message naming the limit; they are never silently truncated. Count your prompt with the tokenizer listed for that model before sending very large inputs.

9. 9

   How are tokens counted and billed?

   Input and output tokens are counted separately and priced per million tokens at the rates shown on Model Square. Video models are billed per call or per second of output. Each request records its usage immediately, visible in usage logs. Requests that error before producing any tokens are not charged.

10. 10

    What rate limits apply?

    Each key has a requests-per-minute and a tokens-per-minute limit that depends on your account tier. Every response carries the current limits and remaining headroom in x-ratelimit-* headers. If your workload needs more than the published ceiling, contact us with expected volume and we will review the tier.

11. 11

    What happens when a request fails?

    A 4xx means the request itself is the problem — an invalid key, a malformed body, an unsupported parameter or an over-long prompt. A 5xx or a timeout means the failure is on our side or the upstream provider’s. Retry 429 and 5xx responses with exponential backoff and an idempotency key where the API supports one; do not retry 4xx unchanged.

12. 12

    How fast are responses?

    Time to first token depends on the model, prompt length and current load, and varies more between models than between requests. Streaming is the honest way to measure it. We do not add artificial delay or queue requests for capacity reasons without telling you; observed latency for your account is visible in the console.

13. 13

    What is model fingerprinting?

    Some upstream providers return a revision marker — a system_fingerprint or equivalent — identifying the exact backend that served the request. We pass it through unchanged and do not add a fingerprint of our own, so you can detect when a provider swaps revisions and correlate changes in output.

14. 14

    Does the output match the upstream provider exactly?

    Requests are forwarded to the provider’s own weights without rewriting the generated text. Small differences can still appear if the provider has rolled to a new revision or if the gateway fills in a default sampling parameter you did not set. Pin the parameters you care about explicitly — temperature, top_p, max_tokens — when reproducibility matters.

15. 15

    Does the API expose features beyond the upstream model?

    We keep the surface close to the compatible specifications. Additions such as usage metadata, request IDs and provider routing information are additive and documented, and never change the meaning of a standard field. If we introduce an extension, requests that do not use it behave exactly as before.

Purchasing and integration enquiries: support@chinesemodels.ai