".. unless his name is Madagascar."

https://www.youtube.com/watch?v=3AMqNG5KGaA&t=1s

Interested to know throughput on 7900 XTX and what setup you're using?

Terminal is a significant risk though and I’d still really like to see macOS improve the APIs around filesystem access.

Granting terminal full disk access grants arbitrary scripts full disk access. There’s a lot you can do with ACLs and the permissions system, but it’s not reflected in the UI for settings.

Then there’s allowing access to documents, downloads, desktop, external disks. This should really allow the user to select a path or paths for applications, because these options are way too broad (especially external disks).

This is why I use Terminal as my primary terminal, and iTerm as my AI terminal. iTerm gets no permissions, I move specific things to Terminal to do it. Plus I can then style them to optimize for the different usages. And iTerm has better harness hooks anyway.

I would still like to see not only more granular permissions, but single use permissions. Once I grant iTerm access to Documents for whatever reason, it always has such permission. I would be nice to limit that to a single use, or a single harness session.

> Granting terminal full disk access grants arbitrary scripts full disk access.

Indeed, I run all dev tools including coding agents inside sandbox now

https://github.com/ashishb/amazing-sandbox

I do the same but I rely on devcontainers because editors like vscode, zed, etc… provide native support. It seems easier to use than asb.

If you open a project using a devcontainer it prompts you to build one. As long as you install all the tools you need in it, it just works.

Orbstack is much nicer than Docker to host the containers.

> Granting terminal full disk access grants arbitrary scripts full disk access

No, it grants scripts I run full disk access. Unvetted scripts do not run in my terminal, so there are no secret sub-processes either.

I would want terminal and all its subprocesses to have full disk access - I do tons of stuff from the command line and don't run nonsense stuff.

get out of my way.

I think the lifecycle for these chips could stretch far longer. If you're offering these models on a two year lifecycle, then you'd be able to stand up your top tier (wouldn't need to be frontier) at high speed. Run (for example) Kimi K3 on it and give it a brand name:

AcmeAI Carbon

Market it as your premier (only) model at high throughput. Two years later you stand up MSICs for the new state of the art with entirely new hardware, your lineup becomes:

AcmeAI Nitrogen (top tier) AcmeAI Carbon (mid tier)

If you just kept pushing the same model down your pricing tier over time you could still extract a lot of value from an old model, even years after it's been set in stone. Working on brand new code/frameworks? Pay to use the newest model. Working on legacy code? Use the lower tier models that will already know your legacy frameworks, pay far less and still get massive throughput. I've worked on a lot of government projects that this would be absolutely brilliant for.

The other side of this is that agent harnesses are NOT set in stone, so even a legacy model with a knowledge cut-off that's years out of date can likely still be helped quite a bit by harness and fetch behaviours that are still developing rapidly. Especially at this kind of throughput.

I'm somewhat doubtful that we will be seeing something as large as Kimi K3 in silicon any time soon.

This tech can definitely scale up from the current 8B prototype, but - at least as far as my limited understanding of the tech involved goes - you cannot just ASIC a trillion weights model due to physical size constraints.

___

Specification HC1

Model Llama 3.1 8B (hardwired)

Process TSMC 6nm

Die size 815mm²

___

So the current prototype already pushes the limits of what we can fit on a single die, and that is already likely going to limit your yield.

This is an architectural limitation that may be overcome by how you bake the MoE (mixture-of-experts) onto silicon.

If you could manage a per-die expert somehow and keep the expert routing gate relatively fast (through an interposer interconnect or doing wafer-scale Cerebras type shit) you don't need to keep the whole thing on the same die. Small dies with one expert per die on an interposer, and a very tiny router might be sufficient.

Kimi K3 is huge, though. Deepseek V4 Flash is a much more moderate model (284B total), and it works extremely well. Models of that size, and smaller, are just going to keep getting better and better. Presumably there's a threshold below which models are not generally useful or competitive, but if models-on-silicon can scale up to just 256B, that would be really remarkable.

My 2 cents to for your point:

- Deepseek V4 Flash is impressively capable. Sonnet still beats it out by a thin margin, but the real kicker is that a typical session with Sonnet at current API costs is ~$2. The same session with Deepseek is 2 cents (ha). Its even allowed me to consider offering free-with-limits API usage on my own app. - Taalas (or competitors) have a lot going for them. If anything I feel like they need to join hands with these smaller model makers and converge in 2028

This is a net good for Linux.

Most of the PC gaming audience is on Windows, so Windows is still the primary target being developed against. Having better Vulkan on Windows means more support for Vulkan in games in the pipeline, which means better Linux support in those games over time, which ultimately benefits Steam and their hardware.

Now it’s our turn to embrace, extend …