Sharing my Codex experience (token usage) · ARABIC AI AGENTS ACADEMY

Sharing my Codex experience (token usage)

Salam everyone!

Some days ago, I posted here asking whether I was using Codex efficiently, especially my orchestrator loop: Implement → Test → Review → Fix → Repeat until approved.

The feedback was really useful, so I decided to stop relying on impressions and start measuring what was actually happening. I built a local tracking system and collected detailed data from 10–20 August. I’m attaching the full report for anyone interested in examining it.

The headline number surprised me:

Codex recorded 1.406 billion input + output tokens across 206 agent turns and 20,795 interactions.

The summed agent workload was 92.8 hours, although root agents and subagents sometimes worked simultaneously, so this is not 92.8 hours of real elapsed time.

Also, an important clarification: this is telemetry, not an API invoice. It should not be interpreted as the amount I was billed or as a direct representation of my Codex plan quota.

What surprised me most :

→ 99.64% of the total was input. Only 0.36% was output : So my main problem is apparently not that Codex writes long answers. The much larger factor is the context repeatedly sent through the workflow.

→ 97.79% of the input was cached input.

→ Just four days accounted for 82.33% of all recorded tokens.

→ Subagents accounted for 313.3 million tokens, or 22.29% of the total.

→ In the activity classification, analysis and planning represented 43.31%, while implementation represented only 11.56%.

My current interpretation: I don’t think the orchestrator pattern itself is necessarily wrong. The larger issue seems to be how much context is repeatedly carried through long sessions and autonomous loops: conversation history, instructions, repository information, command output, test results, logs, and separate context for each subagent. My workflow may therefore be logically efficient while still being context-inefficient.

I gave chatGPT the report and the recommendations are:

→ Pass short, structured handoffs instead of giving every agent the complete history.

→ Add stricter iteration limits and clearer stopping conditions to the review/fix loop.

→ Reserve xhigh or ultra reasoning for genuinely difficult decisions.

→ Use lower reasoning effort for routine implementation, testing, formatting, and logging work.

→ Separate planning, implementation, testing, and review into smaller bounded tasks.

→ Reduce oversized command output and unnecessary logging.

→ Compare long-running sessions against deliberately starting fresh sessions.

→ Measure tokens per completed bug or feature, first-pass success rate, retries, and time until acceptance—not just turn count or elapsed time.

I’m not presenting these conclusions as final. The report gives me much better visibility, but I still need to test which changes actually improve the workflow.

I’d really appreciate your interpretation:

- Is this amount of cached input normal for long Codex sessions, or is it a clear sign that my context has become too large?

- Would you keep this orchestrator and tighten its boundaries, or redesign it?

- When do you preserve an existing session for its context and cache, and when do you deliberately start fresh?

- How do you decide which tasks deserve xhigh or ultra reasoning?

- What other metrics would you add to the next report?

Thanks again to everyone who replied to my original post. Your feedback pushed me to stop guessing and collect actual data.

I’m especially interested in hearing from people running long autonomous tasks, subagents, or similar implement → test → review workflows.

PS: find the PDF report attached.

10 comments

Sharing my Codex experience (token usage)