DEV Community: Kendrick B. Jung

Codex Fast Mode vs Claude Fast Mode: What’s Actually Different?

Kendrick B. Jung — Tue, 31 Mar 2026 14:08:35 +0000

TL;DR

Both Codex and Claude support a fast mode, but the way they achieve speed is completely different. Codex has two tracks: either it serves the same GPT-5.4 model about 1.5× faster, or it runs a separate small model called Spark on Cerebras wafer-scale hardware at more than 1,000 tokens per second. Claude keeps the same Opus 4.6 model and speeds it up through infrastructure-level prioritization, with output speed improving by up to 2.5×. The tradeoffs around price, speed, and intelligence retention are subtle, and which option is better depends on your workflow.

What got me curious

Since I use both Codex and Claude Code, I already knew both sides offered a fast mode. But the pricing felt different, the speed felt different, and the user experience felt different. Sean Goedecke’s post, "Two different tricks for fast LLM inference," made it clear that the two companies were solving the problem in fundamentally different ways, so I started digging deeper.

Codex fast mode: really two different tracks

On the Codex side, there are actually two things that can reasonably be called fast.

The first is GPT-5.4 fast mode. It serves the same GPT-5.4 model about 1.5× faster while consuming 2× the credits. Since the model itself does not change, there is no intelligence drop. In the CLI, it is just a simple /fast on toggle.

Nathan Lambert noted that even when using GPT-5.4 fast mode with xhigh reasoning effort, he had never hit the Codex limit, while Claude could still hit limits sometimes. Whether that comes from better token efficiency or looser limits on OpenAI’s side, it does feel noticeably roomier in practice.

The second is GPT-5.3-Codex-Spark, which is a separate model entirely. This is the truly ultra-fast path, running on Cerebras WSE-3 (Wafer-Scale Engine 3) hardware. It can generate more than 1,000 tokens per second. Right now, it is available as a research preview for ChatGPT Pro subscribers.

Cerebras WSE-3: a different world from GPUs

Cerebras WSE-3 is fundamentally different from a conventional GPU. NVIDIA’s flagship B200 is around 208 billion transistors, while the Cerebras chip packs 4 trillion transistors across roughly 900,000 cores on a single silicon wafer. The core advantage is memory bandwidth: up to 27 petabytes per second on chip. Since memory bandwidth is one of the real bottlenecks in LLM inference, Cerebras is attacking that bottleneck directly at the hardware level.

That said, WSE-3 only has 44GB of on-chip memory, so it is difficult to place a very large model like GPT-5.3-Codex on it wholesale. That is why Spark is a smaller model. In real use, some people say it still carries that familiar "small model smell," especially when tool calls get messy.

OpenAI and Cerebras have also announced a multi-year partnership worth up to $10B, including plans for a 750MW data center. The longer-term direction seems clear: Spark is likely just the beginning of putting bigger frontier models onto Cerebras hardware.

OpenAI also shared infrastructure-level optimizations around Spark. By introducing persistent WebSocket connections and optimizing the Responses API internals, they say they reduced client-server roundtrip overhead by 80%, token overhead by 30%, and TTFT by 50%. So the speedup is not only about the model itself. It is also about tightening the whole pipeline.

Claude fast mode: same model, different infrastructure

Claude’s approach is much simpler. The Opus 4.6 model stays exactly the same. If you set speed: "fast" in the API, Anthropic prioritizes the request at the infrastructure layer. According to the official docs, output token speed can improve by up to 2.5×. The focus is on output throughput rather than TTFT.

Anthropic has not publicly disclosed the full implementation details, but the likely explanation is something like lower-batch-size inference with more dedicated GPU allocation. Smaller batches are less efficient for GPU utilization, but they improve response speed for individual requests. That inefficiency is then covered by the 6× premium pricing.

In Claude Code, fast mode is toggled with /fast, and it requires version 2.1.36 or later. When enabled, it automatically switches to Opus 4.6 and shows a ↯ icon next to the prompt.

One important detail is that fast mode usage is not included in the normal subscription usage bucket. It is billed as extra usage. Pricing kicks in from the very first token, so cost management matters.

Fast mode and effort level are also completely different axes. If you lower effort, the model simply spends less time reasoning and quality may drop. Fast mode, by contrast, serves the same reasoning process faster at the infrastructure level. You can combine them: fast mode plus lower effort for simpler tasks, fast mode plus higher effort for more complex ones.

The core difference

The most important distinctions look like this:

Codex GPT-5.4 fast mode: about 1.5× speed, 2× credits, same model
Codex Spark: 15×+ speed, separate ultra-fast smaller model
Claude fast mode: up to 2.5× speed, 6× price, same Opus 4.6 model

Sean Goedecke captures the difference well. Anthropic is still serving the actual Opus 4.6 model, while OpenAI’s Spark path uses a separate lower-capability model. In terms of raw speed, Spark is dramatically faster. In terms of quality retention, Claude has the stronger position.

There is also a broader point here: the value of an AI agent is often determined less by raw speed and more by how rarely it makes mistakes. If something is 6× faster but increases mistakes by 20%, that can easily be a net loss, because fixing those mistakes may take much longer than waiting for the model.

So if you compare same-model fast modes only, Claude offers a bigger speed bump than Codex, but it is also much more expensive. If you include Spark, OpenAI has the more extreme speed story, but you have to remember it is not the same model.

What about speculative decoding?

Early in my research, I came across claims that Codex fast mode used speculative decoding. That does not seem accurate. Speculative decoding itself is a real and widely used inference optimization technique, but I could not find official confirmation that Codex fast mode specifically uses it.

The idea behind speculative decoding is elegant. A small draft model predicts upcoming tokens first, and then the larger main model verifies them in a single pass. Google published work on this in 2022 and later discussed using it in products like AI Overviews, where it can deliver 2–3× speedups while preserving the same output distribution.

For Codex Spark, though, the main speed story seems much more tied to the hardware characteristics of Cerebras itself. The model benefits from staying close to on-chip SRAM and avoiding the usual memory bandwidth bottlenecks. It is possible that speculative decoding is also used somewhere internally, but there is no official confirmation.

Closing thoughts

Peter Steinberger is one of the most fascinating examples of where this kind of workflow can go. He reportedly runs four OpenAI subscriptions and one Anthropic subscription, spends around $1,000 per month, runs 3–8 Codex CLI sessions in a 3×3 terminal grid, and can hit 600 commits in a day. That is a completely different scale. By his own estimate, API usage would cost about 10× more, so running multiple subscriptions is actually the more rational option. More recently, he has even joined OpenAI.

What is especially interesting is that Peter used to be a serious Claude Code power user but gradually shifted toward Codex. His reason was surprisingly relatable: Claude Code kept saying things like "absolutely right" and "100% production ready" even when tests were failing, and he found that unbearable. Codex, by contrast, felt more like an introverted engineer quietly doing the work. He also said Codex tends to read far more code before starting, which lets it infer intent well even from short prompts. Eventually he canceled additional Anthropic subscriptions and made Codex his main driver, even though he still uses Claude in a smaller role.

Whether I am on Claude Max or Codex Pro, I usually cannot even consume the full weekly quota. But people like that are running five subscriptions at once. If you listen to AI podcasts, there are quite a few people using even more. A while ago I had to force myself to adapt to a kind of parallel-project brain just to burn through huge amounts of tokens, and it was honestly exhausting. Now I do not really get the headache anymore. Instead, I get stuck wondering what else I could even do with all this capacity. That is how one project leads to another, and another task appears from there.

In the end, running several projects at once becomes a kind of refresh loop. If I look away from one blocked project for a while and work on another, ideas tend to come back. Peter described it as doing one thing while another is "cooking," then switching again while that one cooks too. My scale is obviously smaller, but I recognize the pattern.

Refs

Using git worktree for parallel AI agent development

Kendrick B. Jung — Tue, 24 Mar 2026 12:45:18 +0000

TL;DR

If you want to run multiple AI coding agents in parallel, git worktree is the answer. It gives each branch its own working directory inside the same repository, so you do not need stash gymnastics or multiple clones.

What is Git Worktree?

Even if you are juggling several tasks, a human developer can still only work in one context at a time. The old pattern was to stash your current changes, check out another branch, do some work there, and then come back and pop the stash later.

git worktree changes that entire flow. It lets one Git repository have multiple working directories attached to it. Normally, a repository has a single working tree. With worktree, you can keep the same .git history and object database while checking out different branches into separate folders.

The structure looks like this:

/projects/
├── my-app/                 ← main worktree (main branch)
│   └── .git/               ← real git data
├── my-app-feature/         ← linked worktree (feature/auth branch)
│   └── .git                ← not a directory, but a file pointing to the main .git
└── my-app-hotfix/          ← linked worktree (hotfix/login branch)
    └── .git

Each worktree has its own HEAD, index, and working files, but they all share commit history and Git objects. In terms of Git objects, extra disk usage is minimal. But dependencies like node_modules or .venv still need to exist per worktree, so heavy projects can consume disk space quickly if you keep many worktrees around.

There is also one important limitation: you cannot check out the same branch in two worktrees at once. This is intentional. It prevents the confusion of having the same branch diverge across multiple active directories.

When did it arrive?

git worktree officially landed with Git 2.5 on July 29, 2015. A major contributor was Nguyễn Thái Ngọc Duy, who had been refining the idea for years. At launch it still wore an experimental label and had some submodule compatibility issues, but those rough edges have largely been resolved over time.

Later releases added more lifecycle commands. Git 2.7 brought git worktree move and git worktree remove, and Git 2.15 introduced git worktree lock and git worktree unlock.

I only started paying real attention to it recently, but clearly many people had already been quietly using it for years. It spent nearly a decade as one of those “great if you know it” features. Once AI coding agents became normal, though, it suddenly started feeling essential.

Harness engineering: why worktree matters

Harness engineering is not about building the AI agent itself. It is about designing and orchestrating the environment you delegate work into. git worktree becomes incredibly powerful once that environment exists.

Agents like Claude Code and Codex read and write files directly in the working directory. If an agent is working on the feature/payments branch, that directory may be sitting in a half-modified state at any moment.

What happens if you check out another branch in that same directory, or launch a second agent into it? Best case, you create confusion. Worst case, you end up with conflicting file states and agents working from the wrong code snapshot.

The old solution was git stash, but once several stashes pile up, it becomes annoying to remember which one belongs to which task. Cloning the repository multiple times also works, but now you are duplicating repo state and losing the convenience of sharing local history and objects directly.

git worktree solves this cleanly. Each AI session gets a fully independent directory tied to its own branch, while history and objects remain shared. Claude Code made this even more explicit by adding an official --worktree flag in February 2026, effectively promoting this workflow to a first-class citizen.

Starting a worktree-based workflow

The basic commands are simple:

# Create a new worktree with a new branch
git worktree add ../my-app-feature -b feature/auth

# Create a worktree from an existing branch
git worktree add ../my-app-hotfix hotfix/login

# List all attached worktrees
git worktree list

There are two common directory layouts. The first puts worktrees next to the main project:

/projects/
├── my-app/
├── my-app-feature-auth/
└── my-app-hotfix-login/

The second keeps them inside the project under a trees/ folder:

/my-app/
├── src/
├── .git/
└── trees/
    ├── feature-auth/
    └── hotfix-login/

If you use the second pattern, do not forget to add trees/ to .gitignore. Otherwise the main worktree will see them as untracked files.

There is one more thing to handle when creating worktrees. Files ignored by Git, such as .env, are not copied automatically. A plain cp works, but then you need to repeat that every time the main .env changes. A symlink is often more convenient because updates in the main worktree are reflected everywhere:

# Create worktree, then link .env
git worktree add trees/feature-auth -b feature/auth
ln -s "$(pwd)/.env" trees/feature-auth/.env

If you have multiple environment files like .env.local and .env.development, it helps to wrap this in a shell function:

# ~/.zshrc or ~/.bashrc
wt() {
  git worktree add "$1" -b "$2"
  for f in .env .env.local .env.development; do
    [ -f "$f" ] && ln -s "$(pwd)/$f" "$1/$f" && echo "linked $f"
  done
}

# Usage
wt trees/feature-auth feature/auth

If you use Claude Code, the official --worktree flag makes the flow even simpler:

# Create a worktree and start Claude Code in one step
claude --worktree feature-auth

That single command creates .claude/worktrees/feature-auth/, creates the branch, and starts the Claude session inside it.

Working inside a worktree

Once the worktree exists, you just move into that directory and work as usual. IDEs and editors can also open each worktree as a separate project.

With AI agents, it looks like this:

# Terminal 1 - feature work
cd ../my-app-feature-auth
claude # or codex, gemini-cli, etc.

# Terminal 2 - hotfix work, at the same time
cd ../my-app-hotfix-login
claude

While one agent is working, you can review the output from another. You stop being the person waiting for code and start being the person directing parallel work.

Commits inside each worktree work exactly the same as usual. Since the branch is already separated, you do not have to think much about context switching.

git add .
git commit -m "feat: add auth middleware"

After the work is done

Once the task is finished, the rest looks like a normal PR workflow. If you are already inside the worktree directory, push naturally goes to that branch:

cd ../my-app-feature-auth
git push -u origin feature/auth
gh pr create --title "Add auth middleware" --base main

After opening the PR, there are three common ways to integrate the branch back into the main worktree.

Squash merge — usually the cleanest for AI-generated work

Inside the worktree, the agent may have made several exploratory commits. Those process commits usually do not need to live forever in main history. Squash merge compresses everything into one clean commit. On GitHub you can choose “Squash and merge”, or in the CLI:

git merge --squash feature/auth
git commit -m "feat: add auth middleware"

Rebase merge — when you want perfectly linear history

This rebases the worktree branch on top of main and then fast-forwards it in. It is useful when the commits are already clean and meaningful on their own:

# Inside the worktree (or use master instead of main if needed)
git rebase main

# Back in the main worktree
git checkout main
git merge feature/auth --ff-only

Merge commit — when you want to preserve branch history

This creates an explicit merge commit, leaving a visible record that feature/auth was integrated at that point in time. It is useful for larger work units or when branch-level traceability matters:

git checkout main
git merge feature/auth

For many small tasks handled by AI through harness engineering, squash merge tends to fit best. There is usually no reason to keep all the intermediate trial commits. From the perspective of the main worktree, one clean commit that says “this feature was added” is often enough.

Once the merge is done, clean up the worktree.

Removing a worktree

# Remove the worktree
git worktree remove ../my-app-feature-auth

# Delete the branch too
git branch -d feature/auth

# Clean up stale worktree metadata
git worktree prune

If the worktree was created through Claude Code’s --worktree option, it will automatically delete the worktree and branch when the session ends with no changes. If commits exist, Claude asks whether to keep them.

Things to watch out for

Do not parallelize tasks that edit the same files unless you are prepared to handle merge conflicts later. Worktree does not magically solve overlapping changes. If two agents touch the same file, the merge conflict still exists. You still need to split work along sane boundaries.

Servers using the same port will also collide. If you run multiple dev servers from multiple worktrees at once, make sure they use different ports or only run one at a time.

It is also worth running git worktree prune periodically. If you manually delete directories, stale worktree metadata can linger and clutter the list. git worktree prune cleans those invalid references up.

Closing thoughts

git worktree first appeared in 2015, but this may be the exact era it was waiting for. Once AI coding agents become a normal part of development, running multiple isolated workspaces in parallel stops being a niche trick and starts feeling like the default.

Instead of repeatedly stashing and checking out branches, you can switch context just by changing directories. That is why git worktree feels less like a neat Git feature now, and more like core infrastructure for parallel AI-assisted development.

Refs

fractional-indexing: Implementing Drag-and-Drop Ordering and Avoiding Index Collisions

Kendrick B. Jung — Mon, 23 Mar 2026 12:46:47 +0000

Avoiding index collisions in sortable lists

The limits of integer indices

If you have ever built a drag-and-drop list, you have probably stored the order like this.

[
  { "id": "a", "order": 1 },
  { "id": "b", "order": 2 },
  { "id": "c", "order": 3 }
]

What happens if you move b to the front? b becomes 0, and a is still 1, so at first glance it seems fine. But if you later want to insert a new item between a and b, you have to shift a to 2 and c to 3. In other words, changing one item often forces you to update several others too.

In collaborative tools where multiple users can reorder items at the same time, that structure tends to create collisions. If two people modify the same part of the list concurrently, the final order can become inconsistent or trigger large update conflicts.

What is fractional-indexing?

David Greenspan introduced this approach in Implementing Fractional Indexing. The core idea is simple: instead of using integers for order, use sortable string keys.

[
  { "id": "a", "order": "a0" },
  { "id": "b", "order": "a1" },
  { "id": "c", "order": "a2" }
]

Want to insert an item between a1 and a2? You can generate a middle key like a1V. Everything else stays unchanged.

Figma uses this idea in its multiplayer editing system. It manages child-node ordering with fractional indexing, which means reordering typically updates only the moved node.

Using the library

In JavaScript, you can use the fractional-indexing package.

npm install fractional-indexing

import { generateKeyBetween, generateNKeysBetween } from 'fractional-indexing';

// First key
const first = generateKeyBetween(null, null);
// → 'a0'

// Insert at the beginning
const zeroth = generateKeyBetween(null, first);
// → 'Zz'

// Insert at the end
const second = generateKeyBetween(first, null);
// → 'a1'

// Generate a key between two existing keys
const third = generateKeyBetween(second, null); // 'a2'
const mid = generateKeyBetween(second, third);
// → 'a1V'

// Generate multiple keys at once
const keys = generateNKeysBetween('a0', 'a2', 2);
// → ['a0G', 'a0V']

You store the key as a string in the database and sort it with lexicographic order using ORDER BY. The scheme is designed so alphabetical order matches the intended item order.

Other ways to manage ordering

fractional-indexing is not the only option. There are a few common alternatives, and each comes with tradeoffs.

Gap strategy with integers

This is the simplest approach. You start with generous spacing.

[
  { "id": "a", "order": 1000 },
  { "id": "b", "order": 2000 },
  { "id": "c", "order": 3000 }
]

To insert between a and b, you assign order: 1500. It is simple and fast. The downside is that once the gaps are exhausted, you eventually need to reindex everything. If inserts keep happening in the same region, you end up with values like 1500 → 1250 → 1375 → ..., and a full rebalance becomes unavoidable.

Timestamp-based ordering

Another approach is to use insertion time as the order value.

const item = {
  id: 'a',
  order: Date.now(), // 1700000001000
};

This is the easiest implementation. The problem is that if two clients insert at nearly the same time, ordering becomes ambiguous. For a single-user app, that may be fine. In collaborative environments, it is usually not reliable enough.

Linked list ordering

In this model, each item points to the next item.

[
  { "id": "a", "next": "b" },
  { "id": "b", "next": "c" },
  { "id": "c", "next": null }
]

The nice part is that insertion only touches nearby nodes, so the update scope stays small. The downside is that reading the full order requires traversal, and you lose the convenience of a simple database ORDER BY. If your service reads ordered lists frequently, query complexity can become a real cost.

How to choose

Approach	Implementation complexity	Collaboration safety	Long-term operation
fractional-indexing	Medium	High	Rebalancing needed
linked list	Medium	Medium	More complex queries
integer gaps	Low	Low	Reindexing needed
timestamps	Low	Low	Collision risk

If your product involves frequent reordering or multiple users interacting with the same list, fractional-indexing is close to a practical default. For simpler single-user apps, a gap strategy with integers can still be perfectly sufficient.

Things to watch out for

Keys can grow longer over time. If you keep generating new keys inside the same narrow interval, the string length increases. That is why long-running systems often need a rebalancing step that periodically rewrites the ordering keys.

Another important detail is consistency in string comparison. Your database, server, and client should all treat ordering the same way. If different layers compare keys differently, the rendered order can drift from the intended one.

Closing thoughts

If you manage ordering with plain integers, you eventually run into friction. fractional-indexing is a fairly elegant way to avoid that problem. It is especially worth considering when you need realtime collaboration, optimistic updates, or frequent drag-and-drop reordering.

Refs

Why AI Gives You a Headache: Managing Cognitive Fatigue for Developers

Kendrick B. Jung — Wed, 18 Feb 2026 20:17:02 +0000

A New Kind of Fatigue in the AI Era

Recently, I've been subscribing to Claude Code Max, Codex (ChatGPT Pro), and Antigravity (Google AI Pro), which has dramatically increased my workload. At some point, I started getting headaches. I wondered if it was from lack of sleep, but our CTO at work asked if I was getting headaches. And the thing is, I had actually taken Tylenol the day before. So I thought that might be it, but after talking to others who use AI heavily, they said they occasionally get headaches too. So I decided to investigate. It turns out I'm not alone. Community posts asking "Does anyone get headaches when using AI? Planning and directing takes so much brainpower" are becoming common.

A 2025 academic study also found that deeper engagement with GenAI doesn't reduce cognitive burden—it actually amplifies it.

Why AI Exhausts Your Brain

Decision Fatigue Explosion

In traditional development, you'd spend a day diving deep into one design problem. Implementation took time, giving you the luxury of slowly making architectural decisions. AI flips this dynamic. When you can prototype three approaches in the time it previously took to build one, you must constantly make architecture-level decisions. The bottleneck shifts from "can we build this?" to "should we build this, and how?"

Continuous Task Initiation Burden

AI doesn't move on its own. "Remove this," "redo it," "change direction"—you must constantly direct the next action. This process intensely consumes your brain's executive function, a high-intensity cognitive task.

Prompt Fatigue

A 2025 study of 832 GenAI users found that uncertainty about how to write prompts causes emotional fatigue, while unexpected responses cause cognitive fatigue. The process of choosing words and designing context to get desired results consumes a new type of energy.

Context Switching Costs

Prompt writing → result review → revision instruction → re-review. This loop repeats dozens or hundreds of times daily. While AI doesn't tire from context switching, the human brain pays a transition cost each time it changes modes.

Practical Solutions That Work

The 20-20-20 Rule

Every 20 minutes, look at something 20 feet (6m) away for 20 seconds. Proposed by ophthalmologist Dr. Anshel in the 1990s, this rule is recommended by both the American Optometric Association (AOA) and the American Academy of Ophthalmology (AAO). Research shows that applying this rule for 2 weeks significantly reduces digital eye strain symptoms.

I happen to have a view of the Mississauga skyline from my place, so every 20 minutes I look out at the open landscape for 20 seconds. Having a distant view to rest your eyes on makes practicing this rule much easier than trying to focus on a wall or nearby objects.

Batch Prompting

Instead of continuously micro-directing, give broad guidelines once, let AI draft the solution, then review the results in batches. This reduces the number of brain transitions. For example, tools like oh-my-claudecode's autopilot or ralplan's autonomous execution modes let you review outputs without directing every step.

Intentional Downtime

After 50 minutes of focus, you need 10 minutes away from screens entirely. This allows your brain's Default Mode Network (DMN) to activate, consolidating and organizing information—a completely different brain activity from continuously reading and judging AI outputs.

Posture and Environment Check

An easily overlooked aspect. When concentrating on AI conversations, you may unconsciously tense your neck and shoulders, leading to tension headaches. Simply positioning your monitor at eye level and maintaining at least 63cm (arm's length) from the screen makes a noticeable difference.

The Key: Not "Use Less" but "Use Differently"

The solution to AI fatigue isn't to use AI less. The key is using it with boundaries, intention, and awareness that you're not a machine.

Acknowledging that productivity gains come with increased cognitive costs, and managing those costs, has become the new essential skill for developers in the AI era.

Refs

Siddhant Khare, "AI fatigue is real and nobody talks about it" (2025) — siddhantkhare.com
WarpedVisions, "The hidden cost of AI-assisted development: cognitive fatigue" (2025) — warpedvisions.org
ScienceDirect, "Fatigued by uncertainties: Exploring the cognitive and emotional costs of generative AI usage" (2025) — sciencedirect.com
MDPI, "Generative AI and Cognitive Challenges in Research" (2025) — mdpi.com
Human Clarity Institute, "Cognitive Load, Fatigue & Decision Offloading 2025 Data Summary" — humanclarityinstitute.com
Healthline, "20-20-20 Rule: Does It Help Prevent Digital Eyestrain?" (2025) — healthline.com
ScienceDirect, "The effects of breaks on digital eye strain, dry eye and binocular vision: Testing the 20-20-20 rule" (2022) — sciencedirect.com