I don’t understand it, but good for OpenRouter. Personally, I think OpenRouter’s value is somewhat perishable. In the early AI market where there are a jillion models and anew one every week, it’s great to be able to try them all without having to create accounts and keys for each one. OpenRouter, which I use, makes this easy for developers to do. Add some cost controls and other “management” knobs and it works great. But the market is not going to be this frothy forever. As things settle down and commoditize, the value of switching on a dime diminishes as people lock into their favorite models. And with the OpenAI and Anthropic APIs being defacto standards for how to talk to models, it’s easy enough to switch to another model every so often, as long as you aren’t doing it multiple times per week. The other alternative is that OpenRouter stays in the mix but its pricing gets ground down and down. If it’s (nearly) free and still adds some value, fine. But that doesn’t justify $7B. So, yea, I don’t get it from Stripe’s perspective.
Wow, move the goalposts much? Okay, I’ll stipulate that somebody, somewhere, at some time might have been promoted to get them out of the way. But I’ll tell you it’s definitely not the norm in any company that I’ve ever worked in, to the point that I’ve literally never seen it after nearly 40 years and having worked at all levels from 1st level manager to VP, from F500 to 2-person companies.
Yep, I’ve seen that, too. I’ve also seen people give up a promotion after they decided that managing a team wasn’t what they were good at. A wise person understands themself and knows not to chase the brass ring if that’s not actually what makes them tick.
I’ve been a VP at F500 companies and never seen it done deliberately. There are plenty of ways to manage poor performers out of an organizations. Promotion isn’t one of them.
I have had it loop once. I had to abort the turn, clear the context (maybe I just compacted it?) and restarted. That seemed to clear it up. In general, I have not found that V4 Flash 0731 loops a lot or even any more than other models.
I’ve never found this to actually be the case (that somebody promoted someone they thought was incompetent to “limit damage”). Yes, incompetent employees get promoted sometimes, but it’s typically because they have been brown-nosing an executive and the executive thinks they are actually talented.
For cost reasons, I’ve been using Flash for the reviewer, too, but I plan on trying to use Pro for that. Thus far, however, Flash has been doing well at reviewing. I’m cheap as I’m paying for all the tokens myself.
IMO, ELO rating from The Intelligence company and arena.ai are more representative of rankings since they use humans to judge a head-to-head comparison between a couple models at a time.
https://www.intelligence.ai/http://arena.ai
Yep, exactly. I keep saying that I want the “coding expert” extracted from these multi-T parameter models to run locally on reasonable hardware (large laptops, not servers). Yea, I know there’s no single “coding expert” that you can actually extract in these models, but you get what I mean. Like you said, when I’m coding, I don’t care about world knowledge, and I’m fine with consulting another model when I need that.
I’ve been using v4 Flash 0731 a lot lately and you can’t beat the price performance. That said, it sometimes takes my prompts as more of a suggestion than a directive. I’ve found that introducing a reviewer subagent (even with the same model) helps push it back to what I’ve asked for. But makes every coding session a back and forth: “do X” -> “use a reviewer subagent to analyze whether you really did X as I asked”.
There is some special sauce that they have. It’s not just a simple quant of another release. Or so they imply. I don’t have any insight into how it works or what the Bonsai special sauce is.
It’s still going to chew up context quickly. Surely, some of the added tokens are helping the model, but does it require as many as it generates? What happens on long, multi step tasks as it pushes old tokens out of context? I’m not sure we know the answers to those.
You’re basically proving my point. As I said, it’s similar but incompatible, requiring a recompile or reassemble. The point being that the 32-bit instructions are not a distinct subset of all the instructions with the 64-bit instructions added on. Some of the instruction encodings from rv32 are redefined in rv64 to operate on the larger register sizes. Rv64, for instance redefines the encoding for rv32 add to work on 64-bit registers and creates a new instruction to operate on 32-bit registers. Why didn’t they just extend rv32 to add a new “add 64-bit” instruction. If rv32 was a proper subset of rv64 then it would be easier. So, can you create a cpu that runs both? Sure, but you’ll need a mode and duplicate decoders, in whole or in part. Again not the end of the world (decoders are small these days) but it still makes you go wtf? Maybe there’s something I’m missing that offsets this complexity in some other way, but it’s not obvious what that is. It would have been better, imo, if rv64 (and rv128) was a set of newly added instructions with a cpuid or capabilities bit somewhere to let software know about the hardware capabilities, similar to SIMD instructions in x86. And yes, I realize that this is still less complex than x86, but that’s a low bar.
And I suspect it’s accelerating quickly. This whole space is hyper cost-competitive and pennies matter, so being able to design whatever you want without having to talk to lawyers or pay anyone anything is a huge win and matters far more than whether something takes 1 instruction or 2.
Yes, but x86 had a goal of running every old piece of code on the new thing. That’s not true with RISC-V. Whereas x86 accreted more and more features, RISC-V solves this with profiles that are not guaranteed to be compatible with each other. RISC-V doesn’t even support running 32-bit code on 64-bit processors without a recompile. In a sense, 32-bit RISC-V is a vaguely similar but incompatible ISA to 64-bit RISC-V. That would be a train wreck if there weren’t profiles to specify a group of features that must be there (and some others that might be optional, with a register to flag whether they are or not). The expectation is that profiles act a lot more like the x86 ISA, accreting features while preserving backward compatibility. It took me a while to realize this, too, and I remember several WTF episodes while reading through the specs. And of course profiles go beyond the ISA and specify system level arch as well (like the “PC architecture” did for Windows and Linux). You can certainly argue that it should have been done differently, but it’s not completely crazy given that there is not legacy RISC-V code needing to be run on newer systems for the most part. That won’t be true forever, and so profiles help manage that.
Definitely. I’m a weird software guy that got a hardware degree in college so that I could understand all the low level stuff. I remember there was a joint project with the hardware (ECE) and software (CS) students to build a simple computer with bit slice and microcode and program it to do something (I forget what). I remember the software students being bewildered that there was no division instruction in these systems (because who needs that when you have shifts and add/subtract). Nowadays, with so much stuff running in browsers, the average software engineer has no clue what the hardware is doing.
The Clojure community is definitely less macro-crazy than other Lisp communities. But it’s also very programmer-specific. I’ve worked on OSS Clojure code where the original programmer loved macros. In general, I found it more annoying because reading through recursive macros is just more difficult than reading a simple function. So, I think it’s better for the community to de-emphasize macros, in general. Even if I want back to programming in CL or Scheme/Racket, I think I’d be much more judicious about using macros. Again, nothing against macros in general. They are a powerful tool in Lisp. But, to quote Spider-Man, with great power comes great responsibility.
Macros returning macros happens in every Lisp, including Clojure. It’s no biggie. Hygiene has nothing to do with it and there are ways of properly managing unique symbols in all Lisps, even if some dialects are more manual than in Scheme/Racket.
My own personal rule is that every Lisp programmer should understand macros and very rarely reach for them. They are a super-power, but easy to misuse. I think Paul Graham is partly responsible for the “Lisp = macros” thinking and the general overuse of them. On Lisp was a great book but it does lots of things I wouldn’t consider good practice today. After Graham popularized Lisp and macros, there was a period when every Lisp newbie, myself included, was writing macros all the time. Now that I’m older, I know better. Clojure is my daily driver and I haven’t written a macro in years (though I’ve debugged ones other people have written). But I know defmacro is there and I can use it anytime I really need to.
I’ve been struggling with this. I use Clojure and clj-paren-repair has been helpful (https://github.com/bhauman/clojure-mcp-light/blob/main/src/c...), but it would be even better if the model could be taught to do structural editing, the same way I do in Emacs.
Do you have something in a public repository I can look at?
If you write a harness in Lisp, you can easily access the running Lisp environment via tools, one of which can be a repl tool. This allows the model to do whatever it wants within that environment. Obviously, this is “dangerous” and should be sandboxed.