>it looks like either this battery changes the world within the next 3 months, or it will make the CEO look like a fool.
looking at the richest person on earth today, I think we have established at this point truth doesn't really matter, so I think its safe to say the CEO have little to worry about looking like a fool or to face any kind of consequences really.
Skeptical, but still, I hope the company is for real
can you point me to this claim? also last i checked trying to connect to OpenAI seems to prompt for an API key, does openAI's API key make use of the subscription quota?
just wanted to make sure before I sign up for a openAI sub
The readme (and probably most of the project) is likely generated by an LLM - chances are we'll learn more reading the prompts than the readme.
I actually tried this few days back before the Claude Code EULA reinforcement, I went through the same thing.
1. I honestly had a hard time parsing what this is supposed to do or provide over standard opencode setup from the readme. It is rather long-winded and have a lot of bombastic claims but doesnt really explain what it does.
2. Regardless, the claims are pretty enticing. Because I was in experiment mode, and I already had a VM running to try out some other stuff, I gave it a try
3. From what I can tell, its basically a set of configs and plugins to make opencode behave a certain way. Kinda like how lazyvim/astronvim are to neovim.
4. But for all its claims, it had a lot of issues - the setups are rather brittle and was hard to get working out of the box (this is from someone who is pretty comfortable tinkering with vim configs), when I managed to get it working (at least I think its working), its kinda meh? It uses up way more tokens than the default opencode, for worse (or at less consistent) results.
5, FWIW, I dont find the multi/sub-agent workflow to be all that useful for most tasks, or at the very least its still very early IMO, kinda like the function calling phase of chatgpt to really be useful.
6. I was actually able to grok most of Steve Yegge's gastown post from the other day. He made-up a lot of terms that I think made things even more confusing, but I was able to recognize many of the concepts as things that I also had thought of them in a "it would be cool if we can do X/Y/Z" manner. Not with this project.
TBH, at this point im not sure if I'm using it wrong or am I missing something, or this is just how people market their projects in the age of LLM.
edit: what I tried the other day was the code-yeongyu/oh-my-opencode, not this (fork?) project
Re point 5, the simplest argument in favor of sub-agent workflows it that it allows the main agent context to remain free of a large amount of task-specific working context. This lets the main context survive longer before you need compaction. Compaction in CC is a major loss of context IME. Context compaction is generally the point where I reset the conversation as the compacted conversation is practically as bad as a new one but has a bunch of wasted space already.
How I wish we could just see and patch up the raw context before it goes out. If I could hand edit a compaction it would result in better execution going forward and better for my own mental model. It’s such a small feature, but Anthropic would never give it to us.
hah - i'm the opposite, I want everything done by the AI to be a discrete, clear commit so there is no human/AI entanglement. If you want to squash it later that's fine but you should have a record of what the AI did. This is Aider's default mode and it's one reason I keep using it.
Honestly, one thing I don't understand is why agents aren't organized with unique user or group permissions. Like if we're going to be lazy and not make a container for them then why the fuck are we not doing basic security things like permission handling.
Like we want to act like these programs are identical to a person on a system but at the same time we're not treating them like we would another person on the system? Give me a fucking claude user and/or group. If I want to remove `git` or `rm` from that user, great! Also makes giving directory access a lot easier. Don't have to just trust that the program isn't going to go fuck with some other directory
The agents are being prompted to vibe-code themselves by a post-Docker generation raised on node and systemd. So of course they emit an ad-hoc, informally-specified, bug-ridden, slow reimplementation of things the OS was already capable of.
Probably because Linux doesn't really have a good model for ad-hoc permission restrictions. It has enough bits to make a Docker container out of, but that's a full new system. You can't really restrict a subprocess to only write files under this directory.
For plain Linux, chmod, chmod's sticky bit and setfacl provide extensive ad hoc permissions restricting. Your comment is 4 hours old, I'm surprised I'm the first person to help correct its inaccuracy.
This doesn't meet the requirement. It doesn't restrict a certain subprocess to only write in a certain directory. You are just saying these things to quickly shut down the uncomfortable thought that Linux can't do something.
Or perhaps you need to go read my original comment again as you missed the premise. But if you feel you have perfect memory then perhaps look at something like firejail or read more about systemd.
But your premise of Linux "can't" do something is rather absurd. It's Linux, you can do anything, even if no one has done that thing before.
The reason people didn't respond earlier is because they probably assumed it a waste of their time. I know I have wasted mine
You chose to respond to a question I posed, with an extremely poor answer. I was very specific about restricting a certain subprocess to only write to a certain directory. Your answer does not do that. I pointed that out. Now you are defending that answer by claiming you were actually answering something else entirely. This is nonsensical.
su: user claude does not exist or the user entry does not contain all the required fields
Clearly you're not asking that...
But if your question is more "what's stopping you from creating a user named claude, installing claude to that user account, and writing a program so that user godelski can message user claude and watch all of user claude's actions, and all that jazz" then... well... technically nothing.
But if that's your question, then I don't understand what you thought my comment said.
Yeah, that is what I meant. I mean, it's kind of the system administrator's/user's responsibility to run processes in whatever user context they want. I don't wonder why, like, nginx doesn't forcefully switch itself to an nginx user. Obviously if I want nginx to run in some non-privileged context (which I do), then I (or my distro, or my container runtime, or whatever) am responsible for running nginx that way.
Similarly, it's not really claude-code's job to "come with" a claude user. If you want claude code to run as a low-privilege user, then you can already run it as a low-privilege user. The OS has been providing that facility for decades.
I'm a mild user at best, but I've never once seen the various tools I've used try to make a git commit on their own. I'm curious which tool you're using that's doing that.
Same here. Using Codex with GPT-5.2 and it has not once tried to make any git commits. I've only used it about 100 times over the last few months, though.
Why not use something like Amp Code which doesn't do that, people seem to rage at CC or similar tools but Amp Code doesn't go making random commits or dropping databases.
just because i havent gotten to try it out really.
but what is it about Amp Code that makes it immune from doing that? from what i can tell, its another cli tool-calling client to an LLM? so fwict, i'd expect it to be subject to the indeterministic nature of LLM calling the tool i dont want it to call just like any others, no?
Making a git commit typically doesn't require any special permissions or credentials since it's all local to the machine. You could do something like running the agent as a different used and carefully setting ownership on the .git directory vs. the source code but this is not very straightforward to set up I suspect.
Typically agents are not operating as a distinct user. So they have the same permissions, and thus credentials, as the user operating them.
Don't get me wrong, I find this framework idiotic and personally I find it crazy that it is done this way, but I didn't write Claude Code/Antigravity/Copilot/etc
i remember listening to Adam in one of the podcast he was in (I think it was either the Hackers Inc, or the Art of Product, but could've been something else where he was a guest) - and I remember that he mentioned that idea that there are always a new wave of new developers that they can sell the product to.
I still think he was correct. I myself bought tailwindUI as an aspirational purchase, and i doubt people would pay for it as a subscription.
But I think a lot has changed in the last few years. There arent probably as many new developers given the market, and among those there are probably even less that are willing to pay $100+ for a UI library, not when there are competitions like shadcn or radix or many others as free alternative, or when you could just ask an LLM to generate them for you.
Tailwind Labs definitely need to explore new revenue streams, but i dont think UI components is the way to go. Without knowing their internal data, this is just a guess, but I doubt traffic to docs or pipeline to premium products is much of a factor in the decline.
I believe the new UI libraries hit hard more than the AI impact. AI is not always that accurate so eventually if you want to deep dive in, you still have to turn around to the doc. But the new libraries though, they give the market another good choice, especially when shadcn came out, it's so huge that I personally even feels there's no need to go for the raw Tailwind experience, and what's worse is that shadcn is still evolving fast.
I believe the only way to let Tailwind survive is changing the business model.
i bought Tailwind UI years ago and have barely used it outside of like a couple of abandoned side projects. I bought it knowing that is going to happen because it is a one-time payment, and the idea of supporting the project/Adam is prob a bigger factor that the product.
I definitely wont even consider it if its a subscription.
Selling UI components is a hard sell to begin with - i think they made the right decision with a one-time point payment at that higher price point. If it were a subscription, i probably would've cancelled it within 2 or 3 months.
I was briefly involved in a GitHub discussion that happened before the fork but I think I got the reason why. People (well, me in that case) were asking for more fine grained options like per project instructions, and the Cline author's response was basically "not interested in the added complexity but feel free to fork". So somebody did.
Although I think Cline did eventually add some of the requested options.
as a user, cant say much about the hardware side - but on the software side they aren't the most developer friendly IMO.
APIs are locked behind "contact us" button and is only reserved for enterprise users with seemingly arbitrary criteria on what/who they want to work with
looking at the richest person on earth today, I think we have established at this point truth doesn't really matter, so I think its safe to say the CEO have little to worry about looking like a fool or to face any kind of consequences really.
Skeptical, but still, I hope the company is for real
reply