Tencent Hunyuan Hy4 and Phone Agents: Preview Facts, Access, and Android Execution
A practical guide to Tencent Hunyuan Hy4 Preview, its official open-source and access paths, what changed from the prior generation, and why Android phone actions still need a phone-agent runtime.
- Tencent announced Hunyuan Hy4 Preview on August 28, 2026, describing preview status, open-sourcing, product experiences in WorkBuddy, CodeBuddy, Yuanbao, and ima, plus API access through Tencent Cloud TokenHub and OpenRouter.
- Tencent describes Hy4 improvements around longer-horizon software development, complex office analysis and cross-file work, and scientific reasoning; these are manufacturer-reported claims, not independent benchmark tests.
- Hy4 can support reasoning, generation, planning, and product experiences where integrated, but it does not automatically execute Android phone actions.
- Android phone-side execution still requires a runtime with supported tools, permissions, approvals, visible progress, and result verification.
Hy4 Preview Facts From Tencent's Announcement
Tencent Hunyuan Hy4 is a Hunyuan model generation that Tencent presented as Hy4 Preview in its official August 28, 2026 announcement. For readers asking about a Tencent Hunyuan Hy4 phone agent, the first answer is factual and narrow: Hy4 is a model release and access story first. It is not, by itself, a complete Android phone-agent runtime.
The official source to start with is Tencent's announcement of Tencent Hunyuan Hy4 Preview. The announcement says Hy4 Preview was released open-source and describes three kinds of access: product experiences, API routes, and open-source weights for self-hosted or developer evaluation under the applicable terms.
The product experience entries named in the announcement are WorkBuddy, CodeBuddy domestic and international editions, Yuanbao, and ima. That is useful because it tells readers where Tencent said users could experience Hy4 Preview in product form at announcement time. It should not be stretched into a claim that every Tencent product, every region, or every Android surface exposes Hy4 in the same way today.
The API entries named in the announcement are Tencent Cloud TokenHub and OpenRouter. Those routes are developer-facing model access paths, not consumer mobile-app controls. An API can help an application call a model, but the application still has to decide what context to send, which outputs to trust, which tools can run, and what approvals are required before any external effect.
Open-source release is the third path. Open-source weights can help developers inspect, deploy, or integrate the model under the stated terms and technical requirements. That does not automatically provide a mobile UI, Android permissions, app-control tools, user approvals, account integrations, or recovery handling. Those belong to the surrounding runtime and product layer.
The announcement also included launch-time trial or pricing language tied to the release period. Treat that as historical announcement context, not a current free offer. Pricing, quotas, access windows, and platform terms can change after an announcement, so readers should check the relevant official access page before making cost or availability decisions.
What Tencent Says Changed in Hy4
Tencent positions Hy4 Preview as a new generation in the Hunyuan family, with open-source availability and named access routes for product experience and API use. The concrete changes Tencent highlights are best read as model-layer improvements, not as proof of Android-side execution.
In the announcement, Tencent describes Hy4 in relation to longer-horizon software development work: understanding requirements, planning, debugging, and verification across a larger task. For developers, that matters because a model may produce a more coherent plan or code-reasoning path. It still does not guarantee that a local development environment, repository, permission, or deployment system changed successfully.
Tencent also describes complex office analysis and cross-file work toward documents, spreadsheets, and presentations. In practical terms, that points to better model-side handling of business materials and multi-file context where the product or API route supports it. The result still needs human review before it becomes a sent document, edited file, approved report, or scheduled workflow.
The announcement also names scientific reasoning as an area of improvement. That is a model capability claim from Tencent, not independent verification. Treat vendor-reported tests, scores, and launch comparisons as Tencent's own claims unless a separate evaluator, methodology, and reproducible comparison are available.
For phone tasks, the practical change is not “newer model equals phone control.” Hy4 may help produce cleaner plans, better structured outputs, and stronger reasoning over constraints. Those improvements can help a phone-agent system decide what to do. They still do not create Android permissions, app integrations, confirmation screens, or result checks by themselves. For readers who need the prior-generation context, Tencent Hunyuan Hy3 for Phone Agents: Model Power vs Android Actions explains Hy3 and its phone-agent relevance.
Where Tencent Said Hy4 Could Be Used
Tencent's August 28, 2026 announcement names concrete Hy4 Preview access entries. Read them as announcement-backed routes, not as a fresh availability check performed by this article.
| Access category | Entries named by Tencent | What it means | What to verify |
|---|---|---|---|
| Product experience | WorkBuddy; CodeBuddy domestic and international editions; Yuanbao; ima | These are user-facing or product-level places Tencent said Hy4 Preview was launched into at announcement time. | Current account eligibility, region, product availability, feature scope, and whether Hy4 is still the active model path. |
| API access | Tencent Cloud TokenHub; OpenRouter | These are developer-facing routes for calling the model from applications or workflows. | Current API availability, terms, pricing, quotas, supported parameters, and integration requirements. |
| Open-source weights | Hy4 Preview open-source release | This route supports self-hosted or developer evaluation where the release terms and hardware requirements fit. | License terms, deployment requirements, safety controls, latency, hosting cost, and operational responsibility. |
The practical distinction is route and responsibility. Product experiences can show user-facing behavior but may not expose all API controls. API access can support application workflows, model routing, evaluation, or agent planning, but an API call is still a model call. Open-source weights can support self-hosted evaluation or deployment, but the team running them owns hosting, safety controls, logging, latency, user interface, app integration, and permission handling.
None of those access routes automatically makes Hy4 an Android phone agent. A downloaded model, a product experience, or an API endpoint still needs a runtime to connect model output to supported phone actions, user permissions, approval points, and final-state verification.
Hy4 Model Capability vs Android Phone Actions
Hy4 model capability and Android phone actions answer different questions. The model question is: can Hy4 understand the user's request, reason about constraints, produce a useful answer, draft a plan, or generate structured output? The phone-action question is: can a device-side runtime perform a supported action on Android with the right permissions, approval, progress state, and final verification?
This distinction matters because model output can sound complete even when the phone has not changed. Hy4 could help produce a plan such as “create a reminder for tomorrow,” “summarize this message,” “prepare a reply,” or “check whether this task needs follow-up.” But a plan is not the same as a saved reminder, a sent message, a changed setting, or a verified calendar entry. The phone's actual state belongs to Android, the relevant app, and the runtime that can access supported actions.
A useful phone task has several checkpoints:
| Checkpoint | Model role | Execution role |
|---|---|---|
| Intent | Understand what the user wants and identify missing details. | Bind the request to a supported phone action or ask for clarification. |
| Target | Reason about likely app, account, contact, file, calendar, or setting. | Inspect current device state and choose an allowed tool path. |
| Permission | Explain why access may be needed. | Use Android and app permissions without bypassing user controls. |
| Approval | Prepare the proposed action in reviewable language. | Pause before consequential actions such as sending, deleting, changing, or sharing. |
| Result | Interpret the returned state or failure. | Verify the final phone state and report recovery options if blocked. |
Hy4 may improve the reasoning side of that table. It does not remove the need for the execution side. A phone agent must still respect Android boundaries, app-specific state, account context, sensitive data, and user confirmation. Stronger models make planning better; they do not make permission checks optional.
Android Phone-Agent Execution Requirements
This is where FoneClaw is relevant. FoneClaw is a separately configured Android phone-agent runtime: a configured model reasons and plans while FoneClaw supplies governed supported tools for Android-side work. In this comparison, Hy4 represents model capability; FoneClaw represents the execution layer that a phone task needs after reasoning.
FoneClaw's current Android capability surface is summarized on the FoneClaw Features page, including 100+ built-in tools across areas such as screen and app context, device status, mail, communication, calendar, memo, and tasks or workflows. That tool surface is governed. Supported actions depend on the specific Android capability, current phone state, enabled tool, account context, permission, and applicable approval.
For example, if the user asks to create a calendar event from a spoken note, the model may identify the date, time, title, and missing details. The runtime still has to determine the calendar account, prepare the proposed event, show the user what will be created, request approval where needed, perform the supported action, and verify that the event appears in the expected place. If permission or account access is unavailable, the workflow should report the boundary and guide recovery instead of pretending the event exists.
Recent FoneClaw improvements around richer voice notes and transcription summaries are useful for review clarity. They help users inspect captured intent before it becomes a supported phone task. Scheduled automations, progress handling, notifications, and safer missed-run behavior matter when work is supposed to happen later. These features support accountable execution; they do not replace approval for sensitive actions.
Model choice alone also does not establish consumer-app interoperability or a Hy4-specific integration. A model can be configured for reasoning in a runtime, but consumer product access, API access, self-hosted weights, and Android tool execution remain separate layers. For a deeper explanation of that runtime pattern, see AI Agent Phone Control on Android: Intent, Confirmation, Action.
Model or Phone-Agent Stack: How to Choose
Choose the stack by the final state the user needs. If the output should be an answer, analysis, summary, translation, draft, code suggestion, or plan, a model-centered Hy4 workflow may be the right starting point. If the output must change Android state, the model is only part of the system. You need a phone-agent runtime.
Use this checklist:
- What is the final result? Text in a chat, API output, saved phone item, sent message, changed setting, scheduled automation, or verified workflow?
- Where does the result live? Hunyuan product experience, a backend API workflow, a local model deployment, an Android app, or a device setting?
- Who owns the action? A model can propose; the app, device, or phone-agent runtime executes.
- What permission is required? Calendar, contact, file, screen, mail, message, notification, or accessibility access may be needed.
- Is approval required? Consequential actions should be visible before they run.
- How will success be verified? Check the actual place where the result should appear.
A hybrid setup can be sensible. A strong model may be selected for planning quality, while a phone-agent runtime supplies tool access, permissions, and verification. Teams comparing multiple reasoning models should also evaluate routing, cost, latency, language fit, and task reliability. Phone Agent Model Routing: Kimi, DeepSeek, GLM, Cost, and Android Actions covers that broader decision.
The final rule is simple: use Hy4 for model capability where it is officially available, and use a governed phone-agent stack when the user expects the Android device to do something. A stronger model can improve the thinking layer. It does not remove the need for a responsible doing layer.