ChatGPT vs Gemini vs Claude: How They Differ
New book – Latency: Reduce Delay in Software Systems (Sponsored)
Learn practical techniques to make your software faster at every layer of the stack
Working on latency-sensitive applications? This book will help you spot, understand, and fix latency in your applications and infrastructure. It shares low-latency techniques that have been predominantly “tribal knowledge” until now. You’ll learn a full-stack approach, with techniques that intersect many areas of software engineering, distributed systems, databases, and operating systems.
Understanding and negotiating caching tradeoffs (latency vs. complexity)
Exploring the two main concurrency models (threading and event-driven architecture)
Identifying and applying parallelization opportunities to improve throughput and reduce latency
Applying asynchronous process strategies that reduce perceived latency and improve overall system responsiveness.
Get this 3-chapter excerpt and start reading the book that’s become essential for anyone working with strict performance SLAs.
If we send the same prompt to ChatGPT, Gemini, and Claude, the answers come back meaningfully different. Claude might push back more often. Gemini ingests a two-hour video file as easily as a paragraph of text. ChatGPT routes some prompts to a slower reasoning mode and answers others instantly, without telling the user which path it took.
Why does each model behave this way, and why so consistently?
Each pattern traces back to an architectural decision point where the developers of these frontier models made distinct design choices, and the user-visible behavior follows directly from those choices.
To understand these differences clearly, we need to examine architecture and design, since architectural decisions remain consistent across releases and provide a reliable framework for understanding model behavior over time.
In this article, we will look at the various architectural forks the teams building these models encountered and the decisions they took.
Disclaimer: This post is based on publicly shared details from various sources. Please comment if you notice any inaccuracies.
Foundations
All three models share the same fundamental architecture, which is a transformer-based generative neural network.
The transformer was introduced in the 2017 paper “Attention Is All You Need,” and at its core is a mechanism called self-attention that allows each token in a sequence (a token being a small piece of text, roughly three-quarters of a word) to weigh its relationship to every other token. This setup is shared across the three models, while the components built around it, along with the training process that shapes it, vary substantially.
Training itself involves two phases:
Pre-training is where the model learns from massive amounts of text and other data by predicting the next token, repeated billions of times over.
Post-training is where the base model gets shaped into a helpful assistant through methods like Reinforcement Learning from Human Feedback (RLHF) and Constitutional AI. We will get to them in more detail in a later section.
Each architectural fork follows a consistent pattern, where different companies faced the same design question, each made a particular architectural choice, and each choice produced user-visible behavior we can observe today.
The first such question concerns how to scale the model’s total capacity without proportionally increasing the cost of processing every query.
Density
Every parameter added to a model carries computational cost. In a standard dense neural network, every parameter activates for every token processed, meaning that doubling the parameter count roughly doubles the compute cost per query.
Frontier developers needed a way to escape this constraint, and the architectural question became how to scale total capacity without paying full price on every single token.
Google adopted a technique called Mixture of Experts, or MoE. The Gemini 1.5 technical report identifies the model as “a sparse mixture-of-expert (MoE) Transformer-based model” that “builds on a much longer history of MoE research at Google,” with the Gemini 3 Pro model extending the same approach.
In an MoE layer, instead of one massive computational block where every parameter activates for each token, the network contains many smaller experts, and a small router determines which two or three experts each token should be sent to. The total parameter count can be enormous while only a fraction is activated per token, though achieving consistent results requires careful attention to load balancing and expert specialization during training.
OpenAI has not explicitly confirmed whether GPT-4 uses MoE, and the GPT-4 technical report deliberately omits architecture details. The GPT-5 system details describe a different efficiency approach that we will examine in the Reasoning section, where a router selects between distinct sub-models at runtime.
Nevertheless, these architectural choices produce meaningful consequences in user experience.
MoE models can pack more knowledge per dollar of compute, which contributes to Gemini’s capable handling of a wide breadth of domains. The tradeoff is increased variance, since different prompts route to different experts, and imperfect load balancing during training can leave some experts underused and weaken the model’s capacity on those topics. Dense models tend to deliver more predictable per-token behavior at the cost of being harder to scale to extreme parameter counts.
See the illustration below:
Turn cloud logs into real security signals (Sponsored)
This guide from Datadog provides best practices on how to use Cloud SIEM to detect threats, investigate incidents, and reduce blind spots across cloud and Kubernetes environments.
You’ll learn how to:
Analyze CloudTrail, GCP audit, and Azure logs for suspicious activity
Detect authentication anomalies and common attack patterns
Monitor Kubernetes audit logs for lateral movement and misuse
Correlate signals across services to accelerate investigations
Multimodality
The term multimodal carries different meanings depending on the architectural approach, and a precise distinction helps before we take a look at the design choices.
Two fundamentally different approaches exist for handling non-text inputs like images, audio, and video:
Sequential approach: Train a strong language model first, then add a separate encoder later that translates non-text inputs into embeddings the language model can attend to.
Native approach: Train a single network from inception on all modalities simultaneously, so that text tokens, image patches, and audio frames coexist in the same sequence and get processed by the same transformer layers.
See the diagram below that shows the difference between the two:
These two approaches produce different capabilities.
Google adopted the native approach from the start. The Gemini 1.0 release was designed as natively multimodal, and the 1.5 technical report demonstrates the model handling, in a single input, “10.5 hours of video at 1 frame-per-second”, and the current Gemini 3 Pro model continues this design, where the model offers “native multimodal support for text, vision, and audio inputs.”
OpenAI took a different path initially, with the original GPT-4 supporting vision through a separate pipeline. GPT-4o, released in May 2024, transitioned to a unified architecture, and OpenAI’s own announcement for GPT-5.5 acknowledged that “previous multimodal models from OpenAI were essentially separate models stitched together.”
Lastly, Anthropic has maintained a text-first approach with strong vision capabilities, and Claude Opus 4.8 continues to support high-resolution image input introduced in Opus 4.7 at 3.75 megapixels, particularly useful for documents, screenshots, and dense charts. Anthropic has chosen to focus on text and vision as primary input modalities while setting native audio and video aside for now.
For users, this architectural difference appears most clearly when working with video. Gemini handles long video files directly, and ChatGPT does the same on its more recent models. Claude performs best with documents, screenshots, and high-fidelity images.
Context
A context window represents the amount of input a model can attend to in a single pass, measured in tokens.
Larger windows allow the model to reason over more raw material at once, though long context introduces two important challenges:
Computational cost: Attention scales roughly quadratically with sequence length, so longer windows consume significantly more compute per query.
Quality degradation: Models often lose track of information mentioned earlier as the window fills, with the relevance of early context dropping over the course of a long conversation.
Google pushed hardest on raw window size. The Gemini 1.5 technical report demonstrated context up to 10 million tokens, and Gemini 3 Pro and 3.1 Pro continue to offer 1 million token context in production.
Anthropic offers 1 million tokens on Claude Opus 4.8 and Sonnet 5, and the company’s own documentation uses the term “context rot” to describe quality degradation in long sessions, addressed through automatic compaction that summarizes earlier portions of the conversation.
OpenAI has taken a more conservative position on window size, with GPT-4 Turbo at 128K, focusing efficiency gains on the routing architecture covered in the Reasoning section.
The practical experience differs across the three models. Loading an entire codebase or a multi-hour transcript into a single session works well with Gemini and Claude, given the larger windows available. ChatGPT is structured more around efficient routing between sub-models than around accepting massive single-prompt inputs.
Long context expands the range of questions you can ask, while retrieval-augmented generation, which fetches relevant external data at query time, remains relevant when freshness and cost matter.
Alignment
Pre-training produces a base model that has processed enormous amounts of text and learned to predict the next token. At this stage, the base model behaves as a sophisticated pattern-completer with limited regard for honesty, safety, or helpfulness.
Post-training is the phase where this base model is shaped into the assistant that users interact with, and the three companies have taken substantially different approaches to this work.
OpenAI built on Reinforcement Learning from Human Feedback (RLHF) throughout the development of GPT-3 and GPT-4. The approach involves three main steps:
Human raters compare pairs of model outputs and select the better one.
Those comparisons train a reward model that captures human preferences.
The reward model is then used to fine-tune the language model toward outputs that humans prefer.
The GPT-4 product page describes an additional safety reward signal incorporated into RLHF to reduce harmful outputs. For the reasoning models, OpenAI added an approach called deliberative alignment, where the model reasons about safety policies at inference time. The publicly available Model Spec describes intended behavior in detail.
Anthropic developed an alternative method called Constitutional AI, or CAI. Instead of relying on human raters at every step, CAI uses an explicit written constitution and has the model critique and revise its own outputs against those principles, then applies AI-generated feedback to further refine the model. In January 2026, Anthropic published a 23,000-word constitution that shapes Claude’s training across synthetic data generation, response ranking, and behavioral refinement.
Google uses RLHF with learned reward models in its post-training pipeline for Gemini, with somewhat less explicit public framing than the other two companies. The Gemini technical reports describe a multi-phase training process moving from unimodal pre-training through multimodal alignment.
This architectural area also reflects a broader pattern of differing transparency choices across the three companies. The 2023 GPT-4 technical report deliberately omitted architecture details, while the 2025 GPT-5 system card describes a router, named sub-models, and safety mitigations in remarkable detail. Anthropic publishes its constitution publicly, providing a detailed view into the principles that shape Claude’s behavior. The three companies have made distinct choices about transparency, and those choices have evolved over time.
For users, these training differences appear as personality. Claude tends to push back more often on edge cases because the constitution explicitly trains for that behavior. ChatGPT is often quicker to attempt a task without questioning. Gemini’s responses vary more by domain.
See the diagram below:
With values addressed, the most recent architectural dimension concerns how the model thinks, an area where the three companies have converged from different directions.
Reasoning
The most recent and most consequential architectural development for the current generation of models concerns whether the model produces an answer directly or reasons explicitly through tokens before answering.
A standard chat model takes a prompt and immediately begins generating the response. A reasoning model first generates internal thinking tokens, working through the problem, and only afterward produces the final answer. The same prompt, the same underlying weights, and the same context window can produce very different inference-time compute profiles depending on which approach is used.
OpenAI built dedicated reasoning models, beginning with o1 in late 2024, followed by o3 in August 2025, and continued in GPT-5.5, which was released on April 23, 2026. The architecture includes three main components.
GPT-5-Main, a fast, high-throughput model and the successor to GPT-4o.
GPT-5-Thinking, a deeper reasoning model and the successor to o3.
A Real-Time Router that selects between them based on conversation type, complexity, tool needs, and explicit intent in the prompt.
OpenAI plans to integrate these capabilities into a single model in the future, though the current architecture functions as a system of models rather than as a unified single model.
Anthropic pursued a different approach. Claude Opus 4.8 and Sonnet 5 use adaptive thinking inside a single model, where the same Claude determines for itself how long to think on each request, with summarized reasoning surfaced to developers for inspection.
Google integrated thinking into Gemini 3 through Deep Think mode and the three-level thinking system in Gemini 3.1 Pro, enabling the model to reason over text, images, audio, and video in a single thinking pass.
For users, this architectural difference shows up more visibly than might be expected. ChatGPT can feel inconsistent across sessions because the router may have directed two similar prompts to two different sub-models. Claude tends to feel consistent because the same model varies its reasoning depth based on the request. Gemini’s behavior shifts more with domain and modality.
A convergence happens at this architectural fork. Three companies that began with very different choices at every prior dimension, including MoE versus dense architecture, native versus bolted-on multimodality, and RLHF versus Constitutional AI, have all arrived at the same approximate conclusion. Explicit reasoning tokens at inference time materially improve model performance on hard problems.
Conclusion
In this article, we looked at five architectural dimensions, each representing a question all three frontier developers had to answer when building their models.
Density: Google adopted Mixture of Experts openly, OpenAI built routed efficiency through a different mechanism, and Anthropic kept its architectural choice private.
Multimodality: Google adopted native fusion from inception, OpenAI evolved from bolted-on vision toward a unified architecture, and Anthropic maintained a text-first approach with strong vision capabilities.
Context: Google pushed the largest windows, Anthropic invested in long sessions with explicit handling of degradation, and OpenAI emphasized routing efficiency over raw window size.
Alignment: OpenAI’s RLHF combined with the Model Spec, Anthropic’s Constitutional AI combined with its published constitution, and Google’s RLHF approach represent three distinct shaping pipelines.
Reasoning: All three companies converged on explicit reasoning tokens, despite starting from different architectural choices at every prior dimension.
When we observe one of these models behaving in a particular way, we now have a framework for asking which architectural dimension produced that behavior.
References:
Model comparison content is useful but the frame is almost always wrong. The question isn't which model performs better on benchmarks — it's which model fails in ways that are harder to detect. Governance risk correlates with failure mode opacity, not with average performance. A model that's slightly worse but fails predictably is safer to deploy in high-stakes contexts than one that scores higher but fails in ways you can't anticipate or catch.
Any thoughts on perplexity?