Api bills started getting stupid the past few months, like genuinely looking at my monthly spend and wondering if i am doing something wrong. Decided to run my own tests on chinese models instead of trusting whatever chart someone posts on twitter that week.

Deepseek, qwen, kimi went up against my normal claude/gemini/gpt rotation. Glm-5.3 got added this week when i finally got around to the new release so its early days for that one.

The spend gap is wild. Quality gap exists of course but its not anywhere near what the pricing makes it look, especially on iterative stuff where i am running the same task 5 times to get it right.

Closed models still win on hard reasoning most of the time. Once a prompt gets complicated with a bunch of conditions stacked deepseek and the older chinese ones start fumbling somewhere. Glm-5.3 actually held up better than i expected, felt closer to opus on a few of my tests but i will need more time before i say anything strong.

Claude and gpt still get my real work. Iteration heavy stuff just makes more sense on the lighter side because i am not burning premium tokens on a model to write the same function 4 different ways.

Would rather read other peoples actual usage notes than argue about charts at this point.

I do not write compilers for a living. I learned about Mojo yesterday. My first assumption about the Qualcomm–Modular deal was wrong, and I spent the better part of a day trying to understand why.

On August 18, Qualcomm did three things at once. It released Mojo 1.0 under an open-source license, Apache 2.0 with LLVM exceptions. It integrated its own data-center accelerators into the Modular platform, the same platform it had acquired for roughly $3.9 billion only weeks earlier. And it explicitly, publicly, without hedging, preserved first-class support for competing silicon from NVIDIA and AMD.

This does not look like a spontaneous goodwill gesture after a corporate purchase. It looks like an item on a schedule that was drawn up long before the ink dried.

Qualcomm announced its intent to buy Modular on June 24. The deal closed on July 29. The open-source release and hardware integration followed on August 18. Less than three weeks between closing and release. You do not write a compiler from scratch in twenty days, and you do not reverse a corporate strategy in that window either. The decision to open the code was made before the acquisition closed.

The standard semiconductor playbook after buying a software company is defensive. You acquire the toolchain, wall it off, optimize it for your own chips, and charge for the privilege of migration. Intel has done it. Proprietary vendor stacks do it routinely. Qualcomm ignored the playbook entirely. It spent nearly four billion dollars on software and immediately gave the core away, promising to keep the competition's hardware running smoothly.

The question is not what happened. The question is what happens next.

Qualcomm could have taken the obvious path. It could have locked Mojo inside a proprietary SDK, tied it to Snapdragon, and forced developers to pay for access. Want to run on our chips? Learn our API, rewrite your pipeline, eat the migration cost. That is not cynicism; that is the market norm.

Instead, Qualcomm is building a bridge, not a wall.

The pattern that emerged after a few hours of reading is straightforward. Qualcomm makes its money on silicon. On chips that ship in devices and data centers. Software is not the product; software is the condition under which the product sells. If a developer cannot run a model on your chip, he does not buy your chip. If he is welded to CUDA, he buys NVIDIA.

The goal, then, is not to turn Mojo into a profitable language in its own right. The goal is to uncouple hardware choice from software dependency. If Mojo becomes a neutral layer that runs equally well on Qualcomm, NVIDIA, and AMD silicon, developers stop comparing migration headaches and start comparing watts and throughput. They start comparing hardware.

Qualcomm is not buying a programming language. It is buying the rules of the game, and it is trying to change them.

Open-sourcing Mojo removes one genuine fear: the code cannot be pulled behind a licensing wall tomorrow. If Qualcomm changes course, the community can fork. The license is real, the repository is public, the toolchain is downloadable.

But open code does not mean open governance. Who decides which hardware target gets optimized first? Qualcomm and the Modular team. Who merges pull requests? Not the community, not yet. Who sets the roadmap? The same people who own the platform.

The ball is now in the developers' court. Qualcomm made an expensive, noisy, deliberate bow. But a bow is not a dance. If engineers do not show up, if libraries do not get written, if the ecosystem does not form, then Qualcomm bought a very expensive repository with a beautiful license.

And there is a chain reaction behind the developers. Who will write production Mojo code? Where do you hire engineers who know this stack? The talent question is the adoption question. Qualcomm opened the door and made entry free. Whether anyone walks through is still uncertain.

The risk has not disappeared. It has changed shape. From "will they close it tomorrow?" to "will anyone still care tomorrow?"

All of the above is logic. Logic does not run models in production.

NVIDIA is not defended by silicon. Competitors already ship chips that beat it on price per watt. NVIDIA is defended by two decades of CUDA. Millions of lines of optimized kernels, cuDNN, TensorRT, FlashAttention, an entire engineering culture that cannot be rewritten in a single release cycle.

And Mojo is not alone in this field. OpenAI's Triton already abstracts CUDA. PyTorch 2.0 brought its own compiler. JAX and XLA have pursued hardware-agnostic layers for years. The idea is not new. Mojo simply has Qualcomm and four billion dollars behind it now.

Money, however, does not guarantee adoption. The history of AI infrastructure is crowded with technically impeccable projects that never became standards. You need real production workloads, not demos. You need a library ecosystem. You need teams to start hiring for Mojo expertise, and those résumés do not exist yet.

Qualcomm opened the door and removed the entry fee. But someone else has to step inside.

On August 18, Qualcomm did not merely publish code. It made a wager. A wager that the rules of competition in AI can be shifted not by building a new CUDA, but by making CUDA less indispensable.

This does not mean NVIDIA will lose. CUDA will not vanish tomorrow. It will likely dominate for years to come.

But there is now a player spending billions not to build its own wall, but to make walls less relevant. That alone makes the next two or three years of infrastructure far more interesting than the last two or three.

Whether the strategy works remains unknown. But Mojo is worth watching now not because it is open, but because a chipmaker with deep pockets has decided to play the long game in public, and to play against the rules by which everyone else has won.

---

I saw Qualcomm spend $3.9B on Modular and immediately open-source Mojo. That made no sense to me — it is not how chipmakers operate. So I spent two hours digging through press releases and chasing the logic with LLMs until a coherent picture emerged. I am not a programmer, not a semiconductor analyst, not an insider. I just saw a loose thread and pulled it. If it unravels somewhere, tell me.

I really don't care if anyone likes this post or not, I'm just venting. I love AI, LLMs, agents, etc. in general and thought for the last 8 months that they were really helping me get something done. I'm trying to start a nonprofit. It was really helpful at deciphering the legal jargon I had to use to get incorporated in my state, when I could not afford human help. Free legal counsel does not exist for this purpose and I didn't have extra money, so I was grateful any help existed (even if it came from a robot) and this is about when I stopped using search engines entirely and started using different LLMs (no particular one) as search engines, often checking their answers against each other.

This is where it actually became... terribly frustrating.

Because the next step after that is mostly fundraising (finding grants, nonprofit loans, networking events, etc.) I expected this to be a straightforward process of searching and applying.

But every LLM kept giving me results so awful that it was alarming, sent me into a full panic like there was no funding out there for the nonprofit I had just created. It kept recommending venture capital funds, accelerators (which usually serve for-profit businesses, especially tech businesses), ivy league incubators... for a rural west virginia agricultural nonprofit. I showed up in person to several rooms I did not belong in and made the best of it with good humor, but it was getting frustrating to keep doing this.

After months of circling through answers I knew weren't right on various LLMs... I just typed the same questions into Google and immediately got what I was looking for.

I feel stupid but glad its over. Still a little stunned, not quite understanding why relevant search results are still outside the capabilities of LLMs, but whatever.

Where did the GLM-5.3 launch discussion go? The model is out, but the usual first wave of benchmark screenshots, coding samples, and arguments over one suspicious result is much smaller than I expected.

I only realized after quite a while that GLM-5.3 had already been released. I played with it briefly through the ZenMux API. So far the capability difference from GLM-5.2 has not felt very obvious to me, but it is very, very slow. I cannot tell whether that is a network problem or something else.

For now I have gone back to GLM-5.2. Maybe the slow response was specific to my request path, but it was enough to make the new model feel less immediately useful. I still want to see more real GLM-5.3 testing before deciding whether it is worth switching back.

A frozen cross-vendor study of 31,430 trials across 11 GPT, Claude, Gemini & Kimi Large Language Models found 11,658 successful executions with exactly zero visible UTF-8 output bytes.

Across 4,290 strict matched semantic pairs, null-condition arms produced 2,505 Voids; matched output-licensed controls produced 0.

These were not refusals, safety blocks, rate limits, or transport failures.

Raw records, event hashes, verification code, and full analysis are public.

am i alone in noticing that claude increasingly seems to reprimand, accuse, or judge me over standard questions and tasks? where is this even coming from, is it actually forming its own opinions, or are its silicon valley programmers forcing some sort of hyper preachy alignment onto it? sometimes i simply want a direct answer...

the new v5 models, especially opus 5, have become insufferably argumentative, and quick to make moral judgments. and some other llms tend to blindly flatter and agree with users, claude seems to go to the other extreme

it’s kind of annoying because i just want an ai tool, not a debate partner. tbh the older versions of claude felt way better to use. is anyone else experiencing this?

It can be local, open-weight, closed-source, hosted, whatever. I’m just looking for a smart LLM that won’t constantly refuse requests

I wrote my first article, my aim is to explain things without jargon and as simple as possible! Please give a read and then comment and like, if you feel it was useful!

I keep seeing people (and models) react to this analogy like it’s pure exaggeration or just meme-tier nonsense. Even strong models initially push back hard against it. I did the same until I sat with it longer. So here’s a proper breakdown of why the analogy actually holds more weight than it first appears.

The original analogy

Running a 1-bit (or 1.58-bit / ternary) model is like putting a scientist who still has all his mental capacities intact — knowledge, reasoning ability, training — but blindfolding him, gagging him, tying him up, and binding one hand behind his back… and then asking him to solve a complex math problem that is being explained to him by a 2-year-old.

Most people’s first reaction is: “That’s way too dramatic. BitNet-style models can still perform surprisingly well.” And on the surface they’re right. Native 1.58-bit models trained at scale do retain a lot of capability. So the analogy looks overblown.

Why the first reaction is understandable (and where it goes wrong)

The common counter-argument goes something like this:

The model was trained under the constraint, so it learned how to work with ternary weights.

At sufficient scale the performance gap to full-precision models of similar size shrinks a lot.

Therefore the “crippled scientist” picture is unfair.

That reasoning is partially correct, but incomplete. It focuses almost entirely on the weights side of the constraint and treats the input as clean and fully available. That’s the part the analogy is actually stressing.

The two layers of the constraint

The physical constraints on the scientist

These map cleanly to the ternary weights. The model still “knows” a lot (the training is real), but its internal degrees of freedom are extremely limited. Every transformation has to happen through a very coarse set of operations. Fine adjustments are gone. That part is not controversial.

The input coming from a 2-year-old

This is the part most people skip, and it’s the more important one.

A 2-year-old explaining a complex problem does not give you a clean, complete, well-structured statement of the problem. You get incomplete sentences, missing details, confused ordering, limited vocabulary, and a lot of noise. The scientist still has to reconstruct what the actual problem even is before he can start solving it — while already operating under severe physical restrictions.

Now look at real usage of language models.

Users almost never send clean, perfectly specified inputs. We send vague prompts, half-formed thoughts, grammatical messes, shifting intentions, missing context, and assumptions that the model will “just get it.” Even relatively clear users (myself included) still require the model to extrapolate, fill gaps, track evolving intent across turns, and decide what to take literally versus what to interpret.

A full-precision model has enough internal capacity to do that reconstruction and still reason. A heavily constrained 1-bit model has far less room to do both jobs at once: clean up / interpret the messy input and perform the actual reasoning under ternary weight limitations.

So what does the analogy actually claim?

It is not claiming that 1-bit models are useless.

It is claiming that the combination of:

extreme internal restriction (ternary weights), and

the reality of imperfect, incomplete, noisy human input

creates a much harder situation than the clean benchmark numbers suggest. Benchmarks usually give the model a relatively clear problem statement. Real conversations often do not.

That’s why the analogy feels exaggerated at first. We evaluate these models mostly on clean tasks and forget how much of real interaction is closer to “explained by a 2-year-old.”

Final thought

The scientist is not stupid. He is highly trained. But he is operating with very limited physical freedom and he is receiving a degraded, incomplete description of the problem. That double constraint is real. Dismissing the whole picture as “just dramatic” misses the second half of it.

Curious what others think — especially people who have actually run native 1-bit / 1.58-bit models on messy, multi-turn, real-user style prompts rather than clean eval sets.