One GPU. Many Codex sessions. Less manual juggling.
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.
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.
About Codex GPU Queue on Product Hunt
“One GPU. Many Codex sessions. Less manual juggling.”
Codex GPU Queue launched on Product Hunt on September 18th, 2026 and earned 68 upvotes and 1 comments, placing #30 on the daily leaderboard. 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.
On the analytics side, Codex GPU Queue competes within Productivity, Developer Tools, Artificial Intelligence, GitHub and OpenAI Day — topics that collectively have 1.7M followers on Product Hunt. The dashboard above tracks how Codex GPU Queue performed against the three products that launched closest to it on the same day.
Who hunted Codex GPU Queue?
Codex GPU Queue was hunted by Jack Huang. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
For a complete overview of Codex GPU Queue including community comment highlights and product details, visit the product overview.
Jack Huang
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.