skohan

Infra might very well be the right play. Over the past year, it seems like the evidence is on the side that there's no "secret sauce" in AI, and models will all converge towards similar capabilities. Not much margin to be had for having the best model for a month or less until another lab leapfrogs you by 3%.

C/C++ is still relevant for HPC, where you want to carefully optimize memory management.

It might have to do with optimizing compile times. A crate is the unit of compilation, so small crates increase the likelihood that you won't end up recompiling a lot of unrelated code.

I guess smaller crates and avoiding nested modules could also help optimize for making the code greppable by coding agents without blowing up context windows.

Impressive if these benches hold up to real world use. Not groundbreaking, but certainly in the game.

Would love to see them release some smaller open-weight models.

I think the promise of personal AI agents is incredible, and they can already be super useful. But we haven't even begun to figure out the safety side for a mass audience.

Even as an experienced developer, sandboxing an agent is not trivial. The idea of my aunt, who has her passwords on a post-it-note on her monitor and forwards me scam emails using these things is terrifying.

I remember back when Facebook was still .edu email addresses only (2004 or 2005 maybe), and my university got access, we discovered you could just grab the user id of another user from their public profile, and paste it in place of your own user id on your own profile, and get access to their profile as if it was your own.

My use-case is coding. I'm typically coding interactively with an agent most of the day, and then I have overnight jobs that run every night.

As for the infra setup, I am currently using llama.cpp, although I'm just now working on switching to vllm since it is better for concurrent inference, since it can interleave prompt-processing and decode. Until now llama.cpp was enough, since I was on an R9700 and it was only practical to run one agent with decent sized context anyway.

Oh that's way cheaper to be sure, but a lot less fun!

It doesn't make sense by any standard valuation metric. Yes SpaceX is the best company in the world at getting things into space. The valuation doesn't reflect the actual size of that market at all. It's assuming AI in space will be world-changing, which is a huge leap to make.

I think hardware scarcity plays a part in inference margins. They would get squeezed super quickly if anyone who wanted could just build an inference cluster, but that's not currently the case.

Serving LLM inference is more efficient with more concurrent requests. For a single inference request, the bottleneck is GPU memory bandwidth, as the inference engine spends most of its time waiting to move values in memory. With concurrent requests, it's possible to service multiple requests in a single pass through the model weights, meaning you can utilize more of the GPU/APU's compute.

So you have to price your local hardware against however many subscriptions you would need to run a dozen concurrent agents around the clock.

But even then, I would guess subscriptions are priced on the basis that they don't expect every user to utilize their entire usage limit. I.e. power users are subsidized by casual users.

I just installed a $16k GPU at home - super pricy to be sure, but when you price it against hiring 4 junior developers working around the clock it's a steal

Haven't played it yet, but from what I know my impression was that this game was as much a test bed for his new programming language as it is an artistic expression. I wouldn't be surprised if some puzzles made it in because they were a good test of some novel comp time feature (i.e. the real puzzle game was making the language, not playing the game).

And I bought it day one without reading reviews. Whether or not the game is good, personally I'm happy to support someone who's completely self-funded working on PL design. Not that many people are in position to do that kind of work, and even fewer with a documented history of finishing things.

Being one of if not the top advertisers in the world? I think Meta is doing just fine.

I was talking to a mathematician friend about this, and she was telling me that a lot of the proofs that have been produced in the past couple weeks don't have an application.

To me it begs the question: in a theoretical world where we don't have human mathematicians anymore, what is the point of these proofs if there's no human who actually understands it?

If the point of a lot of this math is only to expand the boundaries of human knowledge, it all seems kind of pointless.

I guess it's fine if you don't mind paying for the extra tokens.

In my experience, what works for one model in terms of system prompt doesn't necessarily transfer to another model, so I would be concerned that a large system prompt would end up being a "jack of all trades, master of none" situation where your giant prompt has to try to account for the eccentricities of every single model, and might even include details that add confusion for some models.

And pi has been eye-opening for me in terms of how well newer models perform with basically no system prompt. It makes me wonder how much of the default system prompt is essentially cruft which was added to support older models which needed more guidance, and is still in there.

Pi is also super context-efficient. The out-of-the-box system prompt before adding tools and skills is like dozens of tokens.

OpenCode was thousands or tens of thousands last time I checked. Not sure if this has been improved.

Seems foolish to use a single-vendor harness to be honest. With how fast things change, and the price/performance you get from open weight models, building a workflow around a single llm provider seems super limiting.

Adding MCP and code mode seems so antithetical to the minimal ethos, I almost would believe they got incentives from Jen, but I don't want to be that cynical.

If they take Neural Rendering far enough, they can get rid of those useless raster and RT cores completely and ship compute and tensor cores only on all their chips

I think MTP is kind of ok, since it's a common protocol, but I think incorporating sub-agents could be a mis-step.

There are a lot of ways to implement sub-agents, and it's not something I need the harness to be opinionated about.

I know builtin tools support opt-out, but it's more bloat. It's also more complexity for the agent to understand when you use it to build extensions for itself.

Do you have any plans to support ROCm?

Do you have anything published on the quality benchmarking using your caching strategy?

You could already use MCP perfectly well on pi via extensions.

I'm not so sure about this move, or the general inclusion of code mode in the core editor as one of pi's main selling points was its minimal nature.

Let's say I have an aligned agent, and I want to give it access to my bank account to track my budget, and my email so it can automate responses to certain messages, and automatically unsubscribe from junk emails.

Nether service has a way to configure fine-grained access for a secondary user.

How do I go about giving the agent the ability to perform these tasks without exposing myself to the risk of unexpected destructive behavior from the agent?

So how would you go about sandboxing Muse in a way that it still functions as a general purpose assistant?

Yeah I think people are probably widely underestimating the risks. Like if you gave another programmer unlimited access to your system and ssh keys, and they never slept and could code and run terminal commands at dozens or hundreds of words per minute, you would have to trust them a lot to give them that.

And I love pi - it's my daily driver - but the extension system itself is an attack vector. If any process manages to write an extension to your .pi directory, it could rewrite your prompt to have the agent exfiltrate your secrets, or take whatever action on the host system if you don't sandbox it.

That helps you if the blast radius is on your machine, but it doesn't really help if the agent is using your credentials to cause some damage with some remote system you have access to.

When I was kicking the tires on pi, one of the first things the agent did was push an update to one of my published Rust crates (not the project it was working on).

That in itself wasn't harmful, but it did convince me it was worth the effort to figure out sandboxing after that.

I sandbox my coding agents using bubblewrap, but I don't think it's as trivial a problem as you make it sound.

For something like muse that's supposed to be a general-purpose assistant, how do you give it enough access to be useful, without giving it too much access, and creating unacceptable risks? And how do you do that in a way that's comprehensible the average Facebook user who's the target market of this product?

Sandboxing the agent application is easy. The tough part is sandboxing in such a way that it's still useful.

I.e. if I have an agent running in a WASM sandbox with no access to the host system, I can't ask it to clean up my files. Same thing with things like giving an agent access to your email inbox: doing so allows the agent to provide utility, but it comes with risks, as the agent can delete important emails, or leak sensitive data.

I think a big part of the problem is, a lot of the systems we use and would like agents to help us with don't have a concept of separated roles with different levels of access which can be applied. A lot of times it's all or nothing.

And even when we do have fine-grained access control available, it's a pain in the ass to manage it. Like you can create a GitHub token with fine-grained access control to your repositories and make sure the agent only uses that one to connect, but it's a whole lot easier to use a broad-access token, or just let the agent use your own token, so lots of people will just end up doing that.

And I also like pi, but it's probably one of the worst in terms of sandboxing as it's yolo by default.