Hacker Newsnew | past | comments | ask | show | jobs | submit | agentdev001's commentslogin

Almost as if distributed safe compute for autonomous workloads suddenly came into focus for many orgs!

"We noticed builders often wished their Claude Code or Codex setup could run in the cloud because locally their agent idea just “worked” with those harnesses.

But the moment you build your own agent, you’re on your own. It’s tricky wiring up the right primitives just well enough to match that “it just worked” feeling."

Im sorry, but who is saying this? If you just throw this statement into agent of your choice- and ask what native integrations exist to cover this use: OAI and Anthropic both have a handful of options here. Claude Agent SDK, Claude managed agents, Codex exec, Codex sdk, Codex app server, openai agents sdk, openai agents api.


Beyond that though, I'm certainly interested in the performance side of things. "Keep an eye out for a follow-up paper from our researchers regarding these benchmarks." Yes plz.

Yes. Or- use them at work, where management is taking a... hands off approach to ~integrating ai~ into the workplace.

Something like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.

"without first having to solve the problem of effectively sandboxing Bash"

Hopefully this is easier as time goes on. Of course- also policy on the egress


Sounds ripe for vibe... sewing

An example of this, Moonshot (kimi) open sourced this: https://kvcache-ai.github.io/AgentENV/latest/getting-started...

"Is giving the agent a temporary scratchbox really that valuable?"

Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.


You must construct additional pylons

As far as I can tell, the paper says "bash capable", without ever describing what that means. How would one know whether a given model is "bash capable" or not?

I would have to imagine, that Luna would very much fall into the camp of "bash capable". At which point- it seems to me that adding any tools beyond just Bash requires some rigorous testing and verification that value is being added.


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?

I think it just means “is there some parser program that consumes the LLM token stream and spawns shell processes with the detected command strings”.

Im not sure how this could make sense, considering the content of the paper.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: