I use Pi and mostly open weight models. I pay for the $20/month Ollama plan and use Deepseek and GLM through that. I’ve never hit the limits on it, but I tend to ask for targeted things rather than “implement a whole feature in one prompt”.
I do keep an OpenRouter account topped up for things that Ollama doesn’t have. 99% of my usage there is embeddings, the other 1% is wanting to test some new model Ollama doesn’t have.
I wrote an agent launcher sort of bash script. Pass in the command to start the agent, the script checks if there’s a Jinja file in a special directory matching that name, and builds it to AGENTS.md. Then it launches the agent.
I was trying to use it as a sort of janky RAG. I had a bunch of snippets (one for DB architecture, one for how load balancing works, etc), and my Jinja files were mostly a list of snippets to pull in. Voila, a bunch of agents that share little pieces of info but have a single source of truth.
I never got a ton of value tbh, it was very good at just grepping the snippets.
Search on the app store sucks too. I haven't been able to find either a way to search for only apps that charge for downloads (I don't want to watch an ad for features, or nickel and dimed on IAP), or some kind of "minimum price" slider I can use.
That feels like a bog-standard search feature on a marketplace. I can only assume the omission is intentional.
"Stop guessing. AppRaven(.app) shows you what people really search for on the App Store, what they complain about in the apps that already exist, and hands you a plan you can start coding today."
I’m not a lawyer either, but this feels a bit like a shotgun blast of reasoning for the bill that will surely confuse the courts when they have to interpret it.
Eg I haven’t finished reading it, but it cites Heller on the first page and enshrines that AI is/can be used for self defense. That feels like a huge can of worms for the court, because now every 2A case in our history is relevant to any AI bill.
I also don’t know that it will accomplish what the author intends. Even if we hypothetically establish that AI use is covered by the first and second amendments, the government can still regulate it if they can pass strict scrutiny, ie if they have a worrisome enough complaint.
What the author wants, at the level of certainty they want it, would require a constitutional amendment and dismantling the strict scrutiny system. No idea what the impact of that would be, but my wild guess is “probably bad”.
I went with Docker because history has taught me that new isolation strategies _will_ have escape bugs at some point, and I’m distrustful that the LLM can’t find one if it wants to.
> Probably the biggest (and least hardened) feature that I spent time on in mine was trying to figure out how to allow arbitrary GUI apps so that I could run agents in it via Zed.
I actually have code for this if you want to use/fork/borrow it. TLDR, mine pretends to be an ACP agent so you run Zed on the host, but under the hood that binary is just creating a Docker container with your image and agent, copying files, etc, and then proxying ACP messages via web socket back and forth. Except for the built-in ACP read/write file and shell endpoints. Those get executed inside the container by the proxy by default, though there’s a config option to pass either or both through to the host.
It does wrap them in protobuf and there’s some router-like stuff so you can add your own non-ACP messages between the two ends of the proxy.
main also has experimental wasm plugin support in the proxies so you can block prompts/tool calls/whatever in an agent-independent way, or add RAG that works for every agent in the world, or whatever.
I've taken to sandboxing my entire agent in a Docker container. I wrote a tool that pretends to be an ACP client but is actually making Docker containers, copying files I specified in, bind-mounting, etc, and then proxying ACP via websocket to an agent in the container (except the ACP terminal/FS commands, those happen in the container).
It works well, though there is some leakiness around paths. I opted to make it place/mount files at the same path as on the host so paths are the same (as opposed to manipulating the ACP messages to modify paths on the fly, that felt messy and buggy).
Configurable networking is on my list for the future, but I haven't decided whether to start with IP-level firewalls or if it's better to start with a proxy and firewall rules to force traffic to it. IP firewalls suck for APIs that might have semi-dynamic IPs.
Robo vacuum charging is almost inherently safe. They probably charge at something like 12V/2A. Voltage too low to penetrate skin, wattage too low to cause serious injury unless you’re really trying.
You can kind of just leave them exposed and live.
None of that applies to a 220V, 50A (or whatever amperage) charging. That can absolutely kill somebody; jet fuel may not melt steel beams, but 11,000W sure will.
You’d end up needing some kind of recess probably, and then getting cars to connect to it like planes refueling mid-flight is a nightmare. You could try some sort of USB-C like signaling before power is sent, but people are never going to enjoy “exposed 220V contacts that may or may not be live depending on if things malfunctioned”.
The point wasn’t that my robot vacuum is handling large current but that “moving device connects to power” is a solved problem. A car capable of driving itself onto this pad could as easily drive itself to a spot to plug in. Extendo-arm from the car could easily slot into an outlet in the floor. Or vice versa. Or a wall or pole.
Planes refueling mid flight is hardly an apt metaphor given the charging station isn’t moving at all and the car can move as slowly as needed.
This seems like one of those “reality has a surprising amount of detail” situations.
Surely getting something to autonomously without fail extend an arm and plug in for the lifespan of these vehicles vs just park in this allocated spot you would park in anyway is an obvious tradeoff.
It’s definitely a trade off but both options have a lot of real world concerns. If safeguards on the wireless pad fail you could easily cook an animal or start a fire. The bottom of the car now needs to be metal free to allow this to work. Distance matters which means if it charges your Porsche it might not be able to charge a Rivian and certainly not with the same efficiency.
I also frankly do not believe the 90% efficiency claim because it seems so much higher than any other wireless charging I’ve heard of.
This seems like one of those things that seems cool but is not generally practical. As a convenience for wealthy Porsche EV owners, sure. As a general purpose charging solution? I doubt it.
Starting a fire, maybe, cooking an animal, extremely not likely.
Turn on an induction stove to max. Put your hand on it. Did it burn your hand? No. Put a ferrous pan on it. Suddenly, really hot.
Same concept happening here. A 36" induction stove top is likely putting out about the same inductive power. If the risk of being over the pad while it operated was enough to burn someone, so would cooking food on an induction stove.
> A car capable of driving itself onto this pad could as easily drive itself to a spot to plug in. Extendo-arm from the car could easily slot into an outlet in the floor.
Those two things really aren't comparably difficult. Eg in the dumbest case for pads, you could make the pads slightly smaller than axle diameter (to prevent dead shorts) and have the car randomly jostle around the space until it detects current flow. I've seen some amateur systems that work vaguely like this. Some signal that charging is nearby, and then a semi-random search to find exposed contacts.
That's not going to cut it on a recessed outlet. Your odds of hitting it randomly are tiny, and it will probably the damage the port with enough repetitions of ramming it into the floor.
> Planes refueling mid flight is hardly an apt metaphor given the charging station isn’t moving at all and the car can move as slowly as needed.
Change your reference point to the plane carrying the fuel and they get an awful lot closer. The planes are moving a lot relative to the ground, they're moving very little relative to each other. I'm not sure if you've watched them doing it, but relative to each other it's actually a very slow process.
> Your odds of hitting it randomly are tiny, and it will probably the damage the port with enough repetitions of ramming it into the floor.
Why would it be random? The scenario here is self driving cars. Suddenly we are talking about random jostling instead of actually targeting.
> Change your reference point to the plane carrying the fuel and they get an awful lot closer. The planes are moving a lot relative to the ground, they're moving very little relative to each other. I'm not sure if you've watched them doing it, but relative to each other it's actually a very slow process.
What is your point here? I’m totally lost. You seem to be trying to hand-wave away the difficulty of refueling mid flight. The specific difficulty there is the fact that it’s happening at high velocity, not the difficulty of plugging a hose into a port. (Traditional mid air refueling is manually directed anyway.)
You are probably fully capable of fueling your car at a self serve gas station. Try doing the same at highway speed. Just reach out the window of the vehicle you are in and fill up your friend’s car from a gas can. Should be easy since the cars are “moving very little relative to each other”, right?
Doesn’t Git store data in sparse files? My impression is that git’s on-disk layout is exactly the kind of thing you’d avoid on object storage. Interactions involve a ton of small reads, resulting in poor performance and enormous bills.
It only really makes sense to tarball repos into cold storage on S3 or Glacier, but short of GitLab cloud I suspect there aren’t enough repos cold enough to be worth the dev costs.
S3 that doesn’t have wild costs for git objects sounds like it’s just NFS
Git does not use sparse files no, however in packs objects are delta-ified: any object can be either literal or a combination of literal segments and range copies from a base object, and that base object can be the same, recursively. So to resolve any object you need to jump around a fair bit in the pack file. The normal GC creates delta chain of length 10, aggressive defaults to 50, the maximum is 4095.
I don’t think this delineation is that clear, unless by “application” you mean the app tier of a 3 tier app.
Postgres and Nginx make sense in system programming languages; they’re extremely performance sensitive and that granular level of control offers them features. Interpreters are sort of the same, they interact with the OS a ton, it makes sense to work in the same language as the OS.
I do generally agree for the app tier of a web app. I wouldn’t build a CMS in Rust, but I also wouldn’t build a reverse proxy in Python.
Writing an operating system kernel in C is valid usage since there's a great deal of thought going into it and it almost never changes.
EVERYTHING ELSE is invalid usage no matter how performance critical people claim their application is. These are just excuses for people to use a grossly unsafe language to get that last 2% of performance whilst costing the world trillions in lost productivity and security breaches.
Some of them are a sort of hydraulic one that uses a spring and some fluid to make the spring release slowly. No idea which you would have lol.
The slow closing prevents water hammer, at least in water systems. In air systems it might just prevent a blast of back pressure blowing all the dust out of your vents onto your carpet.
I do keep an OpenRouter account topped up for things that Ollama doesn’t have. 99% of my usage there is embeddings, the other 1% is wanting to test some new model Ollama doesn’t have.
reply