"LLM Reasoning Modes (5/6) — OpenAI and Codex reasoning_effort: from minimal to xhigh"

Parts 3-4 showed that Claude's single effort knob tunes thinking, text, and tool calls all at once. Part 5 looks at how OpenAI handles the same trade-off. The key difference: OpenAI splits the knob in two — reasoning_effort for thinking depth, verbosity for output length.

OpenAI also exposes a knob to tune quality, latency, and cost per call without switching models. It's called reasoning_effort. But it differs from Claude in two decisive ways: the knob is split into two, and the set of values plus the default change by model generation. Part 5 takes both head-on.

In One Paragraph

OpenAI controls thinking depth with reasoning_effort (the Responses/Chat API; in the Codex CLI config it's model_reasoning_effort). The values differ by model generation — GPT-5 is minimal·low·medium·high, GPT-5.5 is none·low·medium·high·xhigh, and the gpt-5-codex family is low·medium·high·xhigh (no minimal; configuring it normalizes to low). The default is medium, the recommended balanced starting point. And OpenAI splits output length into a separate parameter, verbosity — in contrast to Claude's single effort, which moves thinking depth and output expansiveness together. Reasoning tokens are not returned verbatim (summaries only) and are billed as output tokens.

1. The Name of the Knob — reasoning_effort and model_reasoning_effort

In OpenAI, the parameter that tunes thinking depth is reasoning_effort. It surfaces in two places.

  • API (Responses / Chat): reasoning_effort.
  • Codex CLI config: model_reasoning_effort.

It's the same conceptual knob; just remember the key name differs between calling the API directly in code and setting it in the Codex CLI config file. The meaning is identical — it sets the tone for how many reasoning (thinking) tokens the model spends before the visible answer.

Higher effort means more reasoning tokens, longer inference, and better accuracy on hard tasks. Lower effort is the reverse. It's the same kind of trade-off knob as Claude's effort, but as the next section shows, the set of values differs by model generation.

2. Values by Model Generation — Same Knob, Different Notches

The first trap you hit: the values reasoning_effort accepts differ by model. A value that exists on one model is absent on another.

Model generation Accepted values Default Notes
GPT-5 minimal, low, medium, high medium supports minimal
GPT-5.5 none, low, medium, high, xhigh medium bottom is none, adds xhigh at the top
GPT-5.2-Codex / gpt-5-codex low, medium, high, xhigh medium no minimal — configuring it normalizes to low

How to read it:

  • GPT-5 puts minimal at the bottom.
  • GPT-5.5 shifts the bottom to none and adds xhigh at the top.
  • The gpt-5-codex family (including GPT-5.2-Codex) is tuned for coding and agentic work and does not support minimal. If you configure minimal, it normalizes to low. So on a Codex model, the lightest "reasoning-nearly-off" step is low.

Because the notches differ per generation, when moving code or config to a different model you must stay within the values that model accepts.

3. minimal — The Latency-Shaving Step

minimal runs with few or no reasoning tokens to minimize latency — especially time-to-first-token.

When to use it:

  • Deterministic, lightweight tasks with a narrow output space — extraction, formatting, short rewrites, simple classification.
  • Work where deep thinking barely improves accuracy and only adds latency.

When to avoid it:

  • Multi-step planning or tool-heavy workflows. Shaving reasoning on these hurts quality.

minimal exists on GPT-5 and is absent on the gpt-5-codex family (configuring it normalizes to low). On GPT-5.5 the bottom rung is none.

4. The Default Is medium — and When to Go Higher

The default, per the table above, is medium. It's the recommended starting point that balances quality, reliability, latency, and cost. Absent a specific reason, start here and move toward whichever side you need.

  • If answers come out shallow on a hard task, raise effort (high, and xhigh on models that support it). More reasoning tokens, longer inference, higher accuracy on hard tasks.
  • For lightweight, deterministic tasks, lower it (low, GPT-5's minimal, GPT-5.5's none). Less latency and cost.

Note that where Claude defaults to high, OpenAI defaults to medium — a common point of confusion when moving between the two platforms, since "leave it at the default" means a different amount of thinking on each.

5. reasoning_effort vs verbosity — Splitting the Knob in Two

Here is the core design difference in OpenAI. Separate from reasoning_effort, OpenAI has a parameter called verbosity.

  • reasoning_effort = the depth of thinking. How many reasoning tokens to spend before the visible answer.
  • verbosity (low / medium / high) = the length/expansiveness of the output. How far to unfold the answer.

The two are orthogonal. verbosity lets you tune answer length without rewriting the prompt — e.g., think deeply (high reasoning_effort) but answer briefly (low verbosity), or the reverse.

Let's make the contrast with Claude explicit.

Thinking depth Output length/expansiveness
Claude effort controls both (controlled by the same effort)
OpenAI reasoning_effort verbosity (separate)

So Claude's single effort knob moves thinking depth and output/tool verbosity together. OpenAI splits this into two knobs, turning thinking depth (reasoning_effort) and output length (verbosity) independently. Two design philosophies for the same trade-off.

6. How Reasoning Tokens Are Returned and Billed

OpenAI's reasoning tokens are not returned verbatim — they're hidden, with optional summaries only. And reasoning tokens are billed as output tokens (general OpenAI platform behavior and pricing). So raising reasoning_effort increases the hidden reasoning tokens, and your output-token cost rises accordingly.

This shares the same broad frame as Claude — on both platforms, thinking/reasoning tokens are billed at the expensive output-token tier, and the raw chain of thought is not returned (a summary is the ceiling). That's why the effort knob is not only a quality lever but a direct cost lever.

7. Codex CLI — config.toml and the -c Override

In the Codex CLI, the same knob surfaces in both the config file and on the command line.

Write the model and reasoning effort into ~/.codex/config.toml.

model = "gpt-5.2-codex"
model_reasoning_effort = "high"   # low | medium | high | xhigh

To use a different effort for a single run, override the setting with -c.

codex -m gpt-5.2-codex -c model_reasoning_effort="xhigh" "your prompt"

The full enum the config accepts is none | minimal | low | medium | high | xhigh. But whether a value actually applies is subject to per-model support. For instance, the gpt-5-codex family has no minimal (configuring it normalizes to low), so on a default Codex model the lightest step is low.

8. Which Value to Pick — Summary

  • Default to medium — the balance of quality, reliability, latency, and cost. Start here.
  • Lightweight, deterministic tasks (extraction, formatting, short rewrites, simple classification) → minimal (GPT-5) / none (GPT-5.5) / low (Codex family). Shaves latency.
  • Hard, multi-step, tool-heavy tasks → high, and xhigh on supporting models. Spend more reasoning tokens and time to gain accuracy.
  • If answer length is the problem, move verbosity, not effort. Thinking depth and output length are separate knobs.

What Comes Next

We've now dissected Claude's effort (Parts 3-4) and OpenAI's reasoning_effort plus verbosity (Part 5) separately. The final Part 6 puts them side by side — comparing the cost, latency, and quality trade-offs with benchmark figures, and laying out how to match the knob to task difficulty. That's where the answer to "does more thinking always help?" lives.

Parameter names, per-model values, defaults, and Codex configuration are grounded in OpenAI's GPT-5 new-parameters docs, the GPT-5.5 and GPT-5.2-Codex model docs, and Codex CLI configuration sources. Reasoning-token billing (at the output-token tier) is stated as general OpenAI platform behavior.

Series overview: Series index

๋Œ“๊ธ€

๋Œ“๊ธ€ ์“ฐ๊ธฐ

์ด ๋ธ”๋กœ๊ทธ์˜ ์ธ๊ธฐ ๊ฒŒ์‹œ๋ฌผ

"ML Foundations (9/9) — PyTorch vs TensorFlow, and the Road to Local LLMs"

์ด๋ฏธ์ง€
← 8/9 Deep Learning Architec… ๐Ÿ“š Series Index (series end) The final part. So far we've focused on models. Now we focus on the tools that actually run them . We'll lay out the philosophical difference between PyTorch and TensorFlow, and trace how Hugging Face transformers , llama.cpp , MLX , and Ollama built the bridge to running large language models on your own machine. By the end you should have the full mental model of "download a pretrained LLM and serve it locally." 0. Learning Objectives Explain the eager-vs-graph difference between PyTorch and TensorFlow. Explain, in graph terms, how autograd automates the backward pass. Use Hugging Face transformers ' AutoModel , AutoTokenizer , and pipeline abstractions. Describe llama.cpp's GGUF quantization, INT4 inference, and CPU-first flow. Describe Apple MLX's use of unified memory and how it differs from PyTorch. Run a local LLM with Ollama and call it through an OpenAI-compatible API. ...
Read more »

Agent Memory Engine (2/10) — Building an AI Agent Memory System with SQLite Alone

← 1/10 SQLite Memory Engine f… ๐Ÿ“š Series Index 3/10 memcore Completed → A memory engine that runs without daemons, without dependencies, anywhere ํ•ต์‹ฌ ์š”์•ฝ This post covers how to design an AI agent memory engine (memcore) on a single-file SQLite backend. - Structure: 25 modules, ~6,464 lines, 22 DB tables - Principles: no daemon, single-file portability, no required external dependencies, host-agnostic - Core techniques: 4-layer hybrid search (topic · vector · FTS5 · LIKE), U-tag dialectic-based confidence evolution, ingestion-layer bias rejection rules What This Post Covers One approach to building AI agent memory without a server or cloud vector DB. Specifically: (1) the limitations of text-file-based memory, (2) vector DB alternatives compared and selection criteria, (3) how to layer search tiers, (4) how to evolve confidence scores over time, and (5) how to block biased memory accumulation at the ingestion stage. Design Principles: Why Single-File SQLite Text-file-based ...
Read more »

"ML Foundations (8/9) — Deep Learning Architectures: CNN, RNN, Attention"

์ด๋ฏธ์ง€
← 7/9 Deep Learning Training ๐Ÿ“š Series Index 9/9 PyTorch vs TensorFlow → What did we keep adding on top of an MLP? Vision went CNN, sequences went RNN/LSTM, and eventually both converged on Attention and the Transformer. Each architecture is easier to remember if you read it as what it gave up to gain something else . This part is the one-line summary of the decisive inflection points: LeNet → AlexNet → ResNet → LSTM → Attention → Transformer. 0. Learning Objectives Explain why CNN's convolution, pooling, and weight sharing match images so well. Trace what got unblocked from LeNet → AlexNet → VGG → ResNet as depth grew. State BPTT for RNNs and the vanishing/exploding gradient problem. Write the LSTM gate equations (forget, input, output) with intuition. Write the attention formula in query/key/value form and the scaled dot-product variant. State the precise reasons Transformers replaced RNNs (parallelism + long-range dependencies). 1. ํ•ต์‹ฌ ์š”์•ฝ CNN : weight sharin...
Read more »

"RAG Core Study (14/26) — Evaluation Sets with RAGAS & DeepEval"

์ด๋ฏธ์ง€
Series overview: Series index ๐Ÿ“š Series Index Without an evaluation set, every RAG improvement is a story, not evidence. RAG systems fail in more than one place: retrieval, context selection, answer generation, and grounding. That means "looks better" is not a metric. Part 14 explains how to build a golden dataset , how RAGAS and DeepEval fit into the workflow, and why teams must separate retrieval quality from answer quality if they want tuning decisions to hold up. 0. Prerequisites Part 13 reranking — system quality now depends on multi-stage ranking. Part 1 grounding — a correct-looking answer is not enough. Part 12 Hybrid — multiple retrieval settings need comparison on fixed data. 1. Learning Objectives Build a small but useful golden dataset for RAG. Distinguish retrieval metrics from answer metrics . Use RAGAS and DeepEval in the right roles. Avoid the common traps in judge-model-based evaluation. 2. ํ•ต์‹ฌ ์š”์•ฝ An evaluation set for RAG is ...
Read more »

"ML Foundations (7/9) — Deep Learning Training: Optimizers, Regularization, Initialization"

← 6/9 Neural Networks ๐Ÿ“š Series Index 8/9 Deep Learning Architec… → Building an MLP, as we did in Part 6, is not the same as getting it to train well . The right optimizer, regularization, initialization, and learning rate — when these line up, deep networks converge. When they don't, the network refuses to learn at all. This part is the catalog of those crafts, with formulas, paper citations, and code in one place. 0. Learning Objectives Compare and write the update rules for SGD, Momentum, Nesterov, and Adam. Explain how Dropout, BatchNorm, and LayerNorm work and where they belong in a model. Derive the variance formulas for Xavier and He initialization and match them to activations. Implement step, cosine, and warmup learning-rate schedules in PyTorch. Explain why gradient clipping is effectively required for RNNs and Transformers. Diagnose the most common training failures (NaN, plateau, overfitting) and apply first-line fixes. 1. ํ•ต์‹ฌ ์š”์•ฝ SGD : \(w \leftarro...
Read more »

AI Agents I Built (5/7) — Building an Automated Blogger API Publishing System

← 4/7 My Life Organizer Agent ๐Ÿ“š Series Index 6/7 Dual → Designing a Markdown-Based Auto-Publish Pipeline with Blogger API v3 + OAuth 2.0 Key Summary Blogger API v3 + OAuth 2.0 enables a pipeline that converts Markdown files into publishable HTML posts blogger_publish.py handles the full flow — frontmatter parsing → body cleanup → HTML conversion → CSS injection → API post — in a single script For bulk publishing, quota management (delay, retry, TOC suppression) is the critical design concern Platform Selection Criteria API access is mandatory for AI agent-driven content publishing. A comparison of platforms: Platform API Cost AdSense Decision WordPress.com REST API Paid plan required Paid only Cost overhead Ghost REST API Self-hosted or paid Manual setup Ops overhead Blogger v3 API Free Native integration Adopted Blogger is free, exposes a REST API, and integrates natively with AdSense. For personal blog automation, this combination i...
Read more »

"ML Foundations (6/9) — Neural Networks: From Perceptron to MLP"

์ด๋ฏธ์ง€
← 5/9 Regularization & Model… ๐Ÿ“š Series Index 7/9 Deep Learning Training → A neural network is logistic regression from Part 4 stacked into layers. Each layer passes through a new nonlinear activation, expanding the family of functions the network can represent. In this part we put how a neural network learns onto one page. Perceptrons, XOR, MLPs, backpropagation, activation functions, and the universal approximation theorem all meet here. 0. Learning Objectives Write the perceptron's learning rule and explain why it cannot solve XOR. Express an MLP's forward pass as one line of matrix products. Derive backpropagation by hand on a two-layer MLP. Compare the definitions, derivatives, and trade-offs of sigmoid, tanh, ReLU, and GELU. State the universal approximation theorem (Cybenko 1989 / Hornik 1991) precisely. Train an MLP end-to-end in PyTorch. 1. ํ•ต์‹ฌ ์š”์•ฝ Perceptron (1958): \(\hat{y} = \mathrm{step}(w^\top x + b)\). Converges only on linearly separabl...
Read more »