Hy4 Preview의 장기 코딩, 구조화된 에이전트 탐색, 모델 접근권 재편

I built this FPS game with Hy4 Preview inside WorkBuddy. Now I’m addicted to my own game. Hy4 Preview is a 770B-parameter model with 49B active parameters and a 1M-token context window. The interesting bit for engineers is what they’re testing that scale on: long-horizon software work, large amounts of context spread across files, research, and projects that need repeated iteration instead of a single good response. For coding, that means staying through more of the actual loop: understanding, planning, debugging, and checking the work. Game development happens to be a very visible version of the same problem. It can start from a prompt, get to a playable prototype, and keep working on the same project over multiple turns. That’s the part I got distracted by and I’m still adding things to this one. @TencentHunyuan @TencentAI_News @WorkBuddy_AI

Tencent’s new Hy4 has: • 770B total parameters • 49B active parameters • 1M+ token context The headline is 770B. The number that may matter more for agent workloads is 49B active. Sparse models are changing how we should think about model size.

An agent's biggest cost is the code it never writes. Microsoft canceled Claude Code for 5,000 engineers. Uber burned its entire 2026 AI budget in 4 months too. While both these stories were framed around the bill, none of them asked what the agent was actually doing with the tokens. Developers intuitively think it's writing code, and more output just means a higher bill. But that assumption breaks once you look at what a coding agent actually does in a session. An agent starts a task with no map of your codebase. Before it writes a single line, it has to find where the change belongs. Text search is the only tool most agents have for that, and it faces three distinct problems: 1) A name can show up at hundreds of locations that don't matter, and the agent has to open and read every one to tell the difference. 2) Two things can share a name and mean something different, a method with different arguments, a variable shadowing a field. 3) Sometimes the code shares no words with what you searched for at all, a class implementing an interface without ever naming it nearby. The first two cost tokens. The third costs more, i.e., a missed connection that passes every test and ships as a bug somewhere else, later, with no clear link back to what caused it. Instead of solving this smarter search, treat the codebase as a graph instead of text. Classes, methods, and interfaces become the nodes. The real relationships between them, calls, implements, extends, become the edges. Every node and edge carries the exact file and line it lives at. An agent working against that graph asks a direct structural question, like which classes implement this interface, and gets back exact locations, not a list of matches to sort through. This is close to what an IDE already does when it offers go to definition or find all references. The difference is the agent can ask that question itself, mid-task, without a human looking it up first. The graph doesn't need a compiler to build it either. That matters, because code mid-edit rarely compiles cleanly. Sonar Vortex runs this graph inside the agent's own loop. Sonar tested it on six tasks across four languages, using real merged commits from open-source projects. Each ran ten times per side, and every run had to pass the actual build and tests before it counted. Cost fell in every one of the six tasks, from 5% on a straightforward change up to 36% on the Java interface change. The biggest drops came whenever one change had to happen in many places at once. That's exactly when text search is most likely to miss one. You can read the original study this post is based on here: https:// fandf.co/4cJCjHl The visual below explains regular text search with semantic code navigation, and I worked with the Sonar team to put this together. I also wrote a full breakdown of this. It covers all three ways text search fails, how the graph itself gets built, and the complete results across all six tasks. Read it below.

An 8B model reached 96.9% on ALFWorld, roughly matching Claude Opus 4.5. The key wasn’t a larger model. It learned when and how to use its own external memory and tools. Agent performance is increasingly a harness problem.

Vera Rubin is expected to account for ~20% of NVIDIA’s data center revenue this quarter. That’s roughly $20B. But the bigger story is the cadence. AI compute generations are moving faster and faster. Power, cooling and networking are still physical infrastructure. That mismatch matters.

The stated reason is ToS violation. Perhaps. But it's also true that models are getting commoditized and value capture will increasingly happen at the application layer, and no one wants to be reduced to a commodity. Competition regulators need to be paying close attention to these developments. https:// normaltech.ai/p/up-the-stack -how-ais-escape-from …