Hey all,

I've been working on this for a while and finally shipped it today, so figured I'd share here since this sub actually gets the problem.

The thing that's always bugged me about coding agents: you give them a task, they take one pass at it, and then they stop whether it actually works or not. You're still the one testing it, finding what's broken, and re-prompting. The agent did the "coding" part but you're still doing the "engineering" part.

So I built Keel Code around what I'm calling loop engineering instead of a single model taking one shot, it runs a team of frontier models in a loop that plans, builds, tests, and critiques its own output, and keeps going until the goal is actually met. Not one-shot. Not "here's my attempt, good luck."

The core command is /ascend you give it a goal, it puts together a plan, executes, checks its own work, and iterates until that goal is hit. You're not babysitting it every few minutes.

Install:
bun i -g @keelcode-ai/keelcode

It's using top-tier frontier models for free for a limited time while we're fresh out of launch, so this is the cheapest it'll ever be to kick the tires.

Site: keelcode.ai

Not here to oversell it genuinely want feedback, especially on where the loop breaks down or gets stuck, since that's the hard part of this whole approach. Happy to answer anything about how it works under the hood.

Like everyone else, I saw 2.8 trillion parameters and immediately rolled my eyes a little.

Then I started reading and reading and.... yes, you guessed it: reading.

A few hours later I realized I wasn't thinking about the parameter count anymore.

I was actually thinking about MXFP4, 16-of-896 expert routing, million-token contexts, cache architecture, and all the boring systems problems that somehow let a model this size exist in the real world. Kimi K3 is a 2.8T-parameter MoE model with 16 active experts per token and a 1M-token context window, which is where the engineering starts getting interesting.

The thing that surprised me a lot is how much of the conversation seems to focus on the weights themselves. The more I looked into it, the more I felt the harder problem is serving. Everyone asks whether they can run a model like this. I'm increasingly interested in whether they can run it efficiently.

I ended up going down a rabbit hole on sparse MoEs, batch sizes, cache economics, and Kimi Delta Attention. Somewhere along the way the headline stopped being "2.8T parameters" and became "how did they make this remotely affordable?"

So I wrote a Substack post about it, not just about benchamarks or whether it s more or less good than claude or chagtp.

It's more about the engineering trade-offs hiding underneath the announcement and why I think those are the details that will matter long after everyone forgets the parameter count.