Tencent Publishes Hy-Nomas Report and Benchmark Alongside Genie 4 Comparisons

Tencent Hunyuan has published its Hy-Nomas report and released an evaluation dataset, while separately recreating Genie 4 examples in comparison videos. The release gives researchers materials for testing an interactive world model, a system that generates evolving visual environments in response to user commands. Those materials establish a research baseline, but the comparison clips do not establish performance parity with Google's latest model.

The distinction matters because Tencent's paper evaluates Genie 3, alongside other competing systems, rather than Genie 4. Its published findings also acknowledge a weakness: Hy-Nomas trails Genie 3 on long-term spatial consistency. That makes the announcement more useful than a simple contest between attractive videos suggests.

For developers, the immediate question concerns what they can examine, reproduce, and adapt. Tencent has made that investigation more practical through released research artifacts. Whether the resulting system fits a creative application, interactive prototype, or research project still requires evidence beyond selected demonstrations.

The Hy-Nomas report adds evidence to an existing release

The new report documents the model's design and evaluation, while the repository shows that code and demo availability preceded it.

Tencent's release chronology separates several events that a single announcement can easily collapse. The official repository dates the initial code release and interactive demo to October 21, 2026. It lists the arXiv report on October 27 and the Genie 4 comparison videos on October 29.

That sequence changes how readers should interpret the news. This is an expansion of an existing release, with technical documentation and a fresh competitive presentation. It is not evidence that every component first became available together.

The release history also describes training and inference code, model access, and community integrations. Inference means running a trained model to produce outputs. Those resources make the release relevant to developers who want to investigate implementation details rather than judge finished clips.

A research release has several audiences with different needs. A researcher wants enough information to repeat an experiment. A developer wants to understand deployment requirements and interfaces. A creative professional wants to know whether an interaction produces a useful result.

An announcement video can serve the last audience without satisfying the others. Conversely, a detailed paper can support an experiment without showing that a product is convenient for everyday work. Tencent's materials should therefore be assessed according to the question each artifact can answer.

The report's availability matters because it makes the team's reasoning inspectable. Readers can examine how the authors define interaction, what their evaluation measures, and where their conclusions stop. That creates opportunities for criticism as well as adoption.

The timing also puts the release beside a new competitor announcement. Google's Genie 4 arrived during the same week, giving Tencent's recreated examples an immediate reference point. The comparison attracts attention, but the underlying research package deserves a separate reading.

The Hy-Nomas report should be treated as a description of the authors' system and experiments. It does not automatically validate every impression created by promotional footage. Reproducibility begins when another team can connect the written method to actual outputs under documented conditions.

For readers encountering the project through social media, that is the central change. There is now a more substantive basis for investigation than visual resemblance alone. The useful follow-up is to examine what the released benchmark asks a model to do.

Hy-Nomas-Bench moves the question from appearance to interaction

A shared test collection gives researchers a way to examine behavior across successive commands, rather than compare isolated highlights.

Tencent's interactive benchmark describes 280 cases across four tasks: multi-turn text interaction, camera navigation, interleaved controls, and spatial memory. Multi-turn interaction means issuing successive instructions within the same evolving scene. Spatial memory concerns whether previously observed objects and layouts remain consistent when revisited.

The collection includes prompts, interaction sequences, and reference camera trajectories. A camera trajectory specifies how the viewpoint moves through a scene. These inputs provide a basis for repeating a test, although the dataset documentation separates evaluation inputs from scoring.

That separation deserves attention. Downloading a benchmark does not produce a trustworthy ranking by itself. Someone must generate outputs, apply evaluation criteria, record exclusions, and explain how different model interfaces were handled.

Consider a hypothetical creative task involving a character carrying an object through a room. The first command establishes the character and object. A later instruction changes the action, and a camera movement reveals another part of the room.

A useful system must connect those moments. It should preserve the relevant character, carry forward the object's changed position, and respond to the new viewpoint. A visually attractive ending does not explain whether those transitions remained coherent.

This is why interaction tests matter for product development. An application receives commands over time, often after users react to earlier outputs. Its usefulness depends on handling that sequence, including requests that interrupt or revise an initial plan.

The benchmark also creates a clearer basis for disagreement. Researchers can identify the case where a model fails and describe the failure. That is more actionable than arguing over which collection of promotional videos looks better.

The pressure falls partly on Tencent itself. Once a test collection is public, outside teams can challenge the published interpretation. They can investigate whether the apparent advantage survives different evaluation procedures or becomes concentrated in particular scenarios.

Other model developers face a related choice. They can participate in comparable evaluations, explain why the task does not fit their systems, or propose alternatives. Each response can improve understanding if it makes the underlying assumptions explicit.

The benchmark's scope still needs restraint. A collection focused on interaction does not settle every question about visual quality, sound, usability, or application reliability. A useful result answers the measured question, with its conditions attached.

For a buyer, this means avoiding a single overall label such as “best world model.” Different applications place different demands on the system. The relevant evidence depends on whether the job emphasizes navigation, instruction following, continuity, or another behavior.

The release's practical value is therefore a common starting point for investigation. Its longer-term significance depends on whether independent users publish enough detail to make their findings comparable.

The model separates lasting context from temporary commands

Tencent's technical approach addresses a specific interaction problem: an action should end while its consequences remain part of the scene.

According to the Hy-Nomas report, the system uses an 8-billion-parameter diffusion backbone, a neural network that generates visual content through denoising. It produces successive segments using current instructions and retained history. Tencent describes action-aware attention that limits action instructions to their intended time windows while preserving descriptive context.

The paper also describes a Prompt Enhancer, a vision-language component that converts requests and observed history into structured conditions for the next segment. Its evaluation uses human comparisons against Genie 3, LingBot-World v2, and Happy Oyster. Tencent reports interaction advantages but acknowledges that Hy-Nomas trails Genie 3 in long-term spatial consistency.

Those findings suggest a more specific interpretation than overall superiority. The authors present a system designed around flexible interaction, while identifying memory as an unfinished area. Both points belong in any account of the release.

The distinction between an action and its consequence is easy to see in an illustrative scene. Suppose a user asks a character to open a door. Afterward, the character should stop opening it, while the door's new state remains relevant.

Repeating the old command can create unwanted behavior. Forgetting its consequence can create a different continuity error. An interactive system needs to preserve enough history to distinguish those outcomes when the next request arrives.

That is a useful lens for reading the architecture. The design targets a practical source of confusion in sequential generation. Whether it solves that problem reliably remains an empirical question, especially when several actions and viewpoint changes accumulate.

The Prompt Enhancer also affects how researchers should interpret the experience. A user's short instruction and the generator's detailed conditioning are different stages of the system. Performance belongs to the complete workflow being tested.

For application builders, this raises a diagnostic question. When an output fails, did the system interpret the request incorrectly, generate the wrong action, or lose an earlier state? Those possibilities call for different remedies.

An interface that hides every intermediate step can make that investigation difficult. A research workflow benefits from preserving the original request, its structured interpretation, and the resulting segment. Together, they help explain where behavior diverged from intent.

Tencent's model card separately documents a low-memory configuration for a single NVIDIA GeForce RTX 4090. It uses reduced-precision components and CPU offloading, which moves inactive components into system memory. The card also describes 720-by-1280 output at 24 frames per second in a distilled configuration.

These specifications establish deployment options, not an independently verified responsiveness guarantee. Video playback rate and generation speed answer different questions. A developer still needs to measure how long users wait after submitting a command.

This matters because interaction changes the meaning of acceptable performance. An offline rendering workflow can tolerate waiting that would interrupt exploration. The same model can therefore suit one application while feeling awkward in another.

The technical contribution becomes most useful when connected to such concrete requirements. Architecture explains the intended mechanism. Repeated, documented experiments determine how that mechanism behaves in the environment a developer actually plans to use.

Genie 4 comparisons establish a reference point, not a ranking

Tencent's recreated examples and its published benchmark belong to different forms of evidence.

The official repository describes the October 29 videos as Genie 4 examples recreated with Hy-Nomas. That wording identifies a qualitative comparison. It does not describe Genie 4 participating in the paper's evaluation protocol.

Google's Genie 4 capabilities announcement, published October 27, describes real-time interaction and native audio, including ambient sound and dialogue. Google says access begins with a research preview for trusted testers, with broader access planned. These are Google's claims and rollout plans, rather than independent findings about comparative performance.

The companies are consequently presenting different kinds of access and capability evidence. Tencent offers released artifacts that support direct investigation. Google describes an experimental system whose initial availability is controlled.

For developers, access itself has practical value. An available model can be examined within a team's own constraints. A restricted preview creates a dependency on admission and the conditions of the hosted service.

That does not make access a substitute for quality. A system can be easier to obtain and still perform worse on an important task. Conversely, a stronger demonstration can remain difficult to evaluate when researchers cannot run their own cases.

The competitive pressure here concerns the ability to substantiate claims. Tencent's release invites outside experimentation, making its behavior more open to scrutiny. Google's announcement provides a fresh capability reference, but its preview structure limits who can test it directly.

Curated comparisons can help identify questions worth investigating. They can show that a type of scene or interaction is within a system's apparent reach. They cannot reveal the full distribution of outcomes without information about attempts, selection, and failures.

A similar-looking clip also leaves several possibilities unresolved. The systems might require different instructions, preparation, or generation time. They might diverge when the scene continues beyond the selected excerpt.

Those uncertainties do not invalidate the videos. They define what a viewer can reasonably conclude from them. The clips are evidence of presented outputs, with limited information about how representative those outputs are.

A fair comparison should match the decision being made. If the question concerns instruction following, evaluators need comparable commands and a clear success definition. If it concerns usability, waiting time and recovery from errors become relevant.

If the question concerns sound, a visual comparison cannot settle it. If it concerns retaining a room's layout, the evaluator needs an interaction that returns to the earlier view. The test must expose the behavior being claimed.

This is also why the paper's Genie 3 results should retain their original identity. A result against an earlier model cannot be relabeled as evidence against its successor. The later videos do not update the benchmark by implication.

For now, the defensible conclusion is that Tencent has supplied a research package and a timely visual comparison. A broader ranking requires an evaluation designed for the systems and capabilities actually being compared.

Reproducibility depends on reporting the awkward cases

Open materials create the opportunity for verification; independent reproduction requires transparent decisions about settings, selection, and failure.

The strongest skeptical question is whether outside teams can obtain comparable behavior without relying on undisclosed preparation. That question applies even when the model, code, and evaluation inputs are available.

A reproduction can differ for understandable reasons. Software changes, hardware limits, and interpretation of prompts can affect an experiment. The response should be to document those differences and assess their significance.

Version information is particularly useful when a project is changing quickly. A result refers to the artifacts used at the time of testing. Without that connection, later readers can struggle to determine whether they are comparing equivalent systems.

Prompt handling deserves the same care. A short user request and an expanded structured instruction can place different demands on a model. An evaluator should explain which input representation each system received and why.

Selection is another source of ambiguity. A published result should make clear whether it represents an initial attempt, a repeated run, or an output chosen from alternatives. Otherwise, readers cannot estimate how much effort produced the example.

Failures also carry information that successful clips omit. A system might handle an initial instruction but lose continuity after a viewpoint change. Another might preserve the environment while responding poorly to a requested action.

These patterns matter because applications need predictable recovery. A developer can sometimes redesign an interaction around a known limitation. An unexplained failure pattern is harder to accommodate.

The paper's acknowledged memory weakness is therefore useful information. It directs attention toward a behavior that warrants testing before adoption. Researchers should investigate where that limitation appears and how strongly it affects their intended tasks.

Memory also needs a task-specific interpretation. A filmmaker exploring alternative compositions may accept some environmental variation. An application that relies on returning to an unchanged location has a stricter requirement.

The same caution applies to potential simulation uses. A plausible-looking sequence is insufficient evidence that a system accurately predicts a physical process. Any application requiring that accuracy needs validation against appropriate external observations.

These are analytical limits, rather than claims that Hy-Nomas has failed a particular deployment. Public research materials do not establish every possible use case. Application teams remain responsible for defining the behavior they need and testing it directly.

Human evaluation introduces another set of decisions. Raters need consistent definitions of success and a process for handling ambiguous outcomes. Readers benefit when an evaluation explains how disagreement was resolved.

A single aggregate score can obscure those distinctions. Instruction execution, viewpoint response, and scene continuity can fail independently. Reporting them separately gives developers more information about likely fit.

For teams organizing experiments, a searchable knowledge base can connect technical documents with test observations. The goal is traceability: each conclusion should lead back to the configuration, input, and output that support it.

That discipline makes criticism more productive. Instead of declaring that a model remembers or forgets, evaluators can describe the circumstances. Instead of treating a selected video as typical, they can report how often similar behavior appeared.

The Hy-Nomas report provides material for that discussion. The next stage belongs partly to researchers and developers outside Tencent, whose findings can strengthen, qualify, or challenge the team's interpretation.

Watch independent results, comparison protocols, and usable deployments

The next meaningful evidence will come from repeated experiments, explicitly matched comparisons, and applications that expose their operating conditions.

The first signal to watch is an independent reproduction using documented versions, inputs, and evaluation decisions. A useful publication would connect its conclusions to the cases tested and disclose exclusions. It would also explain material departures from Tencent's procedure.

Agreement with the published findings would strengthen confidence in the release as a research baseline. Divergent findings would be informative if the authors identify likely causes. An unexplained ranking would add much less.

Particular attention should go to the reported distinction between interaction strengths and spatial-memory limitations. Outside results that preserve that pattern would support the paper's more nuanced account. Different patterns would suggest that implementation or evaluation choices deserve closer examination.

The second signal is a direct Genie 4 comparison with a stated protocol. Such an evaluation needs to identify access conditions and which capabilities can actually be matched. Shared visual themes alone are insufficient.

A useful comparison would disclose the prompts, interaction sequence, output selection process, and relevant timing measurements. It should also distinguish visual behavior from audio and other capabilities that are outside a particular test.

If a transparent comparison finds similar performance on shared tasks, the competitive implication becomes more concrete. If substantial differences appear, developers gain a better basis for choosing an approach. Either outcome improves on interpreting promotional resemblance as a ranking.

The third signal is a deployment that remains useful beyond a short demonstration. The relevant evidence includes responsiveness, continuity, recovery from failed commands, and the resources required to sustain the experience.

For a creative application, that might mean a documented session showing how users revise a scene and recover from unwanted results. For research, it might mean a repeatable testing environment that preserves enough information for others to inspect.

These examples describe evidence worth seeking, not deployments already established by this release. Adoption claims should remain attached to observable use. Integration announcements are encouraging leads, but their practical value depends on what users can accomplish.

A browser demo can help readers form an initial impression. It does not guarantee that local deployment will behave identically, or that access conditions will remain constant. Availability and waiting time should be checked when someone actually tries the service.

Over the coming months, the most useful discussion will connect these signals. Independent tests explain behavior. Matched comparisons establish relative strengths. Documented applications show whether those strengths matter outside the evaluation setting.

For now, treat the Hy-Nomas report as a starting point for a bounded investigation. Choose a workflow that matters to you, then identify the commands, continuity requirements, and waiting time it can tolerate. Keep the original inputs and complete outputs, including failures. Compare those observations with the published claims before drawing a broader conclusion. If you explore the demo, continue beyond the attractive opening scene and revisit something the system previously showed. If you run the released model, record the configuration alongside your findings. The useful question is specific: does this system preserve the behavior your application needs when the next instruction arrives?