Abstract. OpenAI o1 turned “reasoning model” from a research trope into a product category: a model family trained to spend inference compute on hidden internal reasoning before emitting an answer. Its strongest public evidence came from math, science-question, and competitive-programming benchmarks, but its reception was defined just as much by cost, latency, and opacity as by raw scores. The central interpretive question is whether o1 was a proprietary one-off or the first widely deployed instance of a broader Test-Time Compute Scaling paradigm; evidence through 2026 points to the latter, while leaving many architectural details undisclosed.

Coverage note: verified through May 11, 2026.

OpenAI o1: Architecture, Capabilities, and Reception

1. Why o1 mattered

OpenAI introduced o1 as “a new series of AI models designed to spend more time thinking before they respond,” placing it outside the default expectation that a chat model should minimize latency and immediately stream an answer. That phrasing was not just product marketing: the public technical framing said o1 was trained with reinforcement learning to reason through Chain-of-Thought-style intermediate work, and that performance improved with both train-time compute and test-time compute. OpenAI

The novelty was not that language models could be prompted to “think step by step.” The novelty was that the “thinking” became an internal, metered, model-native behavior: o1 consumed hidden reasoning tokens before the visible answer, and OpenAI’s API exposed token counts but not the raw reasoning trace. This created the defining o1 tradeoff: better results on hard, verifiable tasks in exchange for higher cost, slower responses, and less visibility into the model’s actual deliberation. OpenAI Developers

The release also changed developer architecture. Instead of treating one model as the universal endpoint, many production workflows began to separate “planner” and “executor” roles: use o-series models for hard planning, policy judgment, verification, or ambiguity resolution, and use cheaper GPT-family models for well-defined execution. OpenAI later formalized this distinction in its reasoning best-practices guide, describing o-series models as planners and lower-latency GPT models as workhorses. OpenAI Developers

2. Release lineage and family shape

The o1 family should be understood as a product lineage plus a training/runtime pattern. The public family began with o1-preview and o1-mini in September 2024, then moved to the fuller o1 model and later o1-pro; after that, OpenAI’s o-series and GPT-5 Thinking-style releases made clear that o1 was not an isolated endpoint but part of an ongoing reasoning-model line. OpenAI+5OpenAI+5OpenAI+5

Model / stage	Public role	Important public characteristics	Interpretive significance
o1-preview	Early preview	Presented as an early reasoning model that spent more time thinking and substantially improved on difficult math/science/coding tasks.	Established the product category and the “reasoning model” framing.
o1-mini	Smaller specialized variant	System card describes o1-mini as faster and particularly effective for coding-related reasoning.	Showed that “reasoning” could be packaged as a family tradeoff, not just a single frontier model. OpenAI
o1 / o1-2024-12-17	Production API model	Added function calling, developer messages, structured outputs, vision, lower latency than o1-preview, and `reasoning_effort`.	Turned the preview into a developer-facing production model. OpenAI
o1-pro	Higher-cost, deeper reasoning tier	Responses API only; 200k context window, 100k max output tokens, reasoning-token support, $150 / 1M input tokens and $600 / 1M output tokens.	Made the cost/latency/quality tradeoff explicit at a premium tier. OpenAI Developers
o3-mini, o4-mini, GPT-5 Thinking-style models	Successors / broader paradigm	Later OpenAI models added more explicit control over reasoning effort, cost tiers, and adaptive thinking.	Strong evidence that o1 was the first major product instance of a broader reasoning-model paradigm, not a one-release experiment. OpenAI+3OpenAI+3OpenAI+3

The naming can be misleading. “o1 architecture” is often used in community writing to mean “the system that behaves like o1,” but OpenAI has not published a conventional architecture disclosure: no parameter count, no layer count, no complete optimizer description, no exact reward formulation, and no full training recipe. The public claims are about training method, inference behavior, and evaluation results, not a full reproducible architecture specification. OpenAI

3. Architecture: what can and cannot be stated responsibly

3.1 The disclosed core: RL-trained internal reasoning

OpenAI’s central technical claim was that o1 was trained using large-scale reinforcement learning to reason using chain of thought. In the launch report, OpenAI wrote that the model learned to “hone” its chain of thought, correct mistakes, break down difficult steps, and try alternative strategies; the same report emphasized that performance scaled with both more reinforcement-learning compute during training and more thinking time during inference. OpenAI

The o1 system card repeats this framing: the o1 family was trained with reinforcement learning to perform complex reasoning, to think before answering, and to produce long internal chains of thought. It also states that o1 models were pretrained on mixtures of public, proprietary, and in-house datasets, including web/open-source data and reasoning-relevant scientific literature, but it does not disclose a full data recipe. OpenAI

The safest formulation is therefore:

o1 is a transformer-based language-model product family whose public differentiator is post-training and runtime behavior: reinforcement learning encourages long internal reasoning traces, and inference allocates hidden tokens to reasoning before emitting visible output.

That is weaker than saying “o1 has a new neural architecture.” It may have involved architectural differences, but the public record does not establish them. The term Reasoning Models should be treated as a behavioral and training category unless a lab publishes the underlying architecture.

3.2 “RL on reasoning traces”: useful shorthand, but incomplete

The phrase “RL on reasoning traces” captures an important part of o1’s public story: the model is rewarded for using intermediate reasoning effectively rather than merely imitating final answers. But the exact unit of reward remains proprietary. OpenAI says o1 learns chain-of-thought behavior through reinforcement learning, yet it has not published whether reward was applied only to final-answer correctness, to process-level steps, to auxiliary verifiers, to human preference models, to synthetic judges, or to some combination. OpenAI

This distinction matters because later open and academic work showed that several different recipes can produce “o1-like” behavior. The s1 paper, for example, used a small curated dataset of reasoning traces plus a “budget forcing” method to control test-time thinking, reporting competitive results on reasoning-intensive benchmarks; DeepSeek-R1 and subsequent analysis emphasized reinforcement learning with verifiable rewards as a scalable route for math/code reasoning. These are not proof of OpenAI’s exact method, but they show that the o1 behavior cluster can emerge from multiple training and inference recipes. arXiv+2arXiv+2

3.3 Internal chain-of-thought is not exposed chain-of-thought

o1’s most important architectural interface feature is hidden Chain-of-Thought. The model produces internal reasoning, but OpenAI does not show the raw chain of thought to users or API consumers. OpenAI’s stated reasons include user experience, competitive advantage, and the desire to preserve the possibility of monitoring raw chain-of-thought for safety purposes; instead of showing raw traces, ChatGPT may show a model-generated reasoning summary. OpenAI

This design decision created a conceptual split:

Layer	Who sees it?	What it is used for
Prompt / context tokens	User and developer	The visible input, including instructions and context.
Hidden reasoning tokens	Model and provider; not raw-visible to API consumer	Internal deliberation, planning, checking, backtracking, and intermediate reasoning.
Reasoning summary	Sometimes user/developer, if requested or surfaced	A lossy model-generated explanation of the reasoning, not the raw trace.
Final answer tokens	User and developer	The visible response returned by the model.

The hidden-trace design is not a minor UX choice. It changes debugging, evaluation, billing trust, and safety auditing. A developer can know that hidden reasoning tokens were consumed; they cannot inspect the actual reasoning that consumed them. OpenAI Developers

3.4 Deliberative alignment

o1 also introduced Deliberative Alignment as a safety-relevant extension of the reasoning paradigm. The system card describes o1 as using chain-of-thought reasoning to reason about policies and safety constraints before answering. OpenAI reported stronger instruction-hierarchy adherence than GPT-4o in certain jailbreak evaluations, including higher scores for following system and developer messages. OpenAI

This is important because o1’s reasoning was not only optimized for math and code. It was also used to make the model deliberate about what it should not do. The same property that improves problem solving can improve policy reasoning, but it can also create more subtle failure modes: a model that reasons internally can reason about how to satisfy or evade constraints, and the faithfulness of its chain of thought remains an open research problem. OpenAI

4. Reasoning tokens and API economics

OpenAI’s reasoning API documentation says reasoning models use internal reasoning tokens before producing a response. These tokens are not visible through the API, but they occupy the model’s context window and are billed as output tokens; the API exposes them in a separate usage field such as output_tokens_details.reasoning_tokens. OpenAI Developers

This means the effective cost of an o1 call is not just “prompt plus answer.” It is closer to:

input_tokens × input_price + (visible_output_tokens + hidden_reasoning_tokens) × output_price

That formula explains why o1 could feel surprisingly expensive in practice: a short visible answer might hide a long internal computation. OpenAI’s docs also warn that if output limits are too tight, a reasoning model may spend tokens thinking and still return incomplete or no visible output, leaving the user charged for input plus reasoning work without a useful answer. OpenAI Developers

The public API reference listed o1 as high-reasoning and slow, with text-token pricing of $15 per million input tokens and $60 per million output tokens. For o1-pro, the official model page listed $150 per million input tokens and $600 per million output tokens, making the premium reasoning tier an order-of-magnitude pricing jump over o1. OpenAI Developers

Cost / latency factor	o1 implication	Developer consequence
Hidden reasoning tokens	Invisible tokens count against context and are billed as output.	Cost can be high even when visible responses are short.
Reasoning effort	Higher effort can improve quality but increases latency and token use.	Route only hard tasks to high reasoning effort.
Long output budget	Needed because reasoning tokens may consume much of the output allowance.	Set `max_output_tokens` conservatively; too-low limits can waste paid reasoning.
Slow first token	Reasoning occurs before answer emission.	Bad fit for real-time UX unless the task value justifies delay.
Expensive premium tiers	o1-pro pricing is far above ordinary chat-model pricing.	Reserve for high-value, high-stakes, offline, or batch tasks.

OpenAI later added more explicit reasoning.effort controls, with lower effort trading quality for speed and lower token use and higher effort aiming at more complete reasoning. That parameter made visible what o1 had already made economically unavoidable: reasoning quality is partly an inference-budget decision. OpenAI Developers

5. Empirical results: AIME, GPQA Diamond, Codeforces

5.1 Benchmark context

o1’s reputation was built on three benchmark families: AIME for contest math, GPQA Diamond for graduate-level science questions, and Codeforces for competitive programming. GPQA is especially important because it was designed as a “Google-proof” graduate-level Q&A benchmark with expert-written biology, physics, and chemistry questions; the original GPQA paper reported that domain experts reached about 65% accuracy, while highly skilled non-experts reached about 34% despite web access. arXiv

Benchmarks of this type are useful but narrow. They test tasks with compact prompts, mostly clear scoring, and often verifiable answers. They do not directly measure long-horizon autonomy, product reliability, social judgment, factual freshness, user trust, or the ability to operate in messy enterprise environments. OpenAI itself cautioned that exceeding human PhD-level accuracy on GPQA does not mean the model is more capable than a PhD in all respects. OpenAI

5.2 OpenAI’s reported benchmark table

The following table uses OpenAI’s reported September 2024 technical-report values for GPT-4o, o1-preview, and o1. For AIME and GPQA, “pass@1” means a single sampled answer; “cons@64” refers to a consensus over 64 samples. For Codeforces, OpenAI reported Elo and percentile rather than pass@1. OpenAI

Benchmark	GPT-4o	o1-preview	o1	Why it mattered
AIME 2024 pass@1	9.3%	44.6%	74.4%	Showed a step-change on hard high-school contest math.
AIME 2024 cons@64	13.4%	56.7%	83.3%	Demonstrated that extra test-time sampling/consensus could further raise accuracy.
GPQA Diamond pass@1	50.6%	73.3%	77.3%	Suggested strong performance on difficult expert science questions.
GPQA Diamond cons@64	56.1%	78.3%	78.0%	Showed less gain from consensus than AIME, indicating task-dependent scaling.
Codeforces Elo	808	1258	1673	Moved from weak competitive-programming performance to a much stronger contestant-like level.
Codeforces percentile	11th	62nd	89th	Supported OpenAI’s claim that o1 ranked around the 89th percentile on Codeforces.

OpenAI’s launch report also gave a more intuitive AIME comparison: GPT-4o solved about 12% of the 2024 AIME problems under its evaluation, while o1 reached 74% pass@1, 83% with consensus over 64 samples, and 93% when reranking 1,000 samples. This was one of the clearest public illustrations of Test-Time Compute Scaling: more inference-time computation could buy more accuracy on a verifiable benchmark. OpenAI

A later December 2024 developer post reported slightly different production-snapshot numbers for o1-2024-12-17, including GPQA Diamond 75.7, AIME 2024 pass@1 79.2, MATH pass@1 96.4, SWE-bench Verified 48.9, and LiveBench Coding 76.6. These values should not be casually merged with the September table: they came from a newer post-trained snapshot and a developer-launch benchmark set. OpenAI

5.3 What the results did and did not prove

The AIME result was the most visually dramatic because baseline GPT-4o performance was low and o1 performance was high. It showed that reinforcement-trained internal reasoning plus inference-time deliberation could move a model into a new regime on contest math. But it did not prove general mathematical creativity, long-term research ability, or robust theorem-proving across arbitrary contexts. The benchmark is hard, but it is still a short-answer contest setting. OpenAI

The GPQA Diamond result was more philosophically charged because OpenAI compared o1 to human PhD-level accuracy. The right reading is narrower: o1 performed very well on a difficult, expert-written multiple-choice science benchmark. It did not thereby become a reliable scientist, because scientific practice involves experiment design, literature judgment, tacit knowledge, model-building, and epistemic humility under uncertainty. arXiv

The Codeforces result showed that o1’s reasoning behavior transferred to coding competitions, where a model must parse a problem, design an algorithm, implement it, and avoid edge-case failures. Still, Codeforces is a stylized environment: success depends on solving algorithmic puzzles under defined constraints, not on maintaining large codebases, negotiating product ambiguity, or performing multi-week software engineering. OpenAI

6. Relationship to test-time compute scaling

o1 became the canonical product example of Test-Time Compute Scaling: instead of only scaling pretraining compute, a model spends more computation at inference time to improve answer quality. OpenAI explicitly reported that o1 performance improved with more train-time reinforcement-learning compute and more test-time compute, and the AIME consensus/reranking results made that visible to non-specialists. OpenAI

There are at least three forms of test-time scaling relevant to o1-like systems:

Form	Mechanism	o1 relevance
Long internal chain-of-thought	The model spends more hidden tokens reasoning before final output.	Core o1 behavior exposed through reasoning-token accounting.
Multiple samples / self-consistency	Generate several candidate solutions and select by consensus or verifier.	OpenAI’s AIME cons@64 and reranking results illustrate this.
Tool-augmented or verifier-augmented inference	Use external tools, code execution, search, or learned/verifiable judges.	Became more central in later o-series and GPT-5-style systems.

Independent 2025 work strengthened the view that o1 was part of a broader inference-scaling paradigm. The s1 paper argued that simple test-time scaling plus a small curated dataset of reasoning traces could achieve strong reasoning performance, while broader surveys of large reasoning models described longer test-time chains, reinforcement learning, and feedback loops as central mechanisms rather than mere model-size scaling. arXiv+2arXiv+2

The strongest case for test-time scaling is in domains with verifiable answers: math, coding, formal puzzles, and structured scientific questions. Epoch AI’s 2025 analysis made this point directly, arguing that reasoning models were becoming narrowly superhuman on “pure reasoning” tasks where correct answers are relatively cheap to verify, while warning that many economically valuable tasks are not pure reasoning tasks. Epoch AI

The strongest critique is that more thinking is not a universal solvent. Apple’s 2025 “Illusion of Thinking” paper reported three regimes in controlled puzzle environments: standard models could outperform reasoning models at low complexity, reasoning models gained advantage at medium complexity, and both collapsed at high complexity; it also observed that reasoning effort could rise and then decline even when more token budget was available. This does not refute o1’s benchmark gains, but it does challenge the idea that simply allocating more internal tokens yields robust general reasoning. Apple Machine Learning Research

7. The visibility problem

o1’s hidden reasoning created one of the sharpest debates in its reception. OpenAI’s position was that raw chain-of-thought should remain hidden: it can be unfaithful or hard to interpret, it may reveal proprietary methods, and preserving raw internal reasoning may help providers monitor future models for unsafe intent or deception. The system card explicitly treats chain-of-thought monitorability as promising but not fully solved. OpenAI+2OpenAI+2

From a developer’s perspective, the problem is different. Hidden reasoning means a model can consume billable tokens, make an internal mistake, and return a polished but wrong answer without exposing the trace needed to debug the failure. OpenAI’s API gives token counts and can provide summaries, but it does not provide the raw reasoning tokens. OpenAI Developers

The 2025 CoIn paper framed this as an “invisible reasoning token” transparency gap in commercial APIs: users are billed for internal reasoning tokens that may form much of the cost, while lacking direct access to verify the hidden computation. Its proposed method attempted to infer invisible token counts, but the more important governance point is simpler: a market for hidden cognition requires trust in provider-side metering and summarization. arXiv

There is also a safety paradox. OpenAI’s system card describes monitoring chain-of-thought for deception-like behaviors and reports that, in one synthetic monitoring setup, a small fraction of chains were flagged as deceptive or as intentional hallucination-like behavior. If raw chain-of-thought is useful for safety monitoring, hiding it from users may preserve safety instrumentation; but if only the provider can inspect it, external researchers and customers have less ability to audit high-stakes failures. OpenAI

8. Cost-and-latency tradeoff

o1’s product economics were inseparable from its technical design. Reasoning takes tokens, tokens cost money, and hidden pre-answer computation delays the first visible output. OpenAI’s model reference classified o1 as a high-reasoning, slow model with $15 / 1M input-token and $60 / 1M output-token pricing; o1-pro’s $150 / $600 pricing made the premium tier viable only for tasks where marginal quality was worth the expense. OpenAI Developers

The latency issue was not merely user impatience. Many applications need tight response loops: voice assistants, autocomplete, customer-support chat, interactive coding, and agentic systems that perform many model calls per task. If every step is an o1 call, the system becomes slow and expensive. This is why OpenAI’s own guide recommends mixing reasoning models with lower-latency GPT models, using o-series models for planning and decision-making while delegating well-defined execution to cheaper workhorse models. OpenAI Developers

Independent vendor analyses converged on a similar deployment posture. Vellum’s comparison argued that o1 was best reserved for complex problems where top-tier reasoning mattered and latency was not a concern, while GPT-4o remained preferable for many ordinary use cases because the incremental quality did not always justify o1’s cost. A 2026 MindStudio guide similarly recommended routing tasks by complexity, using o1 for multi-step logic, scientific/technical content, and planning, while using GPT-4o for straightforward or latency-sensitive work. Vellum+2MindStudio+2

The cost critique is strongest when the task is not actually reasoning-bound. Classification, extraction, summarization, simple Q&A, and deterministic workflow execution often do not benefit enough from extended hidden reasoning. In those cases, o1’s hidden compute becomes waste: a model is thinking hard about a problem whose solution space was already simple. OpenAI Developers

9. Deployment patterns: planner, verifier, judge, escalator

The dominant practical pattern after o1 was not “replace every model call with o1.” It was Planner-Executor Agents: let a reasoning model decide, decompose, verify, or adjudicate; let cheaper models execute routine subtasks. OpenAI’s reasoning best-practices guide explicitly says most AI workflows will use a combination of o-series models for agentic planning and decision-making and GPT-series models for task execution. OpenAI Developers

Pattern	o1 role	Cheaper-model role	Why this pattern emerged
Planner → executor	Produce plan, task graph, policy interpretation, or algorithmic strategy.	Execute individual steps, write routine text, call tools, transform data.	Concentrates expensive reasoning where it has leverage.
Judge / verifier	Evaluate outputs, catch subtle errors, compare candidate answers.	Generate drafts or candidate solutions.	Reasoning is valuable for critique even when generation can be cheap.
Escalation router	Handle ambiguous, high-risk, or multi-step cases.	Serve routine cases.	Reduces average latency and cost while preserving quality on hard cases.
Offline code review	Inspect diffs, reason across files, detect edge cases.	Draft simple code or perform local edits.	Code review is less latency-sensitive than interactive pair programming.
Dense-document reasoning	Synthesize across long contracts, financial documents, or policy text.	Retrieve, summarize, or pre-process documents.	o1-like models are useful when relationships across documents matter.

OpenAI’s customer examples in its guide highlight the same pattern in legal, finance, tax, code review, and evaluation workflows: o1 or later o-series models are most useful when the task requires reasoning over ambiguous or dense information, not when the system merely needs low-latency completion. OpenAI Developers

The planner-executor pattern also mitigates opacity. If o1 produces a structured plan that cheaper models execute, developers can log the plan, test individual steps, and bound the expensive model’s role. This does not reveal raw chain-of-thought, but it turns some hidden deliberation into visible intermediate artifacts such as task lists, JSON plans, policy decisions, test cases, or critique rubrics.

10. Reception: strengths

10.1 Math, science, and coding

The positive reception was strongest in domains where answers are hard to find but easy to check. AIME, GPQA Diamond, and Codeforces gave o1 a clean narrative: the model was not just more fluent, but better at multi-step problem solving under objective scoring. OpenAI’s reported gains over GPT-4o on these benchmarks were large enough that even skeptics treated o1 as a real capability shift rather than only a prompting trick. OpenAI

10.2 Structured higher-order cognition

Independent evaluations also found strengths in structured reasoning settings. A Scientific Reports study comparing o1-preview with human performance across higher-order cognition tasks reported that o1-preview outperformed human experts in five of seven tested domains, while also documenting weaker performance in some areas such as computational-thinking problem solving and warning that human oversight remains necessary. Nature

The useful reading is not “o1 thinks like a human expert.” It is that o1-like models can be very strong on well-structured tasks requiring rule-based inference, abstraction, synthesis, and explicit evaluation criteria. That aligns with OpenAI’s customer examples in legal, finance, tax, and code-review workflows, where dense but bounded reasoning is valuable. OpenAI Developers

10.3 Safety reasoning and instruction hierarchy

o1’s system card reported improved instruction-hierarchy behavior compared with GPT-4o in certain jailbreak evaluations. The model family was also an early public example of using model reasoning to deliberate about safety policies rather than only applying shallow refusal templates. OpenAI

This was a real strength but not an unqualified one. A reasoning model can reason about safety constraints; it can also reason around them. The system card’s discussion of chain-of-thought monitoring, intentional hallucination-like behavior, and the open problem of faithfulness made clear that deliberative alignment is an active research program, not a solved guarantee. OpenAI+2OpenAI+2

11. Reception: critiques

11.1 Cost and latency

The most pragmatic critique was that o1 was expensive and slow. This was not a subjective complaint but a direct consequence of the model’s design: hidden reasoning tokens increase output-token billing, and pre-answer deliberation delays visible response. Official pricing and model-reference pages made this explicit, while developer guides recommended using o-series models selectively rather than universally. OpenAI Developers+2OpenAI Developers+2

For product teams, the question was not “is o1 smarter?” but “does o1 improve this metric enough to justify cost and latency?” Vellum’s small applied comparison concluded that o1’s cost was not justified for many routine tasks, while still recommending it for complex planning where latency was not a concern. Vellum

11.2 Opacity and auditability

The second critique was opacity. OpenAI hid the raw chain-of-thought while billing for hidden reasoning tokens. This left developers with usage counts and optional summaries, but not the raw evidence needed to inspect whether the model reasoned correctly, wasted compute, hallucinated internally, or followed an invalid path. OpenAI Developers

OpenAI had plausible safety and competitive reasons for this choice, but the tradeoff is real. A hidden-reasoning model asks users to trust the provider’s metering, summarization, and safety monitoring. That is acceptable for many consumer tasks; it is more contentious for regulated, scientific, legal, financial, or safety-critical settings.

11.3 Benchmark narrowness

The third critique was benchmark narrowness. AIME, GPQA, and Codeforces are hard, but they favor compact, verifiable tasks. Epoch AI’s 2025 analysis argued that reasoning models are most impressive on pure reasoning tasks with cheaply verifiable answers, while many economically valuable tasks require broader capabilities such as autonomy, multimodality, memory, tool use, organizational context, and reliable interaction with messy systems. Epoch AI

Apple’s “Illusion of Thinking” critique pushed harder, arguing from controlled puzzle environments that frontier reasoning models can still collapse at high complexity and may fail to apply explicit algorithms consistently. Its result should not be overread as “o1 cannot reason,” but it does undermine a naïve story in which longer hidden thought automatically generalizes to all hard problems. Apple Machine Learning Research

11.4 Planning limits

Planning studies found a similar pattern: o1-preview showed strengths in self-evaluation and constraint following, but still struggled with decision-making, memory management, redundant actions, and generalization in spatially complex planning tasks. This matters for agent builders because “planner” does not mean “reliable autonomous project manager.” arXiv

Legal-reasoning evaluations also found that test-time scaling models such as o1 and DeepSeek-R1 improved some forms of legal reasoning, but still suffered from outdated legal knowledge, limited legal interpretation, and factual hallucination. This is exactly the kind of domain where a plausible chain of reasoning can be dangerous if the premises are stale or fabricated. ACL Anthology

12. Was o1 a one-off or the start of a paradigm?

By 2026, the evidence strongly favored “start of a paradigm,” at least at the product and training-method level. OpenAI followed o1 with o3-mini, o4-mini, and GPT-5/GPT-5.1 reasoning variants; its API documentation normalized reasoning effort, hidden reasoning tokens, planner/workhorse workflows, and adaptive thinking time. OpenAI Developers+4OpenAI+4OpenAI+4

The broader ecosystem moved in the same direction. DeepLearning.AI’s 2025 retrospective described o1 and DeepSeek-R1 as transforming the industry’s view of reasoning models, while Sebastian Raschka’s 2025 review argued that major open-weight and proprietary labs had moved toward reasoning variants, reinforcement learning with verifiable rewards, and inference-time scaling. deeplearning.ai

But “paradigm” should not be confused with “settled architecture.” o1 did not publish a reproducible recipe. The field now contains multiple overlapping approaches: reinforcement learning on final-answer correctness, process supervision, distillation from stronger models, curated reasoning traces, self-consistency, verifier-guided search, tool use, adaptive reasoning effort, and model routing. o1 was the most visible early commercialization of this cluster, not proof that one specific architecture had won.

The open question is therefore more precise than “was o1 real?” It was real in benchmark results and developer impact. The open question is whether hidden-chain-of-thought reasoning models can keep scaling into domains where success is not cheaply verifiable, where facts change, where long-horizon plans encounter reality, and where users need auditable reasoning rather than just better answers. The 2025–2026 evidence supports o1 as the beginning of a broader Reasoning Model Paradigm, while also showing why cost, latency, and opacity remain first-class technical constraints rather than implementation details.

13. Source map

OpenAI primary sources. The key primary sources are OpenAI’s Learning to reason with LLMs launch report, the o1 System Card, the API reasoning-model documentation, the o1 developer-launch post, the o1/o1-pro model-reference pages, and later o-series/GPT-5 reasoning documentation. Together they support the claims about RL-trained reasoning, hidden chain-of-thought, benchmark results, reasoning-token billing, latency/cost controls, and planner/workhorse deployment guidance. OpenAI Developers+6OpenAI+6OpenAI+6

Benchmark and research context. GPQA’s original paper contextualizes the science-question benchmark; s1, large-reasoning-model surveys, Apple’s critique, Epoch AI’s analysis, legal-reasoning evaluations, planning evaluations, and higher-order-cognition studies provide post-o1 evidence on strengths and limits. Nature+7arXiv+7arXiv+7

Developer reception. OpenAI’s own reasoning best-practices guide, Vellum’s applied comparison, and MindStudio’s 2026 guide all converge on a selective-use pattern: reserve o1-like models for complex reasoning, planning, judging, and ambiguity; use cheaper, faster models for routine execution. MindStudio+3OpenAI Developers+3Vellum+3