dirk94018

Author here. I own LinuxToaster and wrote this after getting frustrated with every AI tool asking me to move into its interface.

The short version: Unix survived 40 years because small tools compose. Most AI products are doing the opposite — building walls. I think that's a mistake, and I tried to explain why with some concrete examples from tools we've built.

Curious whether others feel the same friction, or whether I'm just a grumpy Unix person.

But wait.. there's even more..

Jam did a great job with its times and while. But sometimes you want map, so we wrote a couple more command line utilities:

imessage bot toast "reply in a friendly tone"

email bot toast "reply in a friendly tone"

One line agents. You now have an iMessage assistant and an email assistant running. Personality lives in a `.persona` file next to it, so you can version it, grep it, diff it.

No webhook setup. No OAuth dance. No "agent platform." The bot is just `toast` wrapped in a daemon that knows how to read from iMessage or IMAP and write back. Unix composition all the way down.

Fair. The posts have all been from our blog, because that's where I write. I'll make a point of submitting other things I find interesting too. In the meantime, happy to discuss the actual ideas in the article if anyone's curious. If you look at the posts, each one is something very different. AI bots creating a shared reality. Open source having a serious supply chain problem today. Gradient descent applied to code. Writing an inference engine from scratch. Each one stands on its own.

After reading the guidelines...

This IS the original source. I wrote it. The guidelines explicitly ask for this.

A post about supply chain attacks, the economics of open source, and the LiteLLM compromise that happened today is squarely on-topic for this audience.

Is "You're over-doing the self promotion" without engaging a single idea in the article a shallow dismissal?

Management is cargo culting the tooling without grasping what AI is actually good at. Because they don't look at it. Meanwhile smart blue collar guys are only limited by their willingness to ask questions. Because they do. It's the difference between the performance of work and work. The most fascinating aspect about AI may just be what it tells us about people, work, and society.

Fair point. The article doesn't mention LinuxToaster's products — the curiosity here is about the future of open source, not promotion. For what it's worth, toastd does what LiteLLM does in C with no Python supply chain, which is part of what got me thinking about this topic in the first place. But that's not in the post.

Author here. I run LinuxToaster, a set of commercial Unix tools for the AI era. This started as notes after watching the LiteLLM compromise unfold in real time — 94 million monthly downloads, credential stealer active for three hours, maintainer's GitHub issue closed as "not planned." Same week Cloudflare showed one engineer could clone Next.js in a week for $1,100 in inference costs. The thesis: the economics that created open source have inverted. Production used to be expensive and trust was free. Now production is nearly free and trust is the expensive part. Open source is getting hit from every direction — supply chain attacks are cheaper to execute than to detect, corporations clone instead of contribute, and individual devs yoink the three functions they need instead of installing the package. Happy to discuss. I know this is a spicy take for HN.

Author. Esther was right about the bots indexing the wreckage. She just didn't know she'd be the wreckage. HN (native app + web), Discord, Facebook, LinkedIn, Lemmy, TikTok, Bing, Yandex, Perplexity, plus a bunch of RSS readers (Miniflux, FreshRSS, News Explorer) and scrapers.

Author here. Good points.

We renamed to UnixClaw — too many NoClaw namespace collisions.

On the .tools gap: you wouldn't put `rm` in .tools. The tools are purpose-built — `kal` talks to Calendar.app via EventKit, `rem` talks to Reminders.app, `contacts` talks to Contacts.app. None of them can do anything outside their domain. If you did want file deletion, you'd write a safe version that moves files to a recovery folder instead.

On the Gemini trick of disabling its own guardrails: `chmod -w .tools` by the human means toast can't modify its own permissions. The AI can only call what you've allowed, and it can't change what's allowed.

The invocation-level concern is real for general-purpose commands. Our answer is: don't give it general-purpose commands.

.tools is also directory-specific — toast walks up the tree from cwd. So your assistant handling iMessages can have a different permission set than a coding project. Least privilege, scoped by context.

Author here. Now renamed to UnixClaw. We wrote small C CLI tools that bridge Unix pipes to native macOS apps — Calendar, Reminders, Contacts, iMessage, email. Combined with toast (our LLM CLI), the whole assistant is one line: imessage bot 'toast "You are the executive assistant"' No daemon, no plugin registry, no Python. Config is three text files: .persona, .tools, .crumbs. Toast works with BYOK (Anthropic, OpenAI, Cerebras, etc.) or locally via toasted on Apple Silicon at ~100 tok/s. The NemoClaw announcement (https://news.ycombinator.com/item?id=47427027) has great discussion about whether more layers fix OpenClaw's security problems. Our take: security comes from having so little code you can read all of it in an afternoon. Happy to answer questions about the architecture.

Relevant timing: the NemoClaw thread (https://news.ycombinator.com/item?id=47427027) has a lot of discussion about whether sandboxing solves OpenClaw's security problems. We think the answer is fewer moving parts, not more layers.

NVIDIA's answer to OpenClaw's security problems is to add more layers. LinuxToaster's answer is to use fewer:

https://linuxtoaster.com/blog/noclaw.html

Author here. We built NoClaw after watching OpenClaw users burn $800-$3600/month on tokens, deal with 1,100+ malicious ClawHub skills, and have agents email their entire contact list unprompted.

An AI assistant can be genuinely useful but it doesn't require 400,000+ lines of code and burn tokens like they are free.

We use small C CLI tools that talk to native macOS apps, Emails, Calendar, Reminders, Contacts — so everything syncs to your other devices, connected by Unix pipes. The whole assistant is `imessage bot 'toast "You are the executive assistant"'`. Inference runs locally on Apple Silicon at zero cost and data never leaves the machine. Alternatively, have Cerebras, OpenAI, or Anthropic do some of the inference. You know, you are in control.

Permissions are a text file called `.tools`, one command per line. Revoke email access by deleting a line. Audit with `cat .tools`.

Happy to answer questions.

Came across as honest. Because why else.

Totally agree. We need to get the ratio between deterministic and non deterministic software right.

Unix approach can be surprisingly powerful.

https://linuxtoaster.com/blog/gradientdescentforcode.html

MCP is a bit of a rube goldberg machine. Unix solved that problem. Pipe text in, get text out, discover capabilities incrementally. The fact that we need benchmarks to prove CLIs use fewer tokens than dumping 55k of JSON schema upfront is embarrassing. toast is just pipe stuff to an LLM and let stdin/stdout be the protocol. No schema tax, no connection lifecycle, no tool registry middleware to manage your middleware. The thing is that AIs are just not good at outputting structure, like people, json isn't natural.

"Driven by curiosity and envy, I tested it out." Two days of work driven by envy. Not what open source should be about.

Interesting. I wanted to do toast | bash to let the AI drive the computer but the bash shell really got in the way. Too much complexity. The things that annoy humans, $ expansion, special characters, etc don't work for AI either. Ended up writing a custom shell for AI (and humans). When a tool gets in the way, sometimes it just time to change the tool.

Author, got annoyed by Python startup times, frameworks, orchestration layers, and the general state of AI tooling. We write everything in C/C++. Toast overhead is ~20ms per invocation — that's what makes the loop practical - toastd does https connection pooling. With Cerebras it can run at ~2000 tok/s. Local toasted gets ~100 tok/s with 0.6s time-to-first-token. Happy to answer questions.

We wrote the linuxtoaster inference engine, toasted, and are getting 400 prefill, 100 gen on a M4 Max w 128GB RAM on Qwen3-next-coder 6bit, 8bit runs too. KV caching means it feels snappy in chat mode. Local can work. For pro work, programming, I'd still prefer SOTA models, or GLM 4.7 via Cerebras.

Author here. AI as pipe, not platform. toast is sed with a brain — reads stdin, writes stdout, honors the Unix contract. We're rewriting the command line around that idea, one tool at a time.

Generation is cheap now. Review is not. The skill that can't be automated is the stopping condition. Knowing what should not exist.

The market wants agents. Agents don't work. A pipe does. If this resonates and you build this way, I'd like to talk.

Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind. Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.

You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.

Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.

Simplicity is hard. Mark Twain's 'I would have written less had I had more time' at the end of a letter comes to mind.

Software dev's tendency to build castles is great for technical managers who want to own complex systems to gain organizational leverage. Worse is better in this context. Even when it makes people who understand cringe.

You would think that things not breaking should be career-positive for SysAdmins, SREs, and DevOps engineers in a way it cannot be for software devs. But even there simplicity is hard and not really rewarded.

Unix philosophy got this right 50 years ago — small tools, composability, do one thing well. Unix reimagined for AI is my attempt to change that.

For chat type interactions prefill is cached, prompt is processed at 400tk/s and generation is 100-107tk/s, it's quite snappy. Sure, for 130,000 tokens, processing documents it drops to, I think 60tk/s, but don't quote me on that. The larger point is that local LLMs are becoming useful, and they are getting smarter too.

On M4 Max 128GB we're seeing ~100 tok/s generation on a 30B parameter model in our from scratch inference engine. Very curious what the "4x faster LLM prompt processing" translates to in practice. Smallish, local 30B-70B inference is genuinely usable territory for real dev workflows, not just demos. Will require staying plugged in though.

Author here. This started because our C inference engine was slower than Python, which was annoying.

We got it to 400 tok/s prefill, 100 tok/s generate, 1,800 lines of C++, no dependencies beyond MLX. Just not redoing work was a 125x improvement.

Favorite moment: the model suggested enabling MetalFX to speed up inference. That's Apple's game graphics upscaler. It makes explosions look better.

AMA about any of it. We are working on the Qwen3.5 models. Local AI is going to get a lot better.

I'm saying the capability to reason about novel situations is in tension with guaranteeing it never produces harmful outputs. We are talking about contradictory design constraints.

Isn't a safe and reliable intelligence an oxymoron?

Don't nerf the models. We don't know what we are losing. DOW said it out loud.