My most-used local Codex tool. I use it every day to let multiple sessions share one Windows GPU. Jobs queue in the background, run when resources are available, and return results to each session, so I don't have to coordinate them manually.

How did Astra change the scope or ambition of what you built?

Astra helped turn the GPU queue I use every day into an open-source tool other Windows AI builders can try. It lets multiple Codex sessions share one GPU: jobs queue, start when eligible, and return results to their originating sessions. The original scheduler was built earlier with GPT-5.6 Sol. For this release, GPT-6 Pro in ChatGPT helped me plan and review the work; Astra in Codex added a read-only waiting-reason observer, prepared a portable source release, and validated it with 51 tests in a clean dependency environment on my Windows machine. It also coordinated two independent Codex sessions running synthetic CUDA jobs and turned real status snapshots into a labeled demo replay. I set goals and approved changes and publication rather than writing the code. The ambition expanded from private infrastructure to a public tool with understandable waiting states, a tested setup path and a documented demo, through a few rounds of natural-language collaboration.

This is the local Codex tool I use most. In my own workflow, I use it far more often than the official plugins.

I often have several Codex sessions working at once, but only one GPU. I want to give them tasks, not keep deciding which session gets the GPU next.

That is why I use this queue every day. It runs in the background, starts submitted GPU jobs when resources and scheduling rules allow, and returns results to the originating session. The core was part of my daily setup before this challenge; this release makes a small, documented version available for other Windows AI builders to try.

The focused Astra addition is a read-only CLI that answers a question I want to inspect before intervening: why is a selected job waiting? It reports confirmed blockers from the current snapshot, keeps uncertain reasons undetermined, and omits commands, private paths and raw job identities. A snapshot observation is not a recorded scheduler decision or an ETA.

The broker core predates this challenge and was developed with assistance from earlier models. For this challenge preparation, I coordinated work across ChatGPT (GPT-6 PRO) and Codex/Astra. GPT-6 PRO helped shape the initial brief and collaborated on the preparation; this Codex task carried out the scoped implementation, verification, demo preparation and publication work. The Astra pass added the observer and regression cases, corrected the minimal-package doctor checks, and verified the candidate. Earlier core work is not attributed to Astra.

All 51 CPU/synthetic tests passed in a new dependency environment on the same Windows machine. In a separate real demonstration, two independent Codex sessions submitted synthetic CUDA jobs and received their results. B queued while A ran, then the existing broker started B automatically. Both succeeded.

The 40-second video replays actual redacted snapshots. Waiting is compressed; original job timestamps are unchanged. It is synthetic CUDA computation, not model inference or a native screen recording. The video alone does not prove the two sessions' independence.

This is a source candidate for trusted local workflows on one Windows machine and one NVIDIA GPU. Use wait/follow; the optional Node/SDK continuation controller is not included. New-machine and built-wheel installation tests are not claimed, and there is no runtime model API.

How did Astra change the scope or ambition of what you built?

Codex GPU Queue

One GPU. Many Codex sessions. Less manual juggling.

One GPU. Many Codex sessions. Less manual juggling.