Why does a 770B open model matter now?
A 770 billion parameter model is significant because it changes what developers can access, not just what a benchmark can measure. Tencent has released Hy4 as an open-weight model, which means developers can download its weights instead of using it only through a closed API. They can also test it through WorkBuddy, CodeBuddy, Tencent Cloud TokenHub, and OpenRouter.
The surprising detail is that Hy4 does not use all 770 billion parameters on every request. It uses a mixture-of-experts design with 78 layers, 256 routed experts, one shared expert, and top-8 routing for each token. Only 49 billion parameters are active on each pass. That makes the model large in total capacity while limiting the computation needed for an individual response.
Its 1 million-token context window matters just as much. A model that can process very large amounts of code or project material can work across longer tasks without repeatedly losing earlier details. Tencent says Hy4 can orchestrate multiple OpenAI Codex sessions and outperform Codex alone across eight benchmarks. Those are Tencent’s claims, but they point to a different role for an open model: coordinating tools and other coding agents, rather than simply answering one prompt.
Cost also changes the calculation. Tencent’s listed API price is $0.834 per million input tokens and $2.501 per million output tokens. Developers can try it free for two weeks in WorkBuddy and CodeBuddy before committing.
The takeaway is simple: Hy4 matters now because openness, long context, low pricing, and agent coordination are arriving together. The model is not only a large set of weights. It is a practical alternative to defaulting to a closed frontier model.
What does Hy4 actually activate on each request?
Hy4 has 770 billion total parameters, but it does not use all 770 billion for every token it processes. Its mixture-of-experts, or MoE, design activates about 49 billion parameters per token. That difference is central to understanding the model’s size.
The architecture is spread across 78 layers. At each layer, tokens are sent through selected parts of the network rather than through every available expert. Hy4 has 256 routed experts and one shared expert, with top-8 routing per token. In plain terms, the model chooses eight routed experts for each token, while the shared expert remains part of the common processing path.
This makes Hy4 both very large and selective. The full 770B parameter count describes the total pool of learned capacity. The 49B active count describes the portion used during one pass for one token. A request can therefore draw on a broad collection of specialized knowledge without paying the compute cost of running every parameter every time.
The same distinction matters when evaluating infrastructure. A 770B model still represents a major serving challenge, even if only 49B parameters are active per token. The model must still manage its expert weights and route tokens across them. The research material does not provide a full hardware or latency breakdown, so the active count should not be treated as a complete estimate of serving cost.
Hy4 also supports a context window exceeding 1 million tokens. That lets it process very large codebases, long agent traces, or extensive research documents, but context length and active parameters describe different things. One measures how much input the model can handle. The other measures how much of its network is used for each token.
The takeaway is simple: Hy4’s headline size is its total capacity, while 49B is its per-token working set.
How does a 1 million token context window change engineering work?
A 1 million token context window changes the unit of work from a single file or prompt to an entire engineering task. Developers can provide large amounts of source code, logs, tests, documentation, and command output in one request. The model has more of the surrounding situation available before it proposes a change.
The surprising part is that more context does not automatically mean faster delivery. A model can inspect more evidence, but it may also spend more time checking that evidence. Hy4 Preview shows this tradeoff clearly. Its score on the DeepSWE benchmark, which focuses on real-world software engineering tasks, rose from Hy3’s 28.0 to 64.3. On Terminal Bench 2.1, it scored 85.4, surpassing DeepSeek V4 Pro and tying with Claude Opus 5. Those results suggest stronger performance on tasks that require navigating repositories and using command-line tools.
For a daily engineering workflow, the benefit is less copying and splitting. A developer may not need to summarize every relevant file or manually decide which logs matter. The model can work from a broader record of the problem, which is useful when a bug crosses configuration, application code, tests, and runtime output.
But the same breadth creates a practical cost. The research reports that Hy4 Preview tends toward over-verification, which prolongs response times. Visual input support is also absent in this preview, so a large text window does not cover every kind of project evidence.
The takeaway is simple: one million tokens can reduce the work needed to prepare context, but teams still need to manage review time. More memory helps the model see the task. It does not remove the need to decide when enough checking is enough.
Why is Tencent positioning Hy4 as an agent manager rather than a chatbot?
A chatbot mainly answers the prompt in front of it. Tencent is presenting Hy4 as something broader: a model that can support multi-step work across coding, office tasks, scientific research, and software engineering.
The distinction comes from Hy4’s design and integrations. The preview has 770 billion total parameters, with 49 billion active parameters, and supports more than one million tokens of context. That gives it room to work with large codebases, long research materials, or extended task histories without reducing everything to a short exchange. Its reported strengths include understanding, planning, and debugging in software engineering, not just producing isolated code snippets.
The training data also points toward this role. Tencent says Hy4 was developed with high-quality data from its software engineering, gaming, finance, and security teams. Those areas involve processes, tools, and decisions that unfold over several steps. Hy4 is also integrated with products such as WorkBuddy and CodeBuddy, while access is available through Tencent Cloud Tokenhub and OpenRouter. In practice, that places the model inside work systems rather than leaving it as a standalone chat window.
This matters for Codex-style use because coding work rarely ends with one generated answer. A useful system must understand the task, make a plan, inspect relevant context, help implement changes, and assist with debugging. The available information does not establish that Hy4 autonomously performs every one of these actions, but Tencent’s positioning clearly emphasizes that kind of workflow.
The takeaway is simple: Hy4 is being framed less as a conversational endpoint and more as the reasoning layer behind connected work tools.
What does the Codex orchestration claim mean in practice?
“Codex orchestration” suggests a model that does more than generate a code snippet. In practice, the useful claim is that Hy4-preview can help coordinate several parts of software work: understanding an existing codebase, forming a plan, debugging failures, and producing code. Tencent describes these capabilities as part of its software engineering focus, with deeper integration into products such as WorkBuddy and CodeBuddy.
The important detail is that orchestration does not automatically mean full autonomy. The available information does not establish that Hy4-preview independently runs an entire development process, edits files, executes tests, and approves a final change without human input. A safer reading is that the model is designed to support a longer sequence of engineering tasks instead of answering one isolated programming question at a time.
Its more than one-million-token context window could make that workflow more practical. A model with that much context can receive substantially more project material in one request, such as source files, requirements, error output, and related documentation. That may reduce the need to repeatedly summarize a repository or paste small sections of code. The model still needs a product layer, such as WorkBuddy or an API client, to provide files, tools, permissions, and feedback.
This distinction matters for architecture. The 770B total parameter count is less important to a developer than whether the surrounding system can turn model output into reliable actions. Hy4-preview is available through Tencent Cloud Tokenhub and OpenRouter, while WorkBuddy and CodeBuddy provide more direct product integration. The practical takeaway is simple: orchestration means supporting the whole reasoning workflow, but the surrounding tools still determine how much of that workflow can actually run automatically.
Where does Hy4 outperform, and where can verification slow it down?
Hy4 preview’s clearest advantage appears in engineering work. Tencent reports a score of 2.99 out of 4 on an internal rubric covering 203 engineering tasks, graded by 163 experts. That placed it ahead of GLM 5.3 at 2.92 and Kimi K3 at 2.94. Tencent also says Hy4 helped optimize parts of its own training and inference systems, raising end-to-end throughput by 31.8% against a baseline.
The model’s design helps explain why it can handle broad coding tasks. It has 770 billion total parameters, but activates 49 billion per token. Its 78 layers include 77 mixture-of-experts layers, each with 256 routed experts and one shared expert. This gives the model a large pool of specialized capacity without using every parameter for every token. Its 1 million token context also gives coding agents room to retain large repositories, logs, and task history.
The harder question is verification. A model that manages Codex-style work must do more than generate code. It must inspect files, run checks, interpret failures, and revise its plan. Those steps add calls, tokens, and waiting time. Hy4’s 1 million token window can hold more evidence, but processing that evidence still has a cost. Verification can therefore reduce the practical speed advantage, especially when a task requires several rounds of testing.
Deployment also matters. Tencent provides vLLM and SGLang Docker images, an FP8 variant, AngelSlim compression tools, and an OpenAI-compatible endpoint. These options make self-hosting more accessible, but the 770B model remains a substantial system to operate. The takeaway is simple: Hy4 looks strongest when engineering quality matters, while verification determines how much of that quality users receive per unit of time and cost.
How do the open weights and API prices change model selection?
Model selection is no longer only about which model scores highest. Hy4 preview changes the decision by offering both open weights and a paid API, giving teams two different ways to use the same model.
The open release makes Hy4 preview a candidate for teams that need more control over deployment, data handling, or integration. It has 770 billion total parameters, with 49 billion activated parameters, and a context window exceeding 1 million tokens. Those details matter for large codebases, long research documents, and data-heavy workflows. But open weights do not make deployment free or simple. Teams still need to evaluate infrastructure, operations, and performance for their own workloads. The research does not provide those costs, so the sensible choice is to test before committing.
The API offers a lower-friction path. Tencent prices Hy4 preview at $0.834 per million input tokens and $2.501 per million output tokens. Output is roughly three times more expensive than input, which makes response length an important part of budgeting. A workflow that sends large files but requests short answers may fit the pricing well. An agent that repeatedly generates long code or analysis may not.
There is also a limited two-week free period through WorkBuddy and CodeBuddy, while API access is available through Tencent Cloud TokenHub and OpenRouter. That gives teams a practical way to measure quality before paying for scale.
The key takeaway is simple: open weights favor control, while the API favors speed. Hy4’s reported expert score of 2.99 out of 4 is useful evidence, but each team still needs to compare deployment effort, token costs, and actual task performance.
What will it take to run or integrate a model this large?
Running Hy4 preview is not the same as downloading an ordinary open model. Tencent has released weights for a 770 billion parameter system, even though only 49 billion parameters are active for each token. That mixture-of-experts design reduces the work required for each response, but the full model still has 770 billion parameters that a deployment must make available.
This is the important distinction: active parameters affect serving work, while total parameters affect the model’s footprint. Hy4 has 78 layers and 256 routed experts. A request uses selected experts rather than all of them, which keeps serving costs far below those of a dense model with the same total size. Even so, teams need infrastructure capable of hosting and routing a model at this scale. The research does not specify hardware, memory requirements, quantization options, or a reference deployment, so those practical details cannot be assumed from the parameter count alone.
The one million token context creates another integration concern. Coding, office work, data analysis, and scientific research can involve large collections of files or long-running work sessions. Hy4 is designed to accept that much context, but applications still need to decide what information to send, when to preserve it, and how to control the cost of each request.
For a Codex-style workflow, the model would need to sit inside an application that supplies code, task instructions, and relevant project material. The Apache-2.0 license makes that kind of integration possible, subject to the license terms. The practical lesson is simple: Hy4 may be open to use, but operating it remains an infrastructure project, not a routine model download.
Which teams stand to benefit most from Hy4?
Hy4 is most useful to teams whose work is both large and varied. Tencent positions the model for coding, office work, data analysis, and scientific research, while its context window exceeds 1 million tokens. That combination matters when a task cannot be reduced to a short prompt and a few pasted files.
Software teams could use Hy4 with very large codebases, technical documentation, and related project material in one context. The model’s 770 billion total parameters and 49 billion active parameters per token also make its design unusual: it has a large pool of specialized experts, but does not use all 770 billion parameters for every request. That can keep serving requirements below those of a dense model with the same total size.
Research and data teams have a similar reason to pay attention. Long papers, datasets, analysis notes, and supporting documents can be handled together instead of being split into many smaller exchanges. Office teams may benefit when work spans lengthy reports, spreadsheets, correspondence, and source material. The value is not simply a larger model. It is the ability to keep more of the task available at once.
The strongest fit is likely organizations with the engineering resources to operate an open-weights model and a clear need for control over their workflows. Hy4 is released under the Apache-2.0 license, so teams can evaluate it and build around the weights rather than relying only on a hosted interface. Tencent also makes it available through WorkBuddy, CodeBuddy, Yuanbao, ima, and other services, giving teams a way to access it without managing the model themselves.
The takeaway is simple: Hy4 matters most where long context, broad productivity tasks, and deployment choice meet.
What should engineers test before replacing a closed frontier model?
A higher score does not automatically make an open model a safe replacement. Hy4 preview’s internal blind evaluation is a useful signal, but it is not a substitute for testing the work your team actually does.
Start with a representative task set across coding, office work, and scientific research. Include the domains used to develop Hy4 preview, such as software engineering, gaming, finance, and security. The goal is not to ask whether the model is “smart.” It is to measure whether it completes real tasks correctly, follows instructions, and produces outputs people can use without extensive repair.
Tencent’s evaluation offers a helpful reference point: 163 experts assessed 203 engineering tasks, and Hy4 preview scored 2.99 out of 4.00, compared with 2.92 for GLM-5.3 and 2.94 for Kimi K3. Because this was an internal evaluation, engineers should treat it as evidence to investigate, not proof that the model will outperform their current provider.
Run the same prompts and inputs through the closed model and Hy4 preview. Record correctness, missing details, unsafe changes, formatting failures, and the amount of human editing required. For coding, test complete tasks rather than isolated snippets. For office and research workflows, test whether answers remain reliable across long, messy inputs.
Then repeat the tests through the deployment path you would use in production. Hy4 preview can be accessed through WorkBuddy and CodeBuddy, Tencent Cloud TokenHub, OpenRouter, or direct product experiences such as Yuanbao and ima. Differences between these paths may affect operational results.
The takeaway is simple: replace a model only when it wins on your measured workflow, not merely on a published score.