Hy4 preview API guide: access, pricing, and a safe first call
A practical guide to trying Tencent Hunyuan Hy4 preview, reading its pricing, and choosing hosted API versus self-hosting.
After Hy4 preview launched, developers have three sensible starting points: try it in WorkBuddy or CodeBuddy, call it through TokenHub or OpenRouter, or download the open weights and operate the stack yourself. The right choice depends on whether you are evaluating behavior or preparing a product integration.
Key takeaway
- Hosted access is the fastest way to measure behavior before buying infrastructure.
- A 49B active count does not remove the memory and networking cost of a 770B MoE.
- Confirm model availability in the live catalog and API response; do not infer integration from an announcement.
- Keep keys server-side and record request IDs, tokens, latency, retries, and quality.
Tencent lists ¥6 per million input tokens, ¥18 per million output tokens, and ¥0.3 per million cached input tokens. Real workflow cost also includes retries, tool calls, and context management. A cheap request that loops repeatedly can cost more than a single expensive completion.
For a first run, set a token budget, timeout, retry limit, and human escalation rule. Record the model version, provider, request ID, input and output tokens, cache hits, latency, and final status. Repeat the same task with a control model before drawing a conclusion.
TokenHub fits teams already using Tencent Cloud billing and controls. OpenRouter fits developers with an existing multi-provider client and routing layer. In either case, keep long-lived keys on the server and never expose them in browser code.
If the model appears in SandBase’s live catalog and API response, a gateway can help compare providers while retaining usage and failure records. Confirm that availability from the live API; do not infer an integration from a launch announcement.
Figure 1. A catalog page is useful for checking what a platform exposes, but the live API response remains the authority for an integration claim.
Self-hosting requires a separate capacity calculation. A 770B MoE model still needs substantial weight storage, memory bandwidth, interconnect, and KV-cache capacity even when 49B parameters are active per token. Quantization quality, concurrency, upgrade work, and observability belong in the estimate too.
Figure 2. A hosted model entry can shorten the first experiment; verify pricing, limits, and model identifiers at request time.
Before production, validate schema adherence, citation quality on long inputs, failure recovery, spend, and latency on a bounded replayable task. Tencent calls Hy4 preview an early release and notes overthinking and excessive self-verification, so keep approval, logs, and rollback paths in place.
Bottom line: start with a hosted trial, measure the cost of a successful workflow, and choose API routing or self-hosting only after the data, reliability, and permission boundaries are clear.
A first-call checklist that produces useful evidence
Start with a task small enough to finish in one sitting. A good fixture has a fixed input, a visible success condition, and at least one failure case. For example, ask the model to inspect a repository, change one function, run the existing tests, and return a patch plus a short explanation. The fixture should not require broad network access or a production credential. If the model cannot finish this bounded loop, a larger autonomous workflow will only make diagnosis harder.
Before sending the request, freeze the prompt and tool schema in a file. Capture the exact provider endpoint, model identifier, temperature or reasoning settings, and the commit used for the test. A second run with the same fixture should be comparable; otherwise latency and cost numbers are anecdotes. Keep the raw request and response in a private test log, redacting customer data and credentials.
Hosted routing versus open weights
Hosted access is usually the fastest way to learn whether Hy4 preview’s long-context and productivity claims matter for your workload. It shifts hardware, model loading, and upgrades to the provider, but adds dependency on endpoint availability, queueing, and provider-specific limits. Ask the provider for context limits, rate limits, retention policy, and error semantics before wiring it into a user-facing path.
Open-weight deployment gives you more control over locality, batching, and instrumentation. It also makes the model’s 770B total parameter footprint an operational concern: active parameters reduce compute per token, but they do not eliminate weight memory, KV cache, interconnect, or replica costs. Benchmark a representative concurrency level, not a single warm request. Include cold start time, health checks, model reload behavior, and the cost of keeping capacity online.
How SandBase can fit
If Hy4 preview is available in the live SandBase catalog, the gateway can provide a common request contract while the application keeps provider credentials server-side. That is useful for replaying the same fixture against Hy4 and a control model, comparing successful-workflow cost, and preserving a request ID across retries. It is not a substitute for confirming model availability or for reproducing provider-specific behavior. Check the live catalog and API response on the day of integration.
Official links
Figure 3. The primary research page provides the release context; it does not by itself prove that every hosted route supports the same parameters.
