Your agent can run your Bambu printer now. Blender to the build plate, over your LAN, no cloud needed. Open source, obviously :)
Update to my first finding on Sept 3rd, xitter.cf/_DMontgomery40/status/…
Even grok thinks astra's aeon is cooler grok bot
aeon-core instructions: hastebin.com/share/ayaqigava…
gpt-5.6 summary:
Aeon looks less like a new foundation model and more like a persistent agent/orchestration layer sitting above Codex.
Its job is basically to act like an ongoing chief of staff for the user. It maintains context across requests, tracks goals and unfinished work, remembers what is currently in progress, survives interruptions, manages automations and event-triggered tasks, and keeps following work until it is completed, cancelled, or superseded.
The really interesting part is that Aeon is explicitly told NOT to do substantive work directly in the parent session. For normal one-off work, it creates or resumes cloud threads and delegates the task there. The parent Aeon stays responsible for coordinating the work, tracking the thread, reading the result, handling follow-ups, and keeping the user informed.
So architecturally it looks something like:
Aeon persistent coordinator
↓
cloud thread / child agent
↓
actual inference model
Which makes the config I found make a lot more sense:
default_model_id: nathree-aeon
child_thread_model_id: gpt-5.6-sol
In other words, nathree-aeon appears to be the persistent agent/profile you interact with, while 5.6 Sol is the model currently doing delegated work underneath it.
And yes, that same allowed-model payload also contains the literal ID gpt-6-astra.
The instructions go significantly beyond "longer memory." Aeon is designed around durable work: ongoing sessions, subthreads, scheduled tasks, event triggers, automatic continuation, authorization boundaries, task ownership, and resuming things without making the user manually coordinate every step.




