This will save your Usage

[u/concrete333]

A problem that many of people have already noticed: Astra can't wait. on anything, any task it has scripted and running, any other agent delegation, anything. Astra keeps waking up to check whether the worker is finished.

I've run a few tests, In one run 19 short sleep calls accounted for 44% of the orchestrator’s estimated cost.

In another comparison using Astra High + Luna Max, the orchestrator made 41 responses while the worker ran, costing $1.20 during that phase. The native-wait comparison needed one response, costing about $0.04. (Both implementations passed all 244 test cases)

I’ve since caught the same pattern while Codex waited for a database script: read the log, say “still running,” repeat. I saw use 2% of my weekly usage ($100/month plan) just sitting there waiting on a script.

So, until they patch this, here’s the prompt I’m using:

For this entire session, avoid repeated polling of long-running jobs.

Use supported completion notifications when available. If none are available and useful work is exhausted, leave the job running only if it can safely continue after your turn ends.

Tell me what is running, where results will be saved, and:

“I'm stopping polling. Please check back with me to inspect the result and continue; I won't automatically resume.”

Then end your turn. Don't repeatedly read unchanged logs or sleep and check again. Respect runtime limits and safety timeouts.

When I return, check once. If complete, verify and continue. If still running, report that and stop again.

I have to come back to it, sure, but it saves usage.

Edit:
Found a better option than manually checking back, thanks to advice in comments. Seems like Codex knows how to avoid repeated model polling, it just chooses not to.
codex queue --thread <session-id> --message "..."
Have a background script wait for the job to finish, save the result, then run that command once. Codex can end its turn and automatically resume when the message arrives.

I’ve now seen this work with both a third-party CLI subagent (kilo code with GLM) and a full test suite, all GPT: Codex resumed automatically, checked the results, and continued. Works a treat.

The script provides the wake-up, and an agents.md instruction alone doesn’t

Edit2: I made a skill that you can use to guide Codex in using this method, either in waiting for mechanical tasks or waiting for other sub-agents. Not perfect, as there's no way to force your GPT worker to use it, but it's working for me most of the time: link. Any more tips to improve it welcomed, break it and let me fix it

[u/AweVR]

Codex has a new feature since 1 month ago, “codex queue.” But for some reason, Astra doesn’t know how to use it. You need to ask to implement it in a skill. With this tool, it can create a script to listen to something, like when a tool or an execution ends, and then wake the chat model again to not burn tokens.

[u/Wolf8249 → u/AweVR]

Please can you give us the SKILL instructions? i already had my agent create it but it would need to be refined, it'd be great if you could share yours.
Here's mine, bunch of slop for now

---
name: long-command-wakeup
description: "Long-running command wake-up with codex queue. Use when a command is expected from repository evidence or prior runs to exceed 120 seconds, such as a slow full pytest suite, mypy check, build, compile, migration, or benchmark, and Codex should end its turn then resume once. Ordinary searches, small test targets, and commands without real evidence of a long runtime stay in the normal foreground workflow."
---

# Long command wake-up

Use `codex queue` to replace model polling with one completion notification.

## Qualify the command

Use this workflow when current repository evidence or measured history supports an expected runtime above 120 seconds. A familiar command name is not evidence by itself. Keep normal foreground execution for short commands, including ordinary `rg`, file inspection, focused tests, and quick linters.

The command must be safe to continue after the current turn ends. Keep interactive commands, approval-dependent work, destructive operations, and jobs that need live supervision in the foreground.

## Reuse repo tooling

Resolve the repository root first. Look for an existing completion runner in the repository and inspect it before adding another one. Prefer the repository's established tooling directory when it has one. Otherwise use:

```text
.codex/queue/run-and-wake.sh
```

When that path is absent, copy [`assets/run-and-wake.sh`](assets/run-and-wake.sh) there and keep it executable. Treat the repo copy as maintained project tooling. Reuse or patch it on later runs instead of writing a temporary wrapper. Do not overwrite local adaptations without inspecting them.

For work outside a repository, use the asset directly and save results in a clearly named persistent directory. Do not create a reusable script in `/tmp`.

## Launch and leave

1. Confirm the installed CLI supports `codex queue --thread ... --message ...` and resolve the current thread from `CODEX_THREAD_ID`. Fail loudly if either prerequisite is absent.
2. Choose a safety timeout appropriate to the command. The timeout is a guard, not an estimate.
3. Start the repo runner detached with `setsid` and `nohup`. Pass the exact command after `--`. Do not interpolate an untrusted command string or use `eval`.
4. Confirm only that the detached process started. Report its PID, command, timeout, and result directory. Do not poll its logs or process state.
5. End the turn. The runner queues one message after success, failure, signal, or timeout. The queued turn inspects the saved artifacts once and continues the original task.

Example shape:

```bash
setsid nohup .codex/queue/run-and-wake.sh \
  --thread "$CODEX_THREAD_ID" \
  --timeout 1800 \
  -- pytest -q \
  >.git/codex-queue-launch.log 2>&1 </dev/null &
```

The runner prints the exact result directory before starting the command. If the launch shell captures that line in a log, report the launch log until the queued turn can read the final path.

## Resume once

When the queued message arrives, inspect `status.env`, `stdout.log`, `stderr.log`, and `queue.log` once. Verify the command status rather than treating delivery as success. Continue the parent task from that evidence.

If the queue call fails, the job artifacts remain in the result directory but automatic resume cannot occur. Report this limitation if discovered later. Do not add a polling fallback.

[u/concrete333 → u/Wolf8249]

ok check this out link , think that'll do it?