They overclocked well though, I think you could run the 300Mhz chips at >400Mhz.
I also believe you could get motherboards that supported 2 Celeron chips. I have no idea how effective/useful it was, but it was certainly a cheap/interesting way to get multiple CPU's.
> Co-trained with the harness. Muse Code was in the training loop from day one, so tool calls succeed and plans execute cleanly. Crucially, we trained across multiple harnesses, so while the model is at its best in Muse Code, it still generalizes to other coding agents you already use.
Very keen to try this after using Claude Code over the last few months.
Should I just point Claude Code to Muse Spark endpoint (because I'm familiar with Code)? What do people think of Muse Code or other coding agent harnesses?
Well thats very interesting. Thank you.
Will be interesting to see how hard/easy it is to translate my Claude skills, loop design, etc to the new harness.
This kind of raises another question to me regarding the coding benchmarks, how much of it is model versus harness?
Coming from Claude Code, I initially went with opencode but switched to pi.dev after a while and I think I like it more. It's lighter weight. It's worth trying both.
Thats not exactly 'validated'. Feels very noisy, it is not a good bar for either
- does this code do what the user actually asked
- is this code actually 'good'
There would be so many examples of coding projects that these models began or attempted to work in, that were abandoned because the models were floundering.
I would imagine the labs have some decent ways to produce novel requirements and then actually validate they are met, without the noisiness of implicit human feedback.
That said, the more I think about it, you are right, there's probably also very good ways to extract signal for all these sessions.
This is exactly what RLVR is, and the reason that models have improved so much at verifiable domains like coding and math while not so much on unverifiable ones like writing and UI design.
I believe a lot of NIC's could autodetect and adapt to the cable? I'm pretty sure I had 2 computers connected to each other using a regular network cable.
Question: For things like this to be truly worthwhile, do you have to ensure the training, post-training of LLM's is filled with brilliant memelang code? The models are probably already good at 'thinking' in SQL at the moment, but if they aren't trained on memelang, surely they will have to use more effort to translate in context to produce equivalent quality queries?
Wouldn't surprise me if in the next few generations we start seeing more LLM generated languages that LLM's prefer to use for expressability, conciseness, etc.
I think for a realistic comparison we would need to see LLMs benchmarked with and without a "use Memelang for queries" prompt (and a short file somewhere explaining the syntax). I think it's unlikely that the token-efficiency of Memelang would provide much benefit for current LLMs; my intuition is that much more tokens would be spent on reasoning and mistakes in Memelang than are saved from just using SQL (SQL queries aren't usually that long anyway??).
In the few public reasoning traces from recent OpenAI models, we see a lot of "grug speak" as it is token-efficient, and they presumably trained the models for token efficiency in reasoning. It is indeed not too much of a leap to see future token-efficient programming languages.
One question I have about stuff like this: How does it affect the models intelligence or thinking ability. If this modifies the output or chain of thought in any way, it may impact what the model is capable of right? Especially if it's not trained to use this kind of language during training.
reply