Hy4 Preview — Tencent Hunyuan 4 Model

What is Hy4 Preview?

Announced by Tencent in its Q2 2026 earnings call and now in grey-testing, Hy4 is positioned as an "expert-level" model above Hy3 — with larger parameters, stronger reinforcement learning, and upgraded multimodal capabilities. It serves as the core engine of Tencent's WorkBuddy agent application. According to the official research page, Hy4 Preview is a new-generation Mixture-of-Experts (MoE) flagship model developed by the Tencent Hy Team.

Hy4 Architecture (Official Specs)

The model comprises 770B total parameters, of which 49B are activated per token. Its backbone consists of 78 layers:

• Layer 1: a standard dense FFN (Feed-Forward Network).
• Layers 2–78: replaced with Mixture-of-Experts — each containing 256 routed experts + 1 shared expert.
• Every token activates the top-8 routed experts along with the shared expert.

In addition to the backbone, 1 native MTP layer (Multi-Token Prediction, 10B total parameters, 0.7B activated) is built in for speculative decoding — accelerating inference by predicting multiple tokens ahead.

Model Specifications

Hy4 Preview vs. Other Flagship Models

Hy4 targets complex reasoning, coding, and agent scenarios — competing directly with DeepSeek, Kimi, and GPT-class frontier models. Full benchmark comparison on our Hy4 vs DeepSeek page.

How to Access the Hy4 API

The model is currently delivered as a hosted API rather than a local download. Its model ID is tencent/hy4-preview, and the endpoint below follows the familiar OpenAI chat completions format. Existing clients can usually switch models by changing the base URL and model name instead of adopting a new SDK.

curl https://tokenra.io/v1/chat/completions \
  -H "Authorization: Bearer $TOKENRA_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"tencent/hy4-preview","messages":[{"role":"user","content":"Hi"}]}'

Create an account at tokenra.io/register to obtain access credentials, then keep the key in a server-side environment variable such as TOKENRA_KEY. Do not place a production key in browser JavaScript or a public repository. See the API docs for gateway-specific headers, streaming options, rate limits, and error responses.

What the Specifications Mean in Practice

The headline parameter count describes the capacity of the complete network, not the amount of computation used by every token. In a Mixture-of-Experts design, a router selects a small group of specialist feed-forward networks for each token. The listed 770B total parameters and 49B activated per token provide a large pool of learned capacity while limiting the active path for each step. Parameter totals alone do not predict latency, memory needs, or answer quality.

The first backbone layer uses a dense FFN. Layers 2 through 78 use 256 routed experts and one shared expert per layer, with the top eight routed experts selected alongside the shared path. The shared expert gives every token a common representation while routed experts can specialize in different patterns. This is an architectural description, not a promise that every request will be faster or more accurate. Real-world behavior depends on the gateway, hardware, prompt length, batching, and system instructions.

A native Multi-Token Prediction layer is also listed as part of the design. MTP can support speculative decoding by proposing several future tokens for verification, which may improve serving efficiency when the provider enables it. It does not change the maximum context or guarantee a fixed response time for every workload.

A context window of 1,048,576 tokens is useful for long technical documents, repository-level code review, research notes, and multi-step agent state. Sending a very large prompt costs more and may increase latency. A 64,000-token maximum output is a ceiling, not a target; applications should set an appropriate output limit and stream responses when supported. The gateway may impose its own request, timeout, file, or rate limits.

Use Cases and Evaluation Notes

This service is a candidate for tasks that benefit from long context and deliberate multi-step reasoning: navigating a large codebase, drafting an implementation plan, extracting relationships across lengthy documents, or coordinating tools in an agent workflow. Coding teams can test it on bug diagnosis, refactoring proposals, and test generation. Product teams can compare it on support workflows that require a long conversation history. These are sensible evaluation areas, not claims that it wins every benchmark.

A useful trial should measure grounded accuracy, tool-call reliability, structured output validity, first-token latency, total completion time, and cost per successful task. Compare the same prompts and context against smaller models that may be cheaper for routine requests. Test failure cases such as ambiguous instructions, unsupported claims, malformed JSON, prompt injection, and context close to the provider limit.

Because this is a preview service, availability, pricing, supported features, and model behavior can change. Before sending private data, review the selected gateway's retention and processing terms. Before deployment, confirm current input and output prices, regional availability, uptime expectations, concurrency limits, streaming support, and tool calling. The comparison table is a positioning guide; benchmark results should come from a reproducible test set.

Frequently Asked Questions