marcus_cemes

> I haven't managed to get one for level "max" yet, it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

Does anyone else find this outright insane? It wrote the equivalent of a full-length novel, just to sit in the question of planning a few dozen shapes.

Academia is going to love this :)

Reading this, I got excited that there may be be a hidden Easter egg, making fun of Jev. I was disappointed to find actual tests.

You would need a significant sample size to make any sort of conclusion from such a probabilistic process. Then there's the issue of how you would actually grade/compare.

Small anecdote on the mobile/robotics part, two years ago I was tasked with a small research sensor/timelapse platform. I reached out for the Pi Zero 2 W, the new Pi camera, and the largest USB battery I could buy. Perhaps I had unrealistic expectations, but I was surprised how much power it draws, even at idle. The napkin math said about 6 days (0.5 W idle, 2 W loaded), in reality it was only 1-2 days.

In comparison, my older laptop idles at around 5 W, even with multiple applications open. Similar experience more recently when looking at setting up a small home lab, the new Pi 5 seems to idle at around 5 W. A friend told me he has an Intel-based mini PC that draws less power. I'm tempted to try re-purposing an old phone, that should in theory do better.

I think I get your point. I can't say that I've observed it writing boilerplate just for the sake of it, but it is disproportionately/abundantly present in the training set. One of the first rules they teach in ML is to balance datasets, even if it's with fake/interpolated samples.

The linear L->R generation is definitely a thing, it's much more costly for an LLM to iterate edits, where a skilled vim coder will be jumping all over the place, trying to make all the LEGO pieces fit.

The skill therefore relies on just being able to one-shot entire chunks of code correctly, and it's amazingly good at this... But even the SOTA models still have a lot of unused imports and unused variable declarations. They just have to "guess" what they'll need and hope for the best. If they include a mass of numpy/scipi/react/icon imports that they might need, it opens the landscape for them later on when predicting relevant tokens, reaching a more ideal solution.

It doesn't hurt to add imports that might be helpful, rather than penalize the solution because you haven't got them. Although the last few SOTA models are more "harness/tool aware", they're starting to have the instinct to write the code anyway, and to be allowed to go and fix the imports later via tool calls.

For anyone who's seen the film Arrival (2016), their entire language is formed of complete concepts, not sequences of words and time. I keep thinking back to this.

I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense.

The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.

That's fair, each provider maintains their own cache. OpenRouter does make an effort to keep providers "sticky", but it may hop/stick to another if latency is too high.

If you don't care about latency, you can create a preset with a single provider, then use that as the model key (i.e. `@preset/deekseek-v4-excl`). The only real downside is OpenRouter's service fee. If you don't want the convenience of switching models, or their excellent dashboard, it's definitely better to pay the provider directly.

Works out of the box with OpenRouter for most models. Some providers are a bit flaky, but DeekSeek (provider) has been one of the most reliable for me, no problems hitting >99% CH.

I find myself often trying to understand the madness of some of the code an LLM produces. Does that count? You're absolutely right! I made a mistake, and I'm sorry.. Then I end up questioning myself if it wouldn't have been easier to just do it myself. To be fair though, it's not limited to LLMs, I've felt that way other people's code too.

Jokes aside, there's a difference to understanding the code and understanding the reasoning that is behind the code, I feel that LLMs still struggle enormously with the later. They start writing, and sometimes realise halfway through that they can't backtrack and just keep writing rubbish. You can argue about spinning loops and iterative processes, as long as they are actually able to converge.

I'm inclined to agree with you, but you could make the same argument for exploiting natural resources and the environment. I don't think it's being done right at the moment, and it does not seem to be benefiting people as much as certain companies.

To be honest, living in Switzerland and speaking with peers, we're just exhausted by the constant AI hype. For a lot of us, the fact that Europe isn't frantically trying to scrape the entire internet and every book in existence for the next massive model isn't a bad thing. The big players are doing their thing, like with the nuclear arms race. We regulate a lot, too much a lot of the time, but sometimes that trickles down to other places too. A lot was done right, imo.

ETH Zurich and EPFL universities recently put out an open model called Apertus (was on the HN front page a few months back), it's not a frontier model, but they built it properly regarding copyright and data transparency.

It might look a bit slow or old-fashioned, but focusing on doing things ethically and legally feels like a much better path than just joining the race to scrape everything.

> We need open weights companies now more than ever.

If you're objective it to democratize AI, sure. But for those fed up with it and the devastating effects it's having on students, for example, can opt to actively avoid paying for products with AI (I say this as someone who uses it every day, guilty). At some point large companies will see that they're bleeding money for something that most people don't seem to want, and cancel those $100k/mo deals. I've already experienced one AI-developer-turned company crash and burn.

Personally, I don't think this LLM-based AI generation will have any significant positive impacts. Time, energy (CO2) and money would have been far better spent elsewhere.

Being a moderately frequent user of Opus and having spoken to people who use it actively at work for automation, it's a really expensive model to run, I've heard it burn through a company's weekend's credit allocation before Saturday morning, I think using almost an order of magnitude more tokens is a valid consumer concern!

I have yet to hear anyone say "Opus is really good value for money, a real good economic choice for us". It seems that we're trying to retrofit every possible task with SOTA AI that is still severely lacking in solid reasoning, reliability/dependability, so we throw more money at the problem (cough Opus) in the hopes that it will surpass that barrier of trust.

You could make the same argument for any language. It still requires you to think and implement the solution yourself, just at a certain level of abstraction.

Perhaps I was a little harsh, this was a few years back when I was evaluating Elixir for a client, but ended up going back to a TS/Node.js stack instead. While the Phoenix documentation is stellar, I found it difficult to find good resources on best practices. I was probably doing something stupid and ran into internal and difficult to understand exceptions being raised on the Erlang side, from Cowboy if I recall. In another case, I was trying to validate API JSON input, the advice I got was to use Ecto (which I never really groked) or pattern match and fail. In JS, libraries like Zod and Valibot are a dream to work with.

The result was a lot of frustration, having been thoroughly impressed by Elixir and Phoenix in the past, knowing that I already knew how to achieve the same goal with Node.js with less code and would be able to justify the choice to a client. It didn't quite feel "there" to pick up and deploy, whereas SvelteKit with tRPC felt very enabling at the time and was easily picked up by others. Perhaps I need another project to try it out again and convince me otherwise. Funnily enough, a year later I replaced a problematic Node.js sever with Phoenix + Nerves running on a RPi Zero (ARM), flawless cross-compilation and deployment.

> Ports are not network transparent

I stand corrected, thank you for the explanation!