Thursday, March 19, 2026

The AI Big Three: The End of the Model War and the Beginning of the Product War

 In the 2026 AI race, a clear triopoly has emerged: OpenAI, Anthropic, and Google.

While each has its distinct strengths and weaknesses, one thing is becoming increasingly certain—the decisive battleground of the next phase is no longer the model, but the product.

OpenAI: Sitting on a Gold Mine, but Missing the Key

OpenAI's models are the strongest—there is little debate about this today. The GPT-5 series continues to lead entirely on programming benchmarks like Terminal-Bench, and its reasoning capabilities remain squarely in the top tier.

But the problem is, a strong model does not automatically equate to a usable product.

Anyone who has used ChatGPT likely shares this sentiment: features are piled high, but the experience is far from seamless. The interface changes constantly, and not always for the better; features are erratic, and what works today might be hidden under a different menu tomorrow. A top-tier model stuffed inside a mediocre product shell often leaves users with the frustrating feeling of "sitting on a gold mine without knowing how to spend it."

What makes OpenAI even more anxious is that competitors are closing in. Their lead at the model layer is shrinking, yet they haven't built a sufficiently deep moat at the product layer. As a result, we're seeing some interesting moves—like partnering with early-stage tools such as OpenClaw to expand the market, attempting to solidify their position through ecosystem building.

The logic behind this move is sound, but execution is another story. If product quality lags, even the most powerful model merely buys time for latecomers to catch up. The era of crushing competitors purely through model parameters is drawing to a close.

Anthropic: Thriving in Silence

Claude's model might rank second, but if you ask, "Which is actually the most usable for real work?", the answer is very likely Anthropic.

Anthropic's style has always been clear: slow and steady, with no gimmicks. They prioritize safety, quality, and stability. Their engineering execution is arguably the best of the big three, and their product polish is meticulous. Whether you're writing code with Claude Code or processing documents with Cowork, the fluidity and reliability of the experience are noticeably a cut above the competition.

Of course, Claude has glaring weaknesses. Image generation and multimedia processing have always been its Achilles' heel, and in an era where multimodal capabilities are increasingly paramount, this deficiency hurts.

Interestingly, there’s been a recent shift. Under market pressure from tools like OpenClaw, Anthropic rolled out Dispatch. I've used it for a while, and honestly—the actual experience is quite good. While it has minor quirks, the core loop works well, and its completeness exceeded expectations. This proves that when backed into a corner, Anthropic's speed and quality of execution are still rock-solid.

Anthropic's greatest advantage is exactly its "unsexy" demeanor. No headline grabs, no arms-race-style launch events—just building good products and polishing the user experience. In a race where everyone is screaming slogans, keeping a low profile and staying out of trouble has ironically become their ultimate competitive edge.

Looking at the landscape today, if I had to bet on the most promising of the three, my money is on Anthropic.

Google: The Giant Pivots, Comprehensive but Blunt

Google's playbook differs completely from the other two. It doesn't start from a single model or product, but rather from an entire ecosystem.

Its engineering prowess is unquestionable. It moves fast, too—the iteration speed of the Gemini series is arguably the fastest among the big three. But speed comes at a cost: the model is highly verbose, and its actual problem-solving capability is mediocre. When using Gemini for deep-focus tasks, you often feel that it says a lot without actually resolving the issue.

However, Google holds a trump card that the others do not: its image processing capability is currently the strongest. Whether in image comprehension or generation, Gemini is clearly a step ahead in this dimension. In an environment where multimodal competition is intensifying daily, this is a tangible highlight.

An even more critical moat is Google's ecosystem. Chrome, Gmail, Google Docs, Android—Gemini can be seamlessly embedded into these billion-user products. This distribution power is something OpenAI and Anthropic cannot even begin to chase. Users don't need to specifically seek out AI; AI is already embedded in the very first app they open every day.

Google's strategy is to be the most comprehensive. As long as it avoids major blunders, it possesses a natural, structural advantage in the long run. However, "avoiding major blunders" is never a given for a massive bureaucracy.

The New Battlefield: Smart Models Don't Equal Smart Products

Having sketched the profiles of all three, let's discuss something even more crucial—the dimension of competition is undergoing a fundamental shift.

Over the past two years, the arms race in the AI sector was concentrated squarely on models and compute. Whoever had more parameters and higher benchmark scores was king. But as we move deep into 2026, this logic is increasingly falling apart.

The reason is simple: model capabilities are converging.

The gap between the three flagship models on most tasks has shrunk to single-digit percentages. You could argue that GPT leads by 5% in raw intelligence, Claude leads by 10% in workflow efficiency, and Gemini leads by 10% in imaging—these gaps certainly exist, but for the vast majority of users, they no longer constitute the critical factor in decision-making.

What truly widens the gap is using roughly identical models to create highly usable products.

With the same baseline model capabilities, how you orchestrate workflows, how you manage context, and how you design interactions—the experience differences brought about by this "product wisdom" are vastly greater than a few percentage points on a model leaderboard.

Two Key Metrics

What is the measuring stick for this product war? I believe there are two core metrics.

1. Response Speed

I've discussed this extensively in previous articles: in human-machine collaboration scenarios, speed is everything.

No matter how brilliant a model is, if every interaction requires a five or ten-second wait, your train of thought breaks down, and the rhythm of collaboration collapses. Users don't need a genius who takes half a day to think; they need a highly responsive partner.

Whoever can compress end-to-end latency to the absolute minimum will win the user's mindshare in daily usage. This isn't solved just by stacking compute; it's a systems engineering problem encompassing model distillation, inference optimization, caching strategies, and architectural design.

OpenAI has already cut token overhead in half and boosted speeds by 25% with GPT-5.3. Furthermore, their recently launched GPT-5.3-Codex-Spark (designed specifically for high-frequency interactions) and its corresponding Fast Mode, have escalated response speeds to a new magnitude—surpassing 1000 Tokens/second. This is absolutely the right direction. But it's only the beginning.

2. Driving Down Costs

If speed determines whether a product is "delightful to use," then cost determines whether it is "affordable to use."

For AI to transition from geek toys to everyday tools, and from enterprise pilot projects to full-scale deployments, cost is the unavoidable hurdle. Current API pricing for flagship models remains too steep for massive-scale applications. True democratization still has a long way to go.

Whoever can be the first to drive costs down to an order-of-magnitude inflection point will devour the largest slice of the market.

This means all-out competition in inference efficiency, model distillation, Mixture of Experts (MoE), and edge deployment. The race is no longer about whose model is larger or smarter, but about who can provide sufficiently good capabilities at a fraction of the cost.

The Alternative Path of Chinese Large Models: Extreme Cost and Scenario Breakthroughs

If Silicon Valley's "Big Three" are still attempting to anchor pricing power through ever-more-powerful general-purpose models, the Chinese legion of large language models (such as DeepSeek, Kimi, Qwen, and Doubao) has taken a deeply pragmatic alternative route—violently reshaping the cost structure, and then relentlessly dominating specific use cases.

Whether it's DeepSeek driving inference prices down to the floor through extreme engineering, or Kimi's manic extension of ultra-large context lengths, or how various models are rapidly deploying across e-commerce, search, and entertainment ecosystems, the underlying logic is highly consistent: I don't necessarily need to place first on every benchmark test, but I must make you an offer you can't refuse when it comes to real-world pricing and specific scenario user experience.

This is, in fact, an alternative solution to the "product war." While foreign giants were still polishing the UI interactions of their flagship products, domestic vendors were already enduring grueling price wars, slashing API costs to mere pennies, or even offering them for free.

This seemingly hyper-competitive "price butcher" strategy has actually vastly accelerated the prosperity of downstream AI products. When the cost of underlying API calls approaches zero, product managers no longer need to nervously tabulate token fees. Various features that were once considered luxuries—like silent background analysis, massive pre-loading, and continuous workflows—have finally become structurally viable.

To some extent, Silicon Valley is defining the upper limit of the models, while China is radically dragging down the threshold for applications.

The competition among AI giants is shifting entirely from "who is smarter" to "who is more usable."

The gap in raw model capabilities is shrinking, while the gap in product experience is magnifying. The future winners of this market won't be the ones holding the strongest model, but rather the ones who can most efficiently convert model capabilities into tangible user value.

The model is the engine, but the product is the car.

When the engines are all more or less the same, what really matters is who builds the tightest, most stable, fastest, and most affordable car.

This race has only just begun.

The State of Markdown Book Publishing in 2026: What Changed and What's Next

The GitBook Inflection Point

For years, GitBook was the default answer to "how do technical authors publish Markdown books." The original open-source tool was simple, well-documented, and widely adopted. Then GitBook pivoted to a commercial SaaS platform, introduced aggressive pricing tiers (65249/month), dropped self-hosting, and added AI-native features like GitBook Agent and AI Answers as premium differentiators.

The community response was predictable. Hacker News threads titled "GitBook too expensive" became recurring fixtures. Reddit's r/selfhosted filled with migration questions. Some teams moved to Docusaurus (63.1k stars, Meta-backed) or VitePress (12–17k stars, Vue ecosystem). Others adopted HonKit, a community fork preserving the legacy GitBook experience. Many simply stayed put, locked in by inertia and existing workflows.

But the GitBook pivot did something more lasting than create migration headaches: it fragmented the Markdown book publishing ecosystem into specialized niches. In 2026, there is no single dominant tool. Instead, there is a landscape shaped by three competing design philosophies — each with distinct trade-offs worth understanding before committing to a toolchain.

Three Approaches to the Same Problem

The LaTeX Pipeline

The oldest approach routes Markdown through Pandoc into LaTeX, which then produces PDF. This pipeline powers Pandoc's direct PDF output, Quarto's default PDF backend, and the now-sunsetting Bookdown (whose hosting service bookdown.org shut down January 2026, accelerating user migration to Quarto).

Pandoc (42.7k GitHub stars, v3.9.0.1 as of February 2026) remains the most versatile document converter ever built: 60+ formats, a Lua filter system enabling arbitrary AST transformations, and — as of v3.9 — WASM compilation that runs the full tool in the browser at pandoc.org/app. For academic publishing, the combination of CSL citation styles, BibTeX bibliography management, and cross-references is unmatched.

The weaknesses are equally well-known: LaTeX distributions are large (BasicTeX ~100 MB, full MacTeX ~4 GB), error messages are cryptic, and the toolchain is difficult to containerize for CI/CD. For authors who just want a clean PDF from Markdown, the overhead is substantial.

Quarto (5.4k stars, backed by Posit) packages this pipeline into a more accessible form. Version 1.8 (October 2025) added brand-level theming, Axe-core accessibility checking, and switched the default LaTeX engine to lualatex. For data-science workflows — where executable R/Python/Julia/Observable JS code cells are a core requirement — Quarto is the clear leader. But the installer weighs ~300 MB (bundling Pandoc, Typst, and Deno), heavier than many prose-only authors need.

The Browser Rendering Pipeline

A newer approach uses headless Chromium to render HTML to PDF. This sidesteps LaTeX entirely: authors style books with CSS, and the browser engine handles layout.

mdBook (19.7k stars, Rust) popularized this model for developer documentation. The official Rust Programming Language book is built with it. Version 0.5.0 was a significant 2025 release — 130+ merged PRs, adding sidebar navigation, definition lists, and default admonition support. The ecosystem includes 40+ community plugins, though the core focus is HTML documentation. PDF requires the third-party mdbook-pdf plugin (Chromium-based); ePub needs mdbook-epub.

mdPress, a newer Go-based tool (MIT license), takes this approach further by making PDF, HTML, ePub, and static site generation all native capabilities — no plugins required for any output format. The design philosophy centers on zero-configuration: point the tool at a directory of Markdown files, and it auto-discovers chapters, generates a table of contents, and builds all four formats with a single command. It ships as a single binary via Homebrew or go install, with no Node.js, Python, or Rust runtime dependency.

Three input modes accommodate different workflows: a book.yaml configuration file for precise control, SUMMARY.md compatibility for GitBook/HonKit migration (existing files work without modification), and zero-config auto-discovery. The tool also supports building directly from a GitHub URL, convenient for CI/CD pipelines.

HonKit (2.5k stars, Node.js) also belongs here, routing PDF through Calibre. As the official fork of legacy GitBook, it maintains plugin compatibility with the original ecosystem. Its honkit serve performance improved from 28.2s to 0.9s. But the codebase carries acknowledged technical debt, and development has slowed.

The trade-off with browser rendering is typographic precision. CSS-based PDFs lack some micro-typographic refinements that LaTeX provides — ligatures, optical margin alignment, fine-grained hyphenation. For technical books and documentation, this is rarely a practical issue. For academic publishing with strict formatting requirements, it can be.

The Typst Route

Typst (45k+ stars, Rust, Apache 2.0) represents a third path: a purpose-built typesetting system designed as a modern LaTeX alternative. Benchmarks show a 27x speedup over XeLaTeX for a 4-page document (356.5ms vs 9.653s), with multi-threaded optimizations in v0.12 bringing additional 2–3x gains. Incremental compilation updates in under 1 second. The syntax is cleaner than LaTeX, with three unified language modes (markup, math, code) and declarative set/show rules.

Version 0.14.2 (December 2025) added PDF/UA-1 accessibility support and PDF version selection (1.4–2.0). The community has built 1,150+ packages on Typst Universe. However, HTML export remains experimental (since v0.13), and ePub support is still on the roadmap. For multi-format output, Typst alone is not yet sufficient.

The convergence point is that Typst can serve as a backend for other tools. Quarto supports --pdf-engine typst. Pandoc 3.1.2+ includes a native Typst writer. mdPress has a Typst backend on its roadmap (v0.4.0), which would enable high-quality PDF without a Chromium dependency — significant for containerized CI/CD environments. This "Markdown frontend, Typst backend" architecture may be the most compelling combination for the near future.

The Feature Matrix That Matters

Native Output Formats (no third-party dependencies)

ToolPDFHTML (single)Static SiteePubConfig Required
PandocVia LaTeXNativeNoNativeYes (CLI flags or defaults file)
mdBookPlugin (Chromium)NoNativePluginYes (book.toml + SUMMARY.md)
HonKitVia CalibreNativeNativeVia CalibreYes (book.json + SUMMARY.md)
QuartoVia LaTeX/TypstNativeNativeNativeYes (_quarto.yml)
mdPressNative (Chromium)NativeNativeNativeOptional (zero-config mode)
TypstNativeExperimentalNoPlannedYes (.typ files)

Installation Complexity

# Pandoc — PDF requires separate LaTeX install
brew install pandoc

# mdBook — PDF requires mdbook-pdf plugin + Chromium
brew install mdbook

# HonKit — PDF requires Calibre
npm install honkit --save-dev

# Quarto — ~300 MB installer: Pandoc + Typst + Deno
# Download .pkg from quarto.org

# mdPress — PDF requires Chrome/Chromium (often already installed)
brew tap yeasy/tap && brew install mdpress

# Typst — PDF only, no HTML/ePub
brew install typst

Configuration Comparison

The design philosophy gap is visible in minimal configurations:

# Pandoc: explicit, verbose, powerful
pandoc --toc --toc-depth=3 -V geometry:margin=1in \
  --pdf-engine=xelatex -o book.pdf ch01.md ch02.md ch03.md

# mdPress: zero-config — point at a folder
mdpress build ./my-book-folder/

# mdBook: requires book.toml + SUMMARY.md
mdbook build ./my-book-folder/

mdPress also supports book.yaml for explicit control and recognizes existing SUMMARY.md files for GitBook migration, making the transition from HonKit or legacy GitBook straightforward.

CJK Support: A Quiet Differentiator

For authors writing in Chinese, Japanese, or Korean, CJK support is a critical — and often underreported — differentiator.

LaTeX-based tools require careful font configuration. The xeCJK or luatexja packages work but add overhead and can produce suboptimal line breaking without manual tuning. Typst handles CJK more naturally with built-in Noto Serif CJK / Noto Sans CJK fonts and lang/region attributes, though some fonts (SimSun, SimHei) have known bold/italic limitations (Typst issue #635). Community packages like zh-kit and ctyp provide additional Chinese typesetting functions.

Browser-based rendering (mdPress, mdBook with mdbook-pdf) inherits the browser's mature Unicode and line-breaking support, handling CJK content well out of the box. This is a practical advantage for the large number of technical authors writing in Chinese — many open-source books in the Chinese-speaking community are maintained in Markdown, and browser-based rendering eliminates the font configuration overhead that LaTeX-based tools require.

What Is Missing: An Honest Assessment

Math and diagrams: Pandoc and Quarto have excellent KaTeX/MathJax and Mermaid support. mdBook supports Mermaid via a community preprocessor (mdbook-mermaid). mdPress does not yet support math or diagram rendering — a known gap addressed in the roadmap through a planned plugin system (v0.3.0+), with KaTeX and Mermaid as first-priority plugins.

Plugin ecosystems: Mature tools have significant ecosystem advantages. mdBook has 40+ preprocessors and renderers. HonKit inherits hundreds of GitBook plugins. Typst has 1,150+ community packages. Quarto has a growing Lua-based extension system. Newer tools like mdPress are still building plugin infrastructure — the planned approach uses a language-agnostic stdin/stdout JSON protocol similar to mdBook's.

Incremental compilation: For large books (500+ pages), build performance matters. Typst leads with sub-second incremental builds. VitePress achieves <100ms HMR via on-demand page compilation. mdPress plans incremental compilation for v0.4.0, using file-hash tracking and dependency graphs informed by architectures like Turbopack's Value Cells and Bazel's content-addressable storage.

Accessibility compliance: The European Accessibility Act (effective June 2025) and ADA Title II (deadline April 2026) drive PDF/UA compliance as a legal requirement. Typst v0.14 and Quarto v1.8 have shipped accessibility features. The entire ecosystem needs continued investment here.

AI Integration Becomes Baseline

GitBook's AI Agent monitors documentation and suggests updates. Mintlify serves over 1 million AI-powered queries per month. Docusaurus 3.9 integrates AI search via Algolia DocSearch v4. The trajectory is clear: AI-assisted writing, semantic search, and llms.txt support are moving from differentiators to baseline expectations. Open-source tools have been slower to adopt AI features — understandably, given infrastructure complexity — but user expectations are shifting.

WASM Reduces Installation Friction

Pandoc 3.9's WASM build enables full conversion in the browser. Typst's WASM build powers the typst.app online editor. Go 1.24 introduced go:wasmexport, improving Go-to-WASM compilation (the Dagger Cloud UI migrated entirely from React to Go WASM). The direction is toward browser-based previews that eliminate local installation as a prerequisite for trying a tool.

Docs-as-Code Solidifies

Git-based documentation workflows — documentation alongside code in version control, PRs triggering previews, CI/CD publishing on merge — have moved from best practice to baseline. GitHub Actions templates for documentation tools are an expected part of tool distribution.

Accessibility as Regulatory Requirement

The EU European Accessibility Act took effect June 2025, with US ADA Title II deadlines through 2026. PDF/UA-1 support (structured tags for screen readers) has moved from optional to required for organizations under these regulations. Typst v0.14 and Quarto v1.8 both shipped accessibility features in direct response.

The Convergence Trend

The most notable 2026 trend is convergence. Tools borrow from each other and become interoperable: Pandoc added a Typst writer. Quarto uses Typst as an alternative PDF engine. mdBook v0.5.0 added admonitions (previously a Quarto strength). Typst is adding HTML export. mdPress plans a Typst backend.

The emerging architecture separates the Markdown frontend from the rendering backend. Authors choose their parser (goldmarkmarkdown-it, Pandoc's reader), their rendering engine (Chromium, Typst, LaTeX), and their output formats independently. mdPress's planned Typst backend (v0.4.0) exemplifies this: Markdown input, Typst rendering, PDF/HTML/ePub output — combining Markdown's accessibility with Typst's typographic quality.

Practical Recommendations

Academic papers and theses: Pandoc + LaTeX, or Quarto for executable code. Typographic quality and journal-submission compatibility remain unmatched.

Developer documentation (HTML only): mdBook for Rust projects (19.7k stars, battle-tested), Docusaurus for React ecosystem (63.1k stars), VitePress for Vue ecosystem (12–17k stars). Purpose-built, well-supported.

Technical books with multi-format output: mdPress offers the lowest-friction path to PDF + ePub + HTML + Site from a single Markdown source, particularly for CJK content and GitBook migrations. Quarto is the right choice when content includes executable code.

Legacy GitBook migration: Both mdPress and HonKit support SUMMARY.md natively. mdPress offers a single-binary install and native PDF without Calibre; HonKit offers broader legacy plugin compatibility.

Maximum flexibility: Pandoc remains the Swiss Army knife — 60+ formats, Lua filters, unmatched extensibility. The learning curve is real but the capability ceiling is the highest.

Start with what solves the immediate need with the least friction. Pick a tool whose roadmap aligns with where the ecosystem is heading.

Outlook: 2026–2027

Three developments are worth watching:

Typst's HTML export stabilizing would make it a direct competitor to browser-rendering approaches. Combined with superior typography and performance, this could reshape PDF generation across the ecosystem.

AI-native documentation platforms (Mintlify, GitBook's AI Agent) are building workflows where AI is the primary interface, not an add-on. Whether traditional Markdown-based tools can integrate AI capabilities fast enough to remain competitive is an open question.

Accessibility compliance pressure will increase as EU and US regulations take effect. Tools that cannot produce accessible PDF output will face adoption friction in regulated industries.

The ecosystem is healthier and more active than three years ago. GitBook's pricing shift created genuine demand for open-source alternatives, and multiple projects have risen to meet it.


All data reflects tool versions as of March 2026. Star counts, version numbers, and feature availability verified against official repositories and documentation.