What Codex's Weekend /fast Pattern Means for Agent Mode Selection¶

Choose by waiting cost, not weekday

Work state	Mode-selection rule
You will inspect the result and immediately change the next instruction	Consider Fast mode because waiting reduces useful iterations
The agent will run autonomously or overnight	Start with Standard mode because nobody is waiting
Audit, architecture, or incident analysis	Set the model and reasoning level first, then choose speed separately

While waiting for a pull-request fix before deciding the next instruction, choose /fast when the wait blocks that decision, not because of the weekday. Use Fast mode as the starting point for short interactive loops and Standard mode for long autonomous or overnight work. At the team level, record completion time, reruns, and credit use by task type instead of tracking the share of tasks using Fast mode.

The original post described a usage rhythm¶

OpenAI's Codex lead, Thibault “Tibo” Sottiaux, posted on August 1, 2026 UTC that users use /fast less during the weekend.¹² The short observation joked that even the model relaxes on weekends, but it did not publish the observation window, user count, daily values, or included plans.

The post directly supports only that OpenAI observed a weekday-weekend difference in the pattern. Several explanations remain possible: workday iteration may be more interactive, weekend work may be longer-running, or total use may simply fall. The post does not distinguish among them.

Fast mode trades credits for speed¶

OpenAI's documentation defines Fast mode as making supported models run 1.5 times faster while consuming credits at a higher rate than Standard mode.³ In the CLI, /fast on, /fast off, and /fast status change or inspect the setting.

As of August 3, 2026, ChatGPT-signed-in use of GPT-5.6 or GPT-5.5 consumes credits at 2.5 times the Standard rate, while GPT-5.4 uses 2 times the Standard rate.³ When Codex uses an API key, API token pricing applies instead and these ChatGPT credit multipliers do not.

Fast mode is not the same as selecting a smaller model or lowering reasoning effort. Model, reasoning, and speed are separate choices, so the /fast setting alone does not mean that a task is lightweight or unsuitable for difficult work.

Credit use also depends on more than the speed setting. OpenAI says usage varies with task size and complexity, model, execution location, codebase size, and long-running sessions.⁴ A small fix and a broad repository investigation can therefore have very different costs even when both use Fast mode.

Assign Fast mode where waiting blocks the next decision¶

The value of spending extra credits on speed depends on what the saved time unlocks. Classifying work by its feedback pattern is more useful than classifying it only by task name.

Example	Benefit from Fast mode	Operating choice
UI tuning, failed-test fixes, bounded research	The result changes the next instruction	Candidate for Fast mode
Broad code exploration, overnight tests, scheduled analysis	No person waits during execution	Start with Standard mode
Production incident triage	Delay can be costly	Candidate after tightly bounding scope
Security audit or material architecture review	Coverage may matter more than latency	Set model, reasoning, and review gates first

Consider a loop that fixes one failing test, reruns it, and uses the result to choose the next hypothesis. Lower latency can increase the number of useful human decisions in that loop. By contrast, finishing an overnight dependency analysis slightly earlier does not advance the next decision if review still begins in the morning.

Do not use weekends as a capacity forecast¶

User-visible completion time combines model processing, tool execution, network delay, repository exploration, and test runtime. Even if aggregate /fast use is lower on weekends, an individual task is not guaranteed to finish faster.

OpenAI's public documentation does not promise weekend capacity, weekday-specific priority, or lower weekend pricing. There is therefore no evidence for an operating rule that shifts heavy tasks to weekends to obtain better service. A weekday can inform staffing, but it cannot replace a product performance commitment.

Measure outcomes by task type¶

To govern Fast mode, record whether extra consumption actually reduced decision-blocking wait time rather than counting how often the setting was enabled. Hold the model, reasoning level, repository, task boundary, tool configuration, starting worktree, and thread state constant when comparing runs.

The developer classifies the work as interactive, unattended, or urgent.
The developer pairs tasks of comparable difficulty and fixes the model, reasoning level, and completion condition.
The operator alternates Fast-first and Standard-first order in comparable time windows and repeats each condition.
Codex starts each task from the same commit, a new thread, and the same tool configuration.
The operator records the median and range of completion times, reruns, credit use, and defects found in review.
The team standardizes Fast mode only for task types where saved time advances the next decision.

Credit balance is available in the Usage panel under Codex Settings, and some plans also show thread-level use.⁴⁵ This is a local operating comparison for one team, not a general Codex performance benchmark.

The weekend observation cannot establish performance or congestion¶

The original post is a product leader's observation, not a published analysis. Without the population and aggregation method, the size, cause, and persistence of the weekday-weekend difference cannot be evaluated.

This mode-selection framework is SmartScope's operational judgment derived from the documented product behavior and the value of waiting time. It is not an OpenAI scheduling recommendation. Supported models, credit rates, and administrator controls may change, so check the Speed documentation and Usage panel before applying it.

Sources¶

Tibo Sottiaux, “users use /fast less during the weekend”, August 1, 2026, 23:42 UTC. This is the author's usage observation; no aggregation method was published. ↩
OpenAI Forum, Codex is for Everyone: Why Codex Matters Beyond Code, May 13, 2026. ↩
OpenAI, Speed, accessed August 3, 2026. ↩↩
OpenAI, Using Codex with your ChatGPT plan, accessed August 3, 2026. ↩↩
OpenAI, Codex rate card, accessed August 3, 2026. ↩