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.
> 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 _think_ they fixed the file sync issue; I haven’t had desynced files in a few weeks.
Still a bad bug that lingered entirely too long.
> when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
If you’re using Pi (I am), that’s partially because Pi doesn’t have “real” ACP and violates the spec as a result. File read/writes are supposed to happen via ACP RPC calls from the agent to the client, so Zed would see them and know to refresh. Pi wasn’t built for ACP so it embeds its own read/write tools and ignores the ACP ones, and Zed never gets the “refresh this file” signal it expects.
I think it’s sort of self-defined. If a model is able to use bash well enough to not need specific tools.
The research seems to agree with you, though. The paper calls out that for “bash capable” models, adding tools to do things bash can already do doesn’t improve performance.
Vaguely the same result as RAG. Unless you’re in specific domains, you won’t beat handing the agent a shell and grep.
> Vaguely the same result as RAG. Unless you’re in specific domains, you won’t beat handing the agent a shell and grep.
This has been my conclusion as well, and I'm doing my best to try and back this up quantitatively. In a perfect world, I could smite all of the internal MCP servers in my Corp environment and replace them with REST/GraphQL. No one using any of these servers is hitting them with models that would perform worse orchestrating with bash- and some of these folks are running harnesses with awful MCP clients.
I am still wondering about the effectiveness of using grep/awk (and ad-hoc python scripts) in code bases, as opposed to more sophisticated LSP and the like?
The only part that would really be novel is the liability.
I would be shocked if you could publish an iOS app without Apple being able to tell the government who you are. Less because Apple cares and more because Apple requires you to pay, which is very hard to do anonymously for something like this (I’d bet the options they offer are effectively “credit card only”).
It also relies on lifelong tenure, which would be a huge cultural shift for both employers and employees. Employees are often used to quitting rather than having to fix business issues (easier to quit than make the business fix X), and businesses are largely used to mistreating their employees because they can be replaced.
We’re culturally very far from even being able to attempt that.
Naively, I think some optimizations would require access to the whole codebase and that would make people nervous (plus incur more cost).
Eg absurd idea, but you could write something that minifies a codebase (by token, rather than byte) and then translates edits back into the expanded code. Probably an insane use of fuse lol. Partially minifying on each tool call sounds like a huge pain with a lot of state to track.
There’s also a lot of common situations where humans prefer solutions that take more tokens because it’s easier for us to read (eg for loop vs map vs list comprehension), which may have some gains.
I strongly suspect there is some form of token compression that works, but I don’t think it will be as simple as “pipe arbitrary text with no context into this tool”.
Jetbrains feels like a place this might come from. “Take this code, parse it to an AST, find the fewest token representation of it” feels like something they’d do, or maybe Astral (specifically in Python land, type checkers feel sort of adjacent as well).
I fully agree. Some of these tautologies, RAGs or RAG adjacent ideas feel like there is real potential. I know in my own testing adding a knowledge graph provided cost saving benefits.
Ultimately, the problem is people aren't actually benchmarking any of these ideas or if they are its via an extremely misleading methodology. For example, headroom violates cache frequently, nullifying any potential savings it could have; but does their benchmarks show that? Nope. [1]
As an aside, I wonder how many days are we away from Codex or Claude taking all the "read" tool calls and re-assembling a full map of your codebase and then offering it as a feature.
I think people don’t do genuine benchmarks because the market forces them to pretend their solution works for anything you can throw AI at. Companies whose valuation is based on them being the RAG/compression/routing/etc company. They can’t admit it only works well in a specific domain because then they’re immediately $300M in the hole.
I have more faith in companies with a more targeted approach. Eg gzip does fine, but video codecs beat compressing raw video by a ton.
> As an aside, I wonder how many days are we away from Codex or Claude
That sounds like SourceGraph but twice as expensive, although it does have “AI” so probably lol
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.
[1] https://github.com/SethCurry/abyss
reply