Microsoft did that for a lot longer than I expected honestly. Historically they would take a year or so before giving up on the "you're an independent company" bit and merge the team into MS orgs.

GitHub pulled it off for 5ish years before that began to change, and it was only last year when they stopped having their own "CEO".

I want to ask what makes them magic, but even those building LLMs don't really know what happens when they run inference...

I have to assume current architectures aren't optimal though, the idea that we stumbled into the one and only optimal solution seems almost impossible.

I'd assume its a totally different architecture that isn't based on storing a compressed dataset of all digital human text.

It seems pretty clearly inline with the dotcom bubble to me. Every company claims to be a leading AI company, those building infrastructure are promising the moon and getting 1/3 of the way there, and no one knows how to monetize it justify the hype or expense.

Knowing what's installed would have to be an OS API. If LLMs provide a standard API surface to the OS, likely including metadata related to feature support.

You're also embodied and experiencing the world around you with more senses than only the ability to read text.

> the only "dataset" you need is a bunch of sensors and the world around you.

Personally I wouldn't want a couple dozen apps installed all with their own model.

It seems easier to have industry specs that define a common interface for local models.

I also assume the OS can, or would need to, be involved in proving the models. That may not be a good thing depending on your views of OS vendors, but sharing a single local model does seem more like an OS concern.

I mean the openai API is the industry standard for allowing apps to communicate with models, llama-server has it, oMLX has it, ollama has it, vLLM has it, lmstudio as well. I don't think this is such a hard thing to do, but it requires people to set it up.

I don't know enough about that API surface to know if its a particularly good one for the use cases we'd have, but yes defining a universal spec for all implementors to support wouldn't be a big lift and is done in plenty of other areas already.

If I were to reach for HTML to consume LLM markdown files, and that is an interesting idea, I'd want to use a build system and define my own design system for my specs.

I'd still want the LLM using markdown, its a much better fit than HTML for loading context. I'd want to consume it in a nicer visual representation. It writes something like `<ds-table>` and it builds to a styled HTML table for me.

Since the LLM craze started I have always assumed it would end up in a place where programming languages are dead and LLMs generate something more low level.

Programming languages were always designed as an abstraction to allow humans to more easily instruct a computer than by writing binary or assembly. If humans write natural language and don't check the generated code, there's no reason to take the hit of generating C, JS, etc that still has to be compiled and/or interpreted.

If anything LLMs should use something higher level because it compresses the context and makes programming closer to natural language they are trained on.

Forcing LLMs to do a shitty job of what a compiler can do deterministically is not a good approach IMO.

Low level was the wrong term for me to pick there. I was meaning more along the lines of "purpose built". I.e. I could see a language, potentially still an abstraction requiring a compiler, that isn't meant to be particularly meaningful or inspectable by humans. For LLMs your right, conciseness would be important and that would likely mean it would be compiled.

Wasn't 4.6 Sonnet a 1T model?

Parameters and compute are quite the same thing, but going from 1T to 5T to 10T is quite a ramp up.