gpt 6 sol already made a lot of progress with caches
i have a feeling unreal agent might have decided to release now rather than getting sherlocked
i just think its very risky right now to spend too much time building harnesses or anything on top of codex or claude simply because frontier labs will just absorb whatever works
I assume the bigger problem is the cache expiring while you wait for the tool call to complete. A bunch of hosted providers only keep the cache alive for ~5 minutes - if you sit there waiting for a 5 minute tool call, you get to pay to reload the entire context into cache
For some reason they're comparing their harness running on Astra xhigh to Codex with Astra max?
---
Also worth noting that OpenAI just added support for async tool calling to their harness, which isn't 1:1 with this approach, but is slowly ramping up in being able to provide something similar.
My harness has used a slightly fancier version of the approach that Unreal is using since ~Feb, and... it definitely works excellently, but it's also assuredly smoother with Astra and other recent models that are more aware of async tool calling.
Seems to do the job and reduce usage; I just ran Astra for ~5 hours (using a goal) and it used the last 30% of my usage. And now they released GPT-6 Sol and Luna (which is basically 5.6 Sol and Luna, but a bit better and also 50% cheaper) ;_;
Perfect, I will incorporate this as default as well as the commit from the other guy into my own codex fork https://github.com/AmazingTurtle/codex btw. I'm rebasing on 0.156.0 right now
the headline chart was lazy on our part, thanks for the flag and I’ll update it.
each individual benchmark that is combined into agentic coding index was compared on xhigh between ua / codex / pi, and headline improvement was calculated on xhigh, but then agentic coding index pareto chart by default includex codex max, hense the confusion.
Honestly the fact that we're still modeling agent harnesses like chat and strapping them into shell sessions instead of building async actor systems with sandboxed OS functionality access actors is bananas to me. So much easy wins can be had just by building on right abstractions... Hopefully will get enough time to play with this idea soon on my own.
I'm actually taking the time to hash out the details to do this as a side experiment project, but basically what I read this project as showing is that if you leverage asynchrony you can let agents be more efficient - and you get this "for free" if you model your "agents" as actors that interact with the system through message passing. Then all the system operations become messages to different actors, need to read a file => message the fs actor => get reply from FS actor as a message when it's done. You'd probably need some out of mailbox ways to share blob resources and sockets for realtime (audio), but for the most part simple message passing should handle most of what LLM agents do.
Actors can have identities and roles for RBAC, etc. you - cross agent communication is the same as sending any other message to a actors.
Not to mention that actors can be on your device, another device, etc. whatever the router can resolve - it's transparent to the agents.
I’d think the approach in this repo gets close to that, no? I also think LLM harnesses should just support typical async i/o.
Let a model get notifications when something it has accessed/ subscribed to changes, a tool produces output or it gets some other kind of message (for example by another AI or flesh agent). Wait until the next turn or wake it up. It can still decide to do nothing and wait.
The time to think your hypothesis is better than our current solution of borrowing from familiar paradigms with familiar limitations is when your idea is demonstrated to be better.
That's the reason I'm excited about the orchestrator because it would let me build my ideal UX on top.
If you move away from the idea that agents are chat streams and treat them as processes/actors then you can start letting agents represent themselves/build their own interfaces.
And if you build enough introspection into the protocol because everything is message based you can have other agents build interfaces for them.
So like either standard GUI, or a voice assistant talking to you and delegating to agents, etc.
It's not an idea it's a way of thinking about agent systems - basically an agent OS.
I think you nailed it. I have my own agent harness that's designed with inspiration from erlang/elixir. It seems to be a natural fit for indeterministic output and failures.
https://tau-agent.dev/ in my setup. Many sessions each multiagent, in different sandboxes, sending messages. Also nothing in the main article that Tau wouldn't have. I just don't have stamina for more "marketing". Async tools ... sooo basic. :D
I had to scroll to the bottom to realize that this had absolutely nothing to do with Unreal Engine or Epic. There's no reason to think that Epic wouldn't have an "Unreal Labs" creating harnesses to help them with software engineering.
This plainly seems like a trademark issue in progress considering it's in the same exact domain and considering how many others were confused the way I probably was.
I liked the 3D effects on the homepage of unreal labs https://unreallabs.ai/ - so I was sure it's related to 3D engine makers, and of course great idea to have an agent for that too.
Maybe if UnrealLabs were a banana company. But they are a software company. The trademark they have on "Unreal" is for computer software and lists a bunch of domains related to the software development of video games/3d models.
Codex offers an OAuth endpoint, which can be used in any harness of your choice. Note this is separate from their app-server setup; in this setup, you talk directly to the API.
I think this space is very untapped. Models are interesting, but I am absolutely obsessed with some things I've been researching/working on for the past few years:
Fractal tool discovery: tool taxonomy where an agent can "drill deeper" to find what specific tool it's looking for. Helps if/when polluting context with a zillion (mostly unnecessary) tools.
Leveraging splay trees: this is my favorite data structure and I think relatively unused in the context of agents/harnesses. A lot of times, recently-used workflows/tool-chains will be used again, so having those at the top of the search hierarchy is an awesome optimization.
Virtual containerized notebooks: models working in sandboxed (WASI) Python notebooks is incredible. Even local models (if given enough time) will usually converge on a good solution. Being able to mount tools/resources/fs is again, imo quite untapped. Some problems here are running native things (thing numpy/pandas) in containers is a nightmare (or impossible).
Anyway, happy to see other folks seriously doing stuff in this space. If anyone wants to collaborate on anything don't hesitate to reach out :) I'm also actively looking for a job or some contract gigs.
It's kind of self-expanding/looping; fractal is just a cute name I like, but it's technically a directed cyclic graph (since you always have/want cycles).
I've always referred to it in UX terms. "Progressive Disclosure" -- It pulls more context as needed.
In this way, I tend to think of the context environment on an agent is the "agent nav" -- it presents context, allows progressive disclosure, and if poorly designed, makes the agent flounder as a poorly designed UI/UX does.
Fractal tool discovery is a fascinating idea! Have you worked on implimenting this into any agent harnesses already to any success? My first impression is allowing the agent to fork itself, not unlike launching a subagent, then returning it's response back to the main agent.
I've also explored s/Fractal tool discovery/Skill tree approaches, seems to work pretty well when you stick the equivalent of XREFs in the frontmatter.
i have found agents to be excellent at using CLIs, which are fractal-like. i built this reddit ads api cli and my agent immediately starting introspecting it in a "drill deeper" manner:
> Helps if/when polluting context with a zillion (mostly unnecessary) tools.
Ugh, I can't help but respond to this one point. The fact that this is even an issue in the current year just tells us how screwed the software field is in a lot of ways. I don't mean that in existential terms, but of how divided we've become in terms of what's happened to human reasoning. On the one hand, you have people who apply deep thinking to develop the sort of approaches you described, and there's the exponentially growing segment of not-even-programmers who seem to never ask themselves whether any of their ideas have any sort of consequences.
Take MCPs for instance. Sure, I guess it can sometimes make sense to have a stateful API that is optimized for agents. Yet, more often than not, these MCPs frontload a ton of context where it's not needed, and solve problems where none existed. Merely sticking an API (MCP) in front of an API (CLI, REST, GraphQL) without a benefit that can be explained in a single sentence is lunacy and demonstrates a real lack of complex thinking.
> tells us how screwed the software field is in a lot of ways
But, you just very clearly described why human software engineers are in higher demand than ever before.
It's always been "screwed" in the sense that everyone else sucks at wielding the power.
What we're actually witnessing is a watershed moment where a lot of technologically illiterate people are getting left behind. Those of us on the literate side are left to fight amongst ourselves and the powers that be for control over the future. We have actually been doing an alright job all things considered (else this conversation wouldn't be happening). Politicians are aging out and we're the adults in the room now.
Your point is valid for individual developers or small teams of technical folks.
However, MCPs are a godsend to anyone trying to manage access to systems (especially SaaS systems) in a large organization that includes a ton of non-technical employees. We use at least a couple of SaaS products where RBAC is severely limited in what it can govern or where API keys do not have any kind of governance so handing one out is basically handing out read/write on the entire system. Being able to configure an MCP to only have read endpoints enabled it a very useful piece of duct tape. Obviously it would be great if the underlying API was just designed with proper governance but that's out of the user's control.
all other tools, mcps, apis, whatever are encapsulated by the one interface. new tools don't bloat the agent's context, and it can write its own code to perform more advanced and batch operations against the available tools (executed within a sandbox).
If the frontier labs (well, I guess just Anthropic) would go full OAuth support even on a subscription we would see, an even bigger, explosion in harness improvements. I maintain that there is a ton of low-hanging fruit and new ideas/concepts that should be tried but the costs are holding people back (using API pricing only).
It's both expensive to test alternative harnesses and it's expensive to develop them (if using API pricing).
In my projects i use unreal and me and my team have tested out multiple things. We have settled on no MCP complications whatsoever other than simply exposing the python scripting from the editor + a export step that can write the blueprints and asset data into plaintext so that the bot can grep them. This has given by far the strongest results, and we now have no issues having the agents edit game code and do operations.
We found this massively outperforms any kind of agent like this and the official unreal MCP systems. Its similar to the Blender MCP which also just exposes scripting + very minimal api to claude code/others.
When did we just give up on the challenge of giving something a unique name? I see products launch everyday on HN now that just take a well known brand and use it as their own. I thought this would be a feature for Unreal engine.
Async, as I understand it, means that the agent never has to actively wait for things to complete, so it can do work while it waits and can receives the result at some later point which it can then react to. I don’t know whether Eve has that feature, it would be cool. Should not meaningfully influence its ability to be deployed serverlessly.
109 comments
[ 3.5 ms ] story [ 49.7 ms ] threadIt says that it removes tokens wasted while a model is waiting on synchronous tool calls. What tokens exactly is Pi using when waiting?
gpt 6 sol already made a lot of progress with caches
i have a feeling unreal agent might have decided to release now rather than getting sherlocked
i just think its very risky right now to spend too much time building harnesses or anything on top of codex or claude simply because frontier labs will just absorb whatever works
For some reason they're comparing their harness running on Astra xhigh to Codex with Astra max?
---
Also worth noting that OpenAI just added support for async tool calling to their harness, which isn't 1:1 with this approach, but is slowly ramping up in being able to provide something similar.
My harness has used a slightly fancier version of the approach that Unreal is using since ~Feb, and... it definitely works excellently, but it's also assuredly smoother with Astra and other recent models that are more aware of async tool calling.
[features.multi_agent_v2] enabled = true wait_agent_enabled = true min_wait_timeout_ms = 10000 # 10s default_wait_timeout_ms = 300000 # 5m max_wait_timeout_ms = 3600000 # 1h
Seems to do the job and reduce usage; I just ran Astra for ~5 hours (using a goal) and it used the last 30% of my usage. And now they released GPT-6 Sol and Luna (which is basically 5.6 Sol and Luna, but a bit better and also 50% cheaper) ;_;
each individual benchmark that is combined into agentic coding index was compared on xhigh between ua / codex / pi, and headline improvement was calculated on xhigh, but then agentic coding index pareto chart by default includex codex max, hense the confusion.
Actors can have identities and roles for RBAC, etc. you - cross agent communication is the same as sending any other message to a actors.
Not to mention that actors can be on your device, another device, etc. whatever the router can resolve - it's transparent to the agents.
Let a model get notifications when something it has accessed/ subscribed to changes, a tool produces output or it gets some other kind of message (for example by another AI or flesh agent). Wait until the next turn or wake it up. It can still decide to do nothing and wait.
If you move away from the idea that agents are chat streams and treat them as processes/actors then you can start letting agents represent themselves/build their own interfaces.
And if you build enough introspection into the protocol because everything is message based you can have other agents build interfaces for them.
So like either standard GUI, or a voice assistant talking to you and delegating to agents, etc.
It's not an idea it's a way of thinking about agent systems - basically an agent OS.
This plainly seems like a trademark issue in progress considering it's in the same exact domain and considering how many others were confused the way I probably was.
People, I'm begging you, please talk to a lawyer before launching.
Fractal tool discovery: tool taxonomy where an agent can "drill deeper" to find what specific tool it's looking for. Helps if/when polluting context with a zillion (mostly unnecessary) tools.
Leveraging splay trees: this is my favorite data structure and I think relatively unused in the context of agents/harnesses. A lot of times, recently-used workflows/tool-chains will be used again, so having those at the top of the search hierarchy is an awesome optimization.
Virtual containerized notebooks: models working in sandboxed (WASI) Python notebooks is incredible. Even local models (if given enough time) will usually converge on a good solution. Being able to mount tools/resources/fs is again, imo quite untapped. Some problems here are running native things (thing numpy/pandas) in containers is a nightmare (or impossible).
Anyway, happy to see other folks seriously doing stuff in this space. If anyone wants to collaborate on anything don't hesitate to reach out :) I'm also actively looking for a job or some contract gigs.
Fun times ahead.
In this way, I tend to think of the context environment on an agent is the "agent nav" -- it presents context, allows progressive disclosure, and if poorly designed, makes the agent flounder as a poorly designed UI/UX does.
https://github.com/genei-Ltd/reddit-ads-cli
Ugh, I can't help but respond to this one point. The fact that this is even an issue in the current year just tells us how screwed the software field is in a lot of ways. I don't mean that in existential terms, but of how divided we've become in terms of what's happened to human reasoning. On the one hand, you have people who apply deep thinking to develop the sort of approaches you described, and there's the exponentially growing segment of not-even-programmers who seem to never ask themselves whether any of their ideas have any sort of consequences.
Take MCPs for instance. Sure, I guess it can sometimes make sense to have a stateful API that is optimized for agents. Yet, more often than not, these MCPs frontload a ton of context where it's not needed, and solve problems where none existed. Merely sticking an API (MCP) in front of an API (CLI, REST, GraphQL) without a benefit that can be explained in a single sentence is lunacy and demonstrates a real lack of complex thinking.
But, you just very clearly described why human software engineers are in higher demand than ever before.
It's always been "screwed" in the sense that everyone else sucks at wielding the power.
What we're actually witnessing is a watershed moment where a lot of technologically illiterate people are getting left behind. Those of us on the literate side are left to fight amongst ourselves and the powers that be for control over the future. We have actually been doing an alright job all things considered (else this conversation wouldn't be happening). Politicians are aging out and we're the adults in the room now.
However, MCPs are a godsend to anyone trying to manage access to systems (especially SaaS systems) in a large organization that includes a ton of non-technical employees. We use at least a couple of SaaS products where RBAC is severely limited in what it can govern or where API keys do not have any kind of governance so handing one out is basically handing out read/write on the entire system. Being able to configure an MCP to only have read endpoints enabled it a very useful piece of duct tape. Obviously it would be great if the underlying API was just designed with proper governance but that's out of the user's control.
mcp with 2 tools: execute(code) and search(query)
all other tools, mcps, apis, whatever are encapsulated by the one interface. new tools don't bloat the agent's context, and it can write its own code to perform more advanced and batch operations against the available tools (executed within a sandbox).
executor is a great implementation of this - https://executor.sh
opencode v2 also provides its own native implementation
i think the language primitives map well to the natural desire to use these tools across networks and in concurrent workloads.
another Go harness i keep up to date with is: https://github.com/boldsoftware/shelley (exe.dev team)
It's both expensive to test alternative harnesses and it's expensive to develop them (if using API pricing).
We found this massively outperforms any kind of agent like this and the official unreal MCP systems. Its similar to the Blender MCP which also just exposes scripting + very minimal api to claude code/others.
Would be interesting to compare to a harness optimizing for cost reduction too.