Ai

Over the past couple of days, I’ve been flipping back and forth through the documentation for Hermes and OpenClaw, and the more I read, the more I feel that many people compare these two projects as if they are on the same level; in reality, the comparison is biased from the start.

They are all doing “personal AI assistants.” They can receive messages, call models, run tools, and retain some context. Hermes even specifically created hermes claw migrate, clearly knowing it would receive a batch of OpenClaw users.

But frankly speaking, Hermes is not a skin-deep version of OpenClaw, and OpenClaw is not just an agent framework with a few extra message entry points. One grows outward from the Gateway, while the other grows outward from the AIAgent. If you don’t grasp this difference first, discussing architecture, design philosophy, and ecosystem later will just lead to more confusion.

Recently, I started a small C++ project using AI. The most frustrating moment isn’t when it can’t write the code, but when it spits out a seemingly decent directory structure in three minutes and casually throws in a few third-party libraries, making the demo actually runnable. That’s the problem. You haven’t even figured out what the newly introduced library supports, how the compilation link works, or where its boundaries are, so rework is basically inevitable later on.

I’m increasingly feeling that what AI programming fears most is not the model being dumb, but starting too greedily. Especially with languages like C++, which don’t have much scaffolding to fall back on; if you miss one step upfront, later you have to account for several steps regarding compilation, linking, library versions, and directory structure.

Previously, when I debugged C++ in VS Code, the configuration basically stopped at launch.json, maybe with an extra line for GDB. Fill in the program, fill in the gdb, set the breakpoints. And then what? Then every time before debugging, I had to manually run cmake --build in the terminal. What was even more annoying was that after setting breakpoints on custom prices, contracts, or order types, the VS Code debug window often only showed a bunch of internal fields. The data was correct, but it wasn’t human-readable. The ridiculous part is that some tutorials I saw before stopped around launch.json. It wasn’t until recently, when I had an AI set up a new project for me, that it conveniently added preLaunchTask and gdb_printers.py, that I realized: debugging C++ in VS Code isn’t just about starting GDB. You can automatically trigger CMake compilation before debugging, and after hitting a breakpoint, you can even let GDB load a Python script to format business types into something readable for us. Honestly, this isn’t some black magic. But it perfectly filled two annoying gaps in daily C++ debugging: pre-launch build and variable display after a breakpoint.

While browsing the forum this time, what struck me most wasn’t which company released another leaderboard, but a very basic statement: “Not enough VRAM; no matter how large the parameters are, it’s useless.”

Previously, I always understood “slow model” as a computational power issue. However, the more I read, the clearer it became that often, the problem isn’t that the GPU can’t compute it, but rather that the data cannot reside in the right place. Just by changing the memory path, the token speed doesn’t just slow down; it drops drastically.

If you only look at the leaderboard, 31B is definitely the most eye-catching. But when you actually get the machine out, it’s still that un-upgraded RTX 3060 12GB, and your judgment will change immediately. How should I put it? For local deployment, in the end, it’s not about who looks the fanciest, but who seems like the one you can live with long-term. For me, what is truly worth running first this time isn’t 31B, but 26B A4B.

On the day of the initial release, what I originally wanted to do was simple: find an upgraded version corresponding to Gemma 3 and download it to run. However, after looking around, I was a bit stunned. The familiar naming convention of 4B / 12B / 27B is gone; instead, we have E4B, 26B A4B, and 31B. How should I put it? This time, what Google truly changed wasn’t just the model sizes, but even “how you should understand this batch of models.”

During my time using Codex, there was one thing that always felt a bit awkward: the default thinking level is medium, but when chatting online about GPT-5.4, everyone’s tone is very strong. When it comes down to actually using it, what exactly is the difference between medium, high, and xhigh? The official documentation hasn’t provided a particularly straightforward chart. My current conclusion is quite clear: for daily coding, I prefer to start directly at high. Medium isn’t unusable; it’s fine for quick tasks, minor tweaks, or exploring directions. But when dealing with multi-file modifications, ambiguous requirements, and needing to judge while looking at code, medium easily wastes computational power in the wrong places. I actually don’t use xhigh often; I save it for really difficult tasks where I get stuck.

After going through all the configurations in the repository, I am even more certain about one thing: what matters in the end is not how strong any single model is, but rather who should bear the cost at each layer.

The most obvious signal is that the currently active published.runtime.json is still the one generated on April 2, 2026, for minimax-m2, yet the entry from April 3, 2026, at 16:38, labeled 5f17088, has switched the default provider for blog-style-suite to the local gemma-4-26b-a4b in LM Studio. This might look inconsistent, but it actually isn’t; it precisely illustrates that this pipeline has begun to specialize.