cmrdporcupine

There's all sorts of reasons, not sure what level of detail you want me to get into. I've got about 30 years of thoughts on this.

For one, I think MOO is kind of shite in lots of ways. But I and others spent lots of time 20+ years ago building alternatives and nobody used them. There's intrinsic value to just picking up and then improving on something that has established history. It gathers an audience of users, has name recognition, and most importantly keeps you responsible from an engineering dev POV because you are forced to focus on delivering a thing that works and you have a way to prove it. As Linux has shown, incremental improvement on a somewhat flawed but relatively popular and known foundation has value. mooR cakes over a lot of the ugly parts of MOO and honestly, I'm pretty proud of it.

Secondly, existing "mainstream" languages are not appropriate, mostly. None of them or their runtimes are really based on a properly sandboxed persistent model. I poked at WASM, and I could write a screed about that, but wrong system. MOO (and successors to it) were built with the idea of lots of people jamming on one shared world, and it shows.

Finally, I have all sorts of ideas on what I think is "better" than MOO, and did eventually open the floodgate this spring and start building out the "dream system" here: https://github.com/timbran-project/mica -- but as you can see from relative star count of one vs the other.. my first point has relvance.

There should be an explanation in the book on how loading works. If not, I'll need to clarify. Documentation writing sucks. But the TLDR is that one of the arguments you pass to the system at start is basically a source directory of ("objdef") human readable / editable source files, and that gets compiled into a persistent binary database. Once that's done, restarts load directly from that DB/image, not source. (But the system can periodically export or "dump" objdef files as well).

Note this is a bit different from classic LambdaMOO, which had no such process. It had a primitive text database that was not human editable really, and you started from what people passed around of those.

Hope that helps. Come by the discord if you have questions: https://discord.com/invite/Ec94y5983z

Also I just finally put up a new blog post on dev status https://timbran.org/catching-up-with-moor.html

EDIT: I've done some book edits and added a chapter here which I hope helps: https://timbran.org/book/2.0-dev/html/the-system/bootstrappi...

You would probably like my project https://github.com/timbran-project/moor

Here's what is key: never rely fully on the "intelligence" of the model. Build a workflow and/or tooling that allows for empirical improvement. e.g. for performance tuning I have a benchmarking framework and a container/server that contains the differential results available via MCP for the agent to observe as it works. Using /goal and a clear destination you want to get to, it will literally grind for hours and use that help. Doesn't help with architectural stuff, but it does help with producing efficient code.

I had the opposite experience. I bought the $100 monthly sub from Neuralwatt last month because it was the only economical provider for GLM 5.2. They raised their rates halfway through, and it simultaneously became too slow to use.

I just looked at DeepInfra -- I've got an account there already etc -- and it's at FP4 quant. How much that effects the quality of inference for GLM, I can't say. I could see using it as a backup when other things run out but don't think I'd trust it.

that stuff in particular -- AI generated with heavy heavy prompting and up front design work and post-implementation testing

I have CUDA work here somewhere too but I have the repository private right now

Feel free to look, but don't bother replying if you have something negative to say, don't feel like having my day ruined by negativity.

https://github.com/rdaum/mica/tree/main/crates/relation-kern...

https://github.com/rdaum/mica/tree/main/crates/vm

https://github.com/rdaum/pagebox/blob/main/crates/wal/src/wa...

Of what specifically?

I have not seen that kind of significant drop with GLM 5.2 yet? so curious why you think it will happen for K3.

This is a very large model. Much larger (3x) than GLM. The resources to run it are very expensive.

Absolutely.

Yes, the reckoning here will happen in a year or two when the (probably subsidized, maybe?) coding plans become either unavailable or much more costly.

It's also already the case that in larger companies people do not have access to these plans as employees and must use API rates.

There's also the political angle. When Anthropic and OpenAI held back their top of the line models because of Bessent & Trump's bullshit, and threatened to deny unwashed foreigners like me access... I dropped my Codex plan and made do purely with GLM 5.2 for three weeks before OpenAI finally released 5.6 Sol. Feels inevitable that this will happen again.

Or, somebody will come up with a way to serve e.g. Kimi K3 or the new Qwen model in an extremely cheap way. Or DeepSeek releases a competitive model at their cut-throat rates. And then the cost argument just wins.

For people cranking out SaaS / web services / web pages / "full stack" work I don't see a huge difference.

If you're building an optimizing compiler, a CUDA kernel, a database, a high performance concurrent data structure with tricky locking, etc. etc. it's still not really close. Sol 5.6 on high just slays e.g. GLM 5.2 for this kind of work for me.

I'm sure K3 is fine for these things too, but I can't afford it at its API rates compared to a Codex coding plan.

For now.

OpenAI's Codex tool is not limited to only calling their models. You can create a profile that uses any OpenAI API compatible endpoint.

It's written in Rust. It seems to perform well. It also seems (from my poking around in it) on the whole well and deliberately written. It doesn't consume memory like a mf'er like Claude Code. It doesn't sit and chew background CPU like I've seen opencode.

I suspect it will accumulate more specific-to-OpenAI-isms over time though.

Absolutely. There's a glaring gap in the space for something about the size of Nemotron Super or just under, but actually ... competent.

The fantasy is a 100B or 80B model, but MoE and highly tuned for coding.

Claude also had issues with this kind of thing for months early on, too, where it simply couldn't compact its own emissions.

But definitely earlier GPT models suffered greatly as context got large, and the compaction itself in Codex was really crappy. That changed around January.

Codex compaction is really quite good. Smaller context doesn't really harm me.

I had a /goal running last night for 9.5 hours straight while I slept. When I woke up in the morning it was fully on task and focused.

Write up a detailed design doc. Build a decent AGENTS.md, and write up a good prompt or /goal.

Long context can be more of a curse than a benefit sometimes anyways.

For whatever reason prefill (on my DGX Spark) is faster with the Gemma models than Qwen 3.6 models of similar size. On vLLM anyways. Likely just deeply tuned code contributed to vLLM by Google?

vLLM gives me ~7000+ tok/sec with Gemma 4's MoE model. Vs ~6000 tok/sec for Qwen 3.6 MoE.

Gemma4 models are arguably better. Or at least about the same.

Yeah, this was '83. They went into the store and saw both on the shelf, and the C64 was "too much" so I got what I got. I think a year later the price on the C64 just made the VIC20 totally pointless.

Also they bought it, brought it home, and then two days later took us all on a 3 week vacation road trip across Canada. I sat in the back of our Toyota Tercel with a pile of magazines with BASIC listings in the back of them fantasizing about getting home to try them out. Torture.

K3 is not cheap or self-hostable.

My parents were too cheap for the C64 and I got the VIC20 instead.

Major bummer. In 20 columns.

I haven't tried K3 yet but my experience with older Kimi models was exactly this, that they'd spin for a whole chunk of time with a lot of back and forth thinking.

But some of this might still be something that gets sorted out with finding the right parameters etc on the serving side.

Only if you're paying for said flagship models through API prices. Which I specifically said I was not and specifically mentioned coding plans.

DeepSeek is a whole other story. It and a few others are quite economical. But they're also not nearly at the same level.

I can get by working on code strictly in GLM. I can't with DeepSeek. It makes some pretty careless mistakes and isn't a very deep thinker.

It is very useful as a general purpose model for non-coding purposes though.

GLM is actually quite expensive in actual practice because it's not very token efficient. I've yet to find a way to run it on a monthly sub reliably for cheaper than Codex.

Neuralwatt was cheap (but slow) but they cranked their price.

Ollama monthly sub is speedy but doesn't offer a lot of quota.

Right now unless you're paying by the token, there's no cost based reason to use the open weight models for daily coding work because the monthly coding plans from Anthropic and OpenAI are a better deal.

That depends entirely on the hosting situation. If someone can provide a subscription plan at slightly lower rates, it's absolutely compelling.

Now live https://news.ycombinator.com/item?id=48935342

Since when are we still in "QE times"?

2.8 trillion parameters

I have been spending my mid-life days pondering getting a used Porsche 986.1 Boxter, cuz, y'know, mid-life. And so reading reviews and I constantly see this refrain: "car drives great, wonderful handling, good value... but not worth it because the engine sound/note is so dull."

I just have to give my head a shake. It makes zero sense to me.

Annoying because I used to like using that phrase.

A similar Codex/GPT verbal tick is "deliberately narrow" or variants thereof.

Just a grep across my repo comes up with a dozen lines with phrases like "It is deliberately small" or "This crate is deliberately not a X" despite my efforts to police this kind of thing.