Tencent’s Hy4 preview is a 770B open model. The real test is deployment.

Tencent’s latest open-weight model is promising on coding and tool-use evaluations, but the number that decides whether you can run it is not 49B. It is the weight footprint, runtime, and workflow around the model.

Three things to know

• Hy4 preview is a 770B Mixture-of-Experts backbone with 49B active parameters per token and a 1M-token context. The 49B figure is a routing figure, not the size of a 49B dense model you can casually load.
• Tencent’s benchmark story is strong but self-reported. Its internal blind test put Hy4 slightly ahead of GLM 5.3 and Kimi K3 on a 203-task engineering mix; the public benchmark appendix is an image, not a reproducible evaluation package.
• The practical entry point is a managed product or API. Tencent documents an eight-way tensor-parallel serving path, while the public weights are roughly 1.56TB in BF16/F32 and 814GB in FP8 before runtime overhead.

The short decision is simple: try Hy4 preview through WorkBuddy, CodeBuddy, TokenHub, or OpenRouter first. Consider self-hosting only if you already operate a serious multi-GPU system and need the control badly enough to own the operational burden.

What is Tencent Hy4 preview?

Tencent released Hy4 preview on 28 August 2026 as the new flagship from its Hy team. The official release describes a 770B-total, 49B-active model with a context window exceeding one million tokens, aimed at software engineering, office analysis, game development, and scientific research. It is available as open weights under the Apache 2.0 licence, alongside hosted access through Tencent products and APIs. Tencent’s release

The technical detail that matters is the gap between total and active parameters. Hy4 has 78 backbone layers: the first uses a dense feed-forward network, while the remaining 77 use Mixture-of-Experts layers. Each MoE layer has 256 routed experts and one shared expert; each token selects the top eight routed experts plus the shared expert. The model card also lists a separate 10B-total, 0.7B-active native multi-token-prediction layer for speculative decoding. Official model card · Tencent GitHub README

That design can reduce how much expert computation each token touches. It does not remove the need to store the wider expert pool. By simple arithmetic, 49B is about 6.4% of the 770B backbone; that ratio is useful for understanding routing, but it is not a hardware requirement.

Figure 1 — The active-parameter number explains per-token routing. The total-parameter number still drives checkpoint storage and much of the serving envelope. Source: Tencent model card; the active-share percentage is an EyesTech calculation.

The benchmark headline is “competitive,” not “proven best”

Tencent’s closest apples-to-apples evidence is a blind side-by-side evaluation inside the company. It says 163 internal experts rated outputs on 203 engineering tasks. Hy4 preview averaged 2.99 out of 4, compared with 2.92 for GLM 5.3 and 2.94 for Kimi K3. Against GLM 5.3, Tencent reports 46.8% Hy4 wins, 12.8% ties, and 40.4% losses. Against Kimi K3, it reports 51.2% wins, 7.9% ties, and 40.9% losses. Model-card evaluation section

That is meaningful product evidence: the model was judged on work Tencent says resembles real engineering tasks, not only on academic multiple-choice questions. It is also a narrow margin in an internal study. The public page does not expose the full task set, prompts, annotator agreement, confidence intervals, or an external replication. The correct reading is “competitive in this tested mix,” not “Hy4 has settled the model race.”

Figure 2 — Tencent’s official internal comparison. The margins are close, and the evaluation protocol is not fully public.

The model card’s benchmark appendix adds a more dramatic generation-over-generation picture. Public transcriptions of the image report Hy4 at 85.4 on Terminal-Bench 2.1, 64.3 on DeepSWE, 53.3 on SWE Atlas Refactoring, 74.1 on Toolathlon-Verified, 37.1 on APEX-Agents pass@1, 65.4 on OneMillionBench with tools, 17.5 on ProgramBench, and 22.8 on Agents’ Last Exam. The official benchmark image and appendix are the primary sources; BenchmarkList and a public transcription make the image easier to read.

Those values should carry a visible caveat: they are Tencent/model-card figures, not an EyesTech rerun. The comparator scores in public transcriptions are also reported as Tencent-run at each model’s highest available reasoning setting. The chart mixes resolved rates, pass@1, pass@4, and Elo; there is no defensible single “overall score” without a pre-registered normalization and weighting scheme.

Figure 3 — Recreated from the vendor appendix and public transcriptions. The large DeepSWE and agent-task jumps are interesting; they are not independent reruns. The OneMillionBench baseline has appeared as 51.5 and 51.6 in public transcriptions, so its delta is illustrative rather than settled.

The benchmark pattern is still useful. Hy4’s strongest public story is not generic trivia. It is long-horizon work: shell tasks, code refactoring, tool use, and large-context workflows. That aligns with the product design Tencent describes. It also means a buyer should test the model on a fixed workflow rather than assume that a high score on one agent benchmark transfers to every repository, toolchain, or language.

X is talking about the model’s workflow, not only its parameter count

The public conversation formed around the same deployment question that the benchmark chart leaves open.

The official launch post from @TencentHunyuan was showing about 2.3 million views, 5,341 likes, 973 reposts, and 1,012 bookmarks when checked on 2 September. Its promise was compact: 770B total, 49B active, 1M context, open weights, productivity, and “tell us what breaks.” Those figures are a time-stamped X observation, not a quality metric.

The follow-up quantization post had about 486,000 views, 1,808 likes, 273 reposts, and 620 bookmarks at the same check. Tencent said its MIX-STQ1_0 build compressed Hy4 from roughly 1.5TB to about 200GiB and showed small changes on selected MCP Atlas, SWE-bench Multilingual, MRCR, and IFBench numbers. That is the most interesting post-launch claim because it points toward a new deployment envelope. It is still a selected-metric vendor claim, not proof that every long agent trajectory loses only a small amount of quality.

The visible replies and demos make the boundaries more concrete:

• Sakura Bonsai is described by Ivan Fioravanti as a single-file Three.js diorama built with Hy4 through WorkBuddy. The post includes the prompt and a 64-second video.
• Pagoda Temple is described by Diwakar Ray Yadav as a Three.js build created, checked, and verified in WorkBuddy. The author reports 1 hour 27 minutes of agent work—useful as a workflow-duration signal, not raw model latency.
• San Francisco — Spider-Man traversal is a public, playable web artifact with swinging, camera orbit, movement, jump, flight, and glide controls. Its source repository is inspectable.
• Two public WorkBuddy pages—Pixel Tank: Base Defense and Pixel Racer—were reachable during this research pass. The former rendered a playable tank game with keyboard/touch instructions; the latter exposed a public pixel-racing page.

These are better than static “look what the model made” screenshots because they expose interaction. But they are still model-plus-agent-system demonstrations. WorkBuddy edits files, previews pages, runs checks, and repairs failures. That is precisely the product experience many readers care about, yet it is not the same as isolating Hy4’s raw coding ability. The public artifacts do not disclose a controlled prompt suite, model settings, full edit history, or manual changes. Even the Pixel Racer host blocked source inspection during this run, so this article does not claim that page uses Three.js.

One recurring complaint in the X conversation was the friction around access: Linux support, model-list availability, queueing, and the meaning of “free.” A reply on the official WorkBuddy post described a missing Hy model in a CLI list and confusion about the free promise. It was a low-engagement anecdote, not evidence of a platform-wide failure. The broader signal is more useful: the impressive demo is inseparable from the product surface that makes the model usable.

The deployment boundary is the story

Tencent’s official serving recipe recommends vLLM or SGLang and shows tensor parallelism across eight devices for the FP8 checkpoint. It also includes Hy4-specific reasoning and tool-call parsers plus speculative decoding settings. Official vLLM/SGLang recipe

The public artifacts show why. The Hugging Face repository is roughly 1.56TB for the BF16/F32 checkpoint and around 814GB for FP8. Those are observed file footprints, not a minimum VRAM recommendation. A simple 770B × 2-byte estimate gives about 1.54TB before metadata, activations, KV cache, runtime buffers, and headroom; a 1-byte estimate gives about 770GB. Even the optimistic arithmetic is server-scale.

The community quantized path is more interesting, but it changes the adjective from “impossible” to “specialized,” not to “laptop.” AngelSlim’s public Hy4 GGUF page lists variants around 435.20GiB at Q4_K_M and 213.66GiB at STQ1_0, with Hy4-specific runtime patches and an 8× H20 measurement. The files may fit inside a large pooled-memory system, but quality, latency, interconnect, and concurrency remain workload questions.

For most teams, the API is simpler. OpenRouter listed Hy4 at $0.834 per million input tokens, $2.501 per million output tokens, and $0.042 per million cached input tokens, with a 1,048,576-token context and 64,000-token maximum completion. OpenRouter’s live listing is dynamic and should be checked again before publication. Tencent’s own Cloud API guide describes roughly 960K maximum input and 64K maximum output on its compatible route, so “1M context” is a configuration headline—not always the same usable prompt budget. Tencent Cloud’s displayed Guangzhou rate card separately lists ¥6/M input, ¥18/M output, and ¥0.3/M cached input. Tencent Cloud pricing

For Indian builders, the important distinction is not a currency conversion. It is that the public evidence supports an API investigation, not an India-local deployment claim. Region, payment method, GST, data residency, latency, SLA, and local hardware supply need to be checked separately. The Chinese yuan price is not an Indian rupee quote, and an eight-GPU self-hosted server needs a verified supplier/configuration before anyone can write a trustworthy rupee TCO.

Figure 4 — Deployment envelope synthesized from official serving guidance, observed provider listings and raw-weight arithmetic. Memory figures are estimates before runtime overhead; prices and availability are time-sensitive.

Which route should you choose?

The sensible order is to start managed, move to API when the workflow is known, and self-host only when control economics justify the cluster. That is not a downgrade of the open-weight release. It is what the release’s own system requirements imply.

What this changes

Hy4 preview shows where open models are heading: not simply toward bigger chat checkpoints, but toward model-and-agent systems that can hold a large working set, call tools, edit files, run tests, and return artifacts. Tencent’s training data and product co-design emphasize software engineering, office analysis, games, finance, and security rather than a generic “ask me anything” demo.

The open-weight label also deserves precision. Apache 2.0 weights and serving code are genuinely useful. They do not by themselves provide a fully reproducible training run, public training data, or a low-cost local experience. A model can be open to inspect and still be expensive to operate.

The next evidence target is straightforward: run Hy4 and two peers on the same small, public task suite and publish task success, latency, output tokens, tool retries, human cleanup, and API cost. Until that exists, Hy4 should be treated as a promising frontier candidate with a clear deployment constraint—not as a settled winner.

Who should care?

• Agent and coding builders: Hy4 is worth a controlled API or WorkBuddy trial for long-horizon repository, tool, and frontend work.
• Infrastructure teams: budget for the total checkpoint and runtime, not the 49B active figure alone.
• Founders and product leaders: the workflow surface may matter more than the model card; test completion time and human repair cost, not only benchmark scores.
• Indian teams: verify routing, billing, residency, latency, and local hardware before committing to a regional deployment assumption.
• Researchers and benchmark readers: preserve source provenance and metric type; do not average mixed vendor-reported scores into one leaderboard.

EyesTech Method Card

• Question: Is Hy4 preview practically usable for builders, and which deployment route is realistic?
• Model/version: Tencent Hy4 preview, public release dated 28 August 2026; research checked 2 September 2026.
• Evidence: Tencent release, official Hugging Face model card, Tencent GitHub README, Tencent Cloud documentation, OpenRouter listing, official X posts, public demo pages, and secondary transcriptions.
• Observed vs claimed: File sizes, public page titles/controls, X engagement snapshots, and listed prices are observed; benchmark and internal blind-test numbers are official/vendor claims; weight-size arithmetic is estimated.
• Direct inference: No first-hand EyesTech inference run was performed. This is an analysis, not a review or independent benchmark.
• Limitations: Image-only benchmark appendix, no public task-level internal-eval protocol, changing provider telemetry, limited public demo provenance, and no verified India-local endpoint or hardware quote.
• Confidence: Medium. High for model identity/specifications; medium for deployment implications; exploratory for claims about real-world superiority.

Update note: Recheck API prices, provider availability, free-access dates, GGUF files, and public benchmark status before publication. Revisit this article in 30 days for independent long-horizon results and support in mainstream runtimes.

Suggested internal connection: EyesTech’s developer-workflow analysis adds adjacent context on how model choice becomes a full software workflow. Use the EyesTech homepage as the hub until a dedicated Model Reality Index URL exists.

Get the EyesTech Signal for follow-ups on model behavior, hardware limits, and deployment economics.