DEV Community: Bhavya Arora

The 15 Git Commands That'll Save Your Sanity (and Your Code)

Bhavya Arora — Wed, 02 Sep 2026 07:31:06 +0000

Most developers don't learn Git by reading the manual. They learn it the first time they delete something important, commit the wrong files, or discover that the branch they thought they were working on was not the branch they were actually working on.

That is not necessarily a bad way to learn. Git becomes much easier once you've seen what these commands are trying to protect you from.

The problem is that Git has accumulated a reputation for being complicated because there are dozens of commands, countless flags, and a lot of terminology that makes perfect sense once you already understand Git. When you're new to it, though, add, commit, push, pull, reset, restore, and revert can look like variations of the same thing.

They aren't.

This guide focuses on the commands you'll actually use in day-to-day development and, more importantly, the situations that tell you which one to reach for. You don't need to memorize every Git flag to be productive. You need a good mental model, a handful of reliable commands, and enough understanding to avoid turning a small mistake into a much bigger one.

The Git Mental Model

Before getting into the commands, it helps to understand the four places your code can exist during normal Git work.

Your working tree is where you actually edit files. The staging area is where you decide which of those changes belong in your next commit. A commit records that staged state in your local repository. The remote repository — often hosted on GitHub, GitLab, or another server — is where you share those commits with other people or systems.

Most of the Git commands in this article are really just ways of inspecting, moving, combining, or undoing changes between those states.

Once that clicks, Git stops feeling like a collection of unrelated commands.

1. `git init`

When you're starting a project from scratch and want Git to track its history, you create a repository with git init.

git init

Git creates a hidden .git directory inside the project. That directory is where Git keeps the information it needs to manage the repository: commits, references, configuration, and the other internal data that makes version control possible.

It is worth separating two ideas here because beginners often conflate them. Running git init creates the repository; it does not automatically add every file in the directory to version control. Your files are still untracked until you stage them.

A typical first setup therefore looks like this:

git init
git add .
git commit -m "Initial commit"

You can also ask Git to create the project directory for you:

git init my-new-project

You generally only need to initialize a repository once. When you're not sure whether you're already inside one, git status is a safer check than running git init again.

2. `git clone`

git clone is the starting point for an existing project. Instead of creating a new repository, you're making a local copy of one that already exists somewhere else.

git clone https://github.com/username/repository.git

A normal clone gives you the project's files and repository history and sets up information about the remote repository so you can fetch and push changes later. It is the command you'll usually run when joining a team, contributing to an open-source project, or moving an existing repository onto a new machine.

Git normally creates a directory based on the repository name, but you can choose your own:

git clone https://github.com/username/repository.git my-project

There is one practical consideration worth knowing about. A repository with ten years of commits can be considerably larger than the current source code suggests, because you're bringing historical data along with it. When you only need a limited amount of history, a shallow clone can be useful:

git clone --depth 1 https://github.com/username/repository.git

That gives you a much smaller starting point, although it also means you don't have the complete history available locally.

The simple rule is:

Use init when you're creating the repository. Use clone when the repository already exists.

3. `git status`

If there is one Git command worth learning so well that you stop thinking about it, it is git status.

git status

When you're not sure what Git thinks is happening, ask Git. The command shows your current branch and tells you about changes that are modified, staged, or untracked.

A simplified example might look like this:

On branch main

Changes not staged for commit:
        modified:   index.html

Untracked files:
        style.css

In this case, index.html is already part of the repository but has local changes that haven't been staged. style.css is a new file that Git isn't tracking yet.

git status is deliberately boring, and that's exactly why it is useful. It doesn't change your files or history. Run it before you commit. Run it when you've just pulled someone else's changes. Run it before a reset. Run it after you've been switching branches and can no longer remember what you were doing.

When Git starts feeling confusing, don't guess. Start with git status.

4. `git add`

The staging area is one of Git's most useful ideas, and also one of the first things beginners find strange.

Suppose you've changed three files, but only two of those changes belong in the next commit. Git gives you the option to decide exactly what gets recorded.

That's what git add does.

git add filename.txt

You can stage everything below the current directory:

git add .

or stage matching files:

git add *.css

Think of staging as preparing a package before you send it. Your working tree can contain many changes, but only the staged changes are going into the next commit.

That distinction becomes particularly useful when you're doing unrelated work in the same project. You don't have to create a giant commit simply because several files happen to be modified at once.

One caution: git add . is convenient, but convenience can hide mistakes. It may stage files you didn't intend to include, which is why .gitignore should be set up early for things such as dependency directories, local environment files, generated output, and operating-system clutter.

5. `git commit`

A commit is a recorded snapshot of the changes you've staged.

git commit -m "Add user authentication"

This is the point where your work becomes part of the repository's history. You can compare it later, inspect it, revert it, or use it as a known point to return to.

That makes commit quality matter more than many beginners realize. A repository filled with messages like changes, fix, and final technically works, but it is much harder to understand months later.

Compare:

Fix bug

with:

Fix null pointer when cart is empty

The second message tells the next person — often future you — what the commit was actually about.

There is also a shortcut worth knowing:

git commit -am "Fix navbar spacing on mobile"

The -a option stages modifications and deletions to files Git already tracks, then creates the commit. It does not include new files, so a brand-new file still needs git add first.

And when the latest commit is almost right but not quite, --amend lets you update it:

git commit --amend -m "Add user authentication and tests"

Amending is handy while a commit is still local. Once you've pushed it and other people may have based work on it, rewriting that commit becomes a different conversation.

6. `git branch`

Branches are how you isolate work without putting unfinished changes directly onto the branch other people may be using.

git branch

lists your local branches.

To create one:

git branch new-feature

To delete a branch that has already been safely merged:

git branch -d old-feature

And when you know you want to remove it regardless of whether Git considers it merged:

git branch -D old-feature

You can rename a branch with:

git branch -m new-name

A useful thing to understand is that a branch isn't a separate copy of your entire project. It is essentially a movable reference to a commit, which is why creating branches is cheap.

There is one beginner mistake worth remembering: git branch new-feature creates the branch, but it does not switch you to it. To create and move to a branch in one step, modern Git gives you:

git switch -c new-feature

That leads naturally to the next command family.

7. `git checkout`, `git switch`, and `git restore`

For years, git checkout handled several unrelated jobs. You could use it to switch branches, create a branch, or restore a file to an earlier state.

git checkout new-feature
git checkout -b another-feature
git checkout -- filename.txt

The command still works, and you will continue to encounter it in older documentation and existing projects. The problem is that one command having several very different meanings makes it harder for beginners to understand what is happening.

Modern Git separates those operations.

Use git switch when you're working with branches:

git switch new-feature
git switch -c another-feature
git switch -

The last form switches back to the branch you were previously on, which is surprisingly useful when you're jumping between two tasks.

Use git restore when you're working with files:

git restore filename.txt

That discards unstaged changes to the file.

To remove a file from the staging area without throwing away its edits:

git restore --staged filename.txt

So the simplest mental model is:

git switch   → branches
git restore  → files
git checkout → older multi-purpose command

You don't need to treat checkout as obsolete. Just recognize that switch and restore make your intention clearer when you're writing new commands.

8. `git merge`

Eventually, isolated work needs to come back together. That's what merging does.

For example:

git switch main
git merge new-feature

If Git can reconcile the two histories automatically, the merge may be uneventful. When it can't, you'll get a conflict.

A conflict usually means that both sides changed overlapping parts of a file, or made changes Git cannot safely combine on its own. The repository hasn't been corrupted; Git has simply reached a decision that requires a human.

You'll see something like:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> new-feature

Open the file, decide what the final version should actually be, remove the conflict markers, and then stage the resolved file:

git add filename.txt
git commit

The first few merge conflicts can feel alarming because the file suddenly contains strange markers and Git seems to stop in the middle of the operation. In practice, conflict resolution is a normal part of collaborative development. The important thing is to understand that Git is waiting for a decision, not reporting a fatal failure.

9. `git push`

Your commits are local until you send them somewhere shared.

git push origin main

That command pushes your local commits to the main branch on the origin remote.

When you create a new branch and push it for the first time, you will often use:

git push -u origin new-feature

The -u option establishes the upstream relationship between your local branch and the remote branch. After that, a plain:

git push

is usually enough.

Force-pushing is where things get serious.

git push --force

can replace remote history, including commits you weren't aware another developer had added. There are legitimate reasons to rewrite history, particularly on personal branches after an amend or rebase, but it should never be a reflex.

When a force-push is genuinely necessary, this is generally safer:

git push --force-with-lease

It checks that the remote branch is still in the state your local repository expects. If someone else has moved it since your last update, the push can be rejected instead of silently overwriting their work.

Even with that protection, shared branches deserve caution.

10. `git pull`

git pull is the command you use when the remote repository has changes you need to bring into your current branch.

git pull origin main

Conceptually, the operation starts by fetching updates from the remote and then integrating the relevant remote branch into your current branch. Exactly how that integration happens depends on your configuration and options.

A common alternative is rebasing:

git pull --rebase origin main

Instead of creating a merge as part of the pull, Git replays your local commits on top of the updated remote history. That can produce a cleaner, more linear history, but rebasing also rewrites the commits being replayed.

Neither workflow is universally right. Some teams merge, some rebase, and some use stricter fast-forward policies. The important thing is consistency: know what your project expects before changing the default behavior.

For example:

git config pull.rebase true

can make rebase the default for the relevant configuration scope.

One subtle point is worth remembering: git pull origin main does not necessarily mean “update my local main branch.” It integrates origin/main into whichever branch you're currently on. That distinction matters when you're working on a feature branch.

11. `git log`

Every Git repository eventually reaches the point where you need to know not just what the code looks like now, but how it got there.

That's what git log is for.

git log

The default output contains commit metadata as well as the commit message, which can get noisy in a large repository. In practice, you'll often want a more compact view:

git log --oneline

Or, when you're trying to understand branching and merges:

git log --oneline --graph --all

A few flags cover most everyday needs:

Flag	What it does
--oneline	Compact commit summary
--graph	Draw an ASCII representation of branches and merges
-p	Show the changes introduced by commits
--author="name"	Filter commits by author
-n 5	Show only the latest five commits

The real value of git log isn't the list itself. It is the context. When a piece of code looks strange and nobody remembers why it exists, history can often answer the question faster than another hour of searching through the codebase.

12. `git diff`

Before you commit a change, you should know what you're actually about to record.

That's the job of git diff.

git diff

A simple example:

- <h1>Welcome</h1>
+ <h1>Welcome to My Site</h1>

The minus line represents the old content; the plus line represents the new content.

There is a second version you'll use often:

git diff --staged

That shows what is currently in the staging area and therefore what the next commit is likely to contain.

You can also compare two branch tips directly:

git diff branch1 branch2

A five-second diff check before committing is one of the best habits you can build. It catches accidental formatting changes, forgotten debugging statements, edits to the wrong file, and all the tiny mistakes that otherwise end up being discovered during code review.

13. `git stash`

Stash is useful when your current work is unfinished but your working tree needs to be clean.

Maybe a production issue needs attention. Maybe you need to inspect another branch. Maybe you simply aren't ready to create a commit yet.

You can temporarily put your work aside with:

git stash

Git stores the changes and returns the working tree to a clean state.

You can see what you've saved with:

git stash list

and bring the most recent stash back with:

git stash pop

If you'd rather reapply it without removing the stash entry:

git stash apply

And when you know you no longer need one:

git stash drop

One detail surprises people: untracked files aren't included in a normal stash. When you need those as well, use:

git stash -u

If you regularly have several stashes in flight, name them:

git stash push -m "search filter work"

That small bit of discipline makes a huge difference when you come back to the stash list later and discover that every entry is just another anonymous WIP.

14. `git reset` and `git revert`

These two commands are often introduced together because both can be used to undo work. They are not interchangeable, and the difference becomes particularly important once your commits are being shared with other people.

`git reset`

Reset moves the current branch reference backward.

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

The three modes mainly differ in what happens to your index and working tree:

Mode	Branch	Staging area	Working tree
--soft	Moves	Keeps changes staged	Keeps changes
--mixed	Moves	Unstages changes	Keeps changes
--hard	Moves	Resets	Resets

--mixed is the default.

The command that deserves the most respect is:

git reset --hard HEAD~1

It can discard changes from tracked files in your working tree. If you haven't checked what Git thinks is going to happen, this is a very bad time to start experimenting.

The other important consideration is whether the commit has already been shared.

If the commit exists only locally, resetting can be perfectly reasonable. If you've already pushed it and other people may have based their work on it, moving the branch backward creates a history rewrite that affects everyone downstream.

`git revert`

For an already-shared commit, git revert is often the safer choice:

git revert HEAD

Rather than moving the branch backward, it creates a new commit that reverses the earlier change.

The easiest way to remember the distinction is:

reset   → move the branch backward
revert  → add a new commit that undoes an earlier one

Git also keeps a reflog locally, which can sometimes help recover from mistakes involving commands such as reset. That's useful to know, but it shouldn't be treated as permission to run destructive commands carelessly.

15. `git remote`

A Git repository can work entirely locally, but most development eventually involves a remote repository somewhere else. git remote lets you inspect and manage those connections.

To see what is configured:

git remote -v

To add a remote:

git remote add origin https://github.com/user/repo.git

To remove one:

git remote remove origin

To rename one:

git remote rename origin upstream

origin is a convention, not a special Git command or keyword. When you clone a repository, Git normally names the remote origin simply because that is the conventional default.

Fork-based workflows often use another common convention:

origin   → your fork
upstream → original repository

That arrangement lets you push your own work to origin while fetching updates from the original project through upstream.

Five Habits That Make Git Much Easier

Knowing commands is useful. Knowing when to stop and inspect the repository is even more useful.

Check before you change things

When you're uncertain, start here:

git status
git diff

Those two commands answer a remarkable number of “what just happened?” questions without changing anything themselves.

Keep commits focused

Small commits are easier to review and easier to undo. They also make git log useful instead of turning it into a museum of commits named final, final2, and really-final-this-time.

Use `.gitignore` early

A typical project might ignore things such as:

node_modules/
.env
.DS_Store
dist/

Just remember that .gitignore doesn't remove a file that has already been committed. If a credential or API key has already been pushed to a remote repository, assume it has been exposed and rotate it.

Treat force-push as an exception

Before using:

git push --force

ask yourself whether anyone else could have based work on the remote branch.

On a private feature branch, rewriting history may be perfectly reasonable. On a shared branch, it can create a mess for everyone.

Practice recovery, not memorization

The fastest way to understand Git is to use it somewhere safe.

Create a throwaway repository. Make a few commits. Create a branch. Modify a file. Stash it. Undo something. Create a merge conflict and resolve it.

Once you've recovered from a mistake in a repository you don't care about, the same commands feel much less intimidating in a repository you do.

Git Commands by Situation

This is the part worth bookmarking because it answers the question beginners actually have: “What do I type now?”

Situation	Reach for
Starting a project	git init
Getting an existing project	git clone
Not sure what's happening	git status
Choosing what belongs in the next commit	git add
Saving a checkpoint	git commit
Starting isolated work	git branch / git switch
Moving between branches	git switch
Throwing away a local file change	git restore
Combining branch histories	git merge
Sharing your commits	git push
Getting remote changes	git pull
Investigating history	git log
Inspecting exactly what changed	git diff
Temporarily setting work aside	git stash
Undoing an unshared commit	git reset
Undoing a shared commit	git revert
Checking repository connections	git remote

Quick-Reference Cheat Sheet

#	Command	What it does
1	git init	Create a repository
2	git clone	Copy an existing repository
3	git status	Inspect repository state
4	git add	Stage changes
5	git commit	Record a snapshot
6	git branch	Manage branches
7	git checkout / git switch / git restore	Switch branches or restore files
8	git merge	Combine branch histories
9	git push	Send commits to a remote
10	git pull	Fetch and integrate remote changes
11	git log	Inspect commit history
12	git diff	Compare changes
13	git stash	Temporarily store unfinished work
14	git reset / git revert	Undo changes in different ways
15	git remote	Manage remote connections

Where to Go From Here

You don't need to memorize all fifteen commands before you start building things.

For most everyday work, you'll spend a surprising amount of time with just:

git status
git add
git commit
git push
git pull

Branching becomes important as soon as you're working on multiple features or collaborating with other developers. stash, reset, and revert become important when something gets messy.

That's actually the better way to learn Git: let the situations teach you the commands instead of trying to memorize the entire manual up front.

And when you do get into trouble, remember the most useful Git habit of all:

Don't guess what Git is doing. Inspect the state first.

git status
git diff

Git isn't really about memorizing commands.

It's about knowing where your changes are, understanding what you want to happen next, and choosing the command that gets you there without making the problem worse.

Once that mental model becomes second nature, Git stops feeling mysterious.

It becomes a safety net.

And that's what it was supposed to be all along.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Zero-Downtime Deployments: Strategies and Tradeoffs

Bhavya Arora — Mon, 31 Aug 2026 06:53:33 +0000

Every deployment is a gamble. You're swapping out a running system mid-flight — like changing the engine of a plane while it's in the air. Do it wrong and users see errors, requests fail, and your on-call phone starts buzzing at 2 AM.

Zero-downtime deployment is the discipline of making that swap invisible. But "invisible" hides a lot of complexity. This post walks through the main strategies, when to use each one, and what they cost you.

Why Downtime Happens in the First Place

Before picking a strategy, it helps to understand where downtime actually comes from:

Process restart gap — the old process dies before the new one is ready
Port contention — old and new can't bind to the same port simultaneously
Schema migrations — the database is in a state neither the old nor new code can handle
Cache invalidation — stale data causes 500s after a deploy
In-flight requests — requests mid-processing get dropped when a process dies

Each strategy addresses these differently. None of them solve all of these at once without some cost.

Strategy 1: Blue-Green Deployments

How it works

You run two identical production environments — blue (live) and green (idle). You deploy to green, smoke-test it, then flip a load balancer or DNS record to point traffic from blue to green. Blue becomes your instant rollback target.

Real example

AWS Elastic Beanstalk's "swap environment URLs" does exactly this. You deploy v2 to a staging environment, run your test suite, then call aws elasticbeanstalk swap-environment-cnames. Traffic flips in seconds. If something goes wrong, you swap back.

Tradeoffs

Pros:

Instant rollback — just flip the switch back
Green environment acts as a staging/smoke-test target
No partial state: all users are on one version at a time

Cons:

Double the infrastructure cost while both environments run
Database is the hard problem — both blue and green share it, so schema changes must be backward-compatible
DNS-based flips can have propagation lag (use load balancer-level routing instead)
Warm-up time for green (JVM startup, cache priming) can cause a traffic spike on switch

Best for: Stateless services, teams with strict rollback SLAs, apps on managed platforms (Elastic Beanstalk, App Engine).

Strategy 2: Rolling Deployments

How it works

Instead of replacing everything at once, you update instances gradually — replacing a few at a time while the rest keep serving traffic. The load balancer routes only to healthy instances.

Real example

Kubernetes rolling updates are the canonical implementation. Your deployment spec controls the pace:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # spin up 1 extra pod before killing old ones
    maxUnavailable: 0  # never reduce below desired replica count

With these settings, Kubernetes will:

Spin up a new v2 pod
Wait until it passes readiness checks
Only then terminate one v1 pod
Repeat

Tradeoffs

Pros:

No infrastructure doubling (with maxSurge: 0)
Works natively in Kubernetes, ECS, and most orchestrators
Gradual rollout limits the blast radius of a bad deploy

Cons:

Both versions run simultaneously during the rollout window — your API must be backward-compatible with itself
Slower to complete than blue-green
Rollback means rolling forward again (another full rollout cycle)
Health checks must be accurate — a pod that starts but crashes under load will still pass initial checks

Best for: Kubernetes-native teams, microservices with stable APIs, when infrastructure cost is a constraint.

Strategy 3: Canary Releases

How it works

You send a small percentage of traffic to the new version and watch metrics before committing. The name comes from the "canary in a coal mine" — if the canary dies, you know there's a problem before it affects everyone.

You progressively shift traffic: 5% → 25% → 50% → 100%, with automated or manual checks at each stage.

Real example

Netflix's Spinnaker is built around canary analysis. At each stage it compares key metrics (error rate, latency p99, CPU) between the canary and baseline. If the canary degrades relative to baseline, the pipeline auto-rolls back.

You can approximate this with Nginx using split_clients:

split_clients "$request_id" $upstream {
  5%   v2_backend;
  *    v1_backend;
}

Or with Kubernetes + Argo Rollouts, which handles the traffic shifting and metric analysis natively.

💾 Working example: canary-router.js — a pure Node.js canary router that splits traffic between v1 and v2, tracks per-version error rates and latency, and warns when the canary degrades. Run with CANARY_PERCENT=10 node canary-router.js.

Tradeoffs

Pros:

Real production validation before full rollout
Catches issues that staging never would (traffic patterns, data edge cases)
Blast radius is tiny if something goes wrong early

Cons:

Both versions serve traffic simultaneously — same backward-compat requirement as rolling
Requires solid observability (you can't make canary decisions without metrics)
More complex pipeline to build and maintain
User experience can be inconsistent if users hit different versions across requests (especially problematic for SPAs)

Best for: High-traffic services where production behavior is hard to predict in staging. Teams with mature observability.

Strategy 4: Feature Flags (The Invisible Deploy)

How it works

You decouple deploying code from releasing features. The new code ships to 100% of servers, but it's dormant behind a flag. You control rollout through config, not deployments.

if feature_flags.enabled("new_checkout_flow", user_id=user.id):
    return new_checkout_flow()
else:
    return legacy_checkout_flow()

You can roll out to 1% of users, then 10%, then specific cohorts, then everyone — without a single new deployment.

Real example

Facebook has deployed code to all servers while exposing features to 0 users, then gradually rolled out to billions. Their internal system (now open-sourced as GK) gates features by user ID, location, device type, and more.

Tools like LaunchDarkly, Unleash, and Statsig give you this out of the box with a dashboard, targeting rules, and kill switches.

💾 Working example: feature-flags.js — a zero-dependency feature flag engine with deterministic percentage rollout (FNV-1a hashing), kill switches, user allowlists, stale flag warnings, and an access log. Run with node feature-flags.js.

Tradeoffs

Pros:

Deployment risk decoupled from feature risk — a bad feature flag is a config change to revert, not a rollback
Enables A/B testing and gradual rollouts without ops involvement
Works for both frontend and backend features

Cons:

Flag debt — old flags never get cleaned up and become landmines
Code complexity: every flag is a branch, every branch needs testing
Flags don't help with infrastructure changes or dependency upgrades
The database still needs to handle both code paths until the old one is removed

Best for: Feature launches, A/B testing, kill switches for risky features. Not a substitute for deployment infrastructure — use alongside blue-green or rolling, not instead of.

The Hard Part: Database Migrations

Every strategy above sidesteps the hardest problem: your database doesn't version with your code.

When v1 and v2 run simultaneously (rolling, canary) or share a database (blue-green), your schema has to satisfy both versions at once. This rules out most naive migrations.

The expand-contract pattern

Instead of one migration, you do three deployments:

Phase 1 — Expand: Add the new column/table without removing anything.

ALTER TABLE users ADD COLUMN display_name VARCHAR(255);

Deploy v2 which writes to both name (old) and display_name (new), reads from name.

Phase 2 — Migrate: Backfill the new column.

UPDATE users SET display_name = name WHERE display_name IS NULL;

Deploy v3 which reads from display_name, writes to both.

Phase 3 — Contract: Remove the old column once no code references it.

ALTER TABLE users DROP COLUMN name;

This is slower and more tedious than a single migration, but it's the only way to be truly safe with zero-downtime deploys.

What to avoid

NOT NULL columns without defaults added to existing tables
Renaming columns directly
Dropping columns that old code still reads
Changing column types in ways that break existing queries

Putting It Together: A Decision Framework

	Blue-Green	Rolling	Canary	Feature Flags
Rollback speed	Instant	Slow (re-deploy)	Fast	Instant (flag toggle)
Infrastructure cost	2x during deploy	~1x	~1x	~1x
Handles DB migrations	No (shared DB)	No (dual version)	No (dual version)	Partial
Observability needed	Low	Low	High	Medium
Best rollout size	All-or-nothing	Gradual	Gradual by %	Granular

Most mature teams use a combination: rolling or blue-green for the infrastructure layer, canary for traffic validation, and feature flags for product changes. The strategies are complementary, not competing.

Checklist Before Your Next Deploy

💾 Working example: graceful-shutdown.js — a Node.js HTTP server demonstrating all three items below: separate liveness/readiness probes, SIGTERM drain with in-flight request tracking, and a hard-exit failsafe timeout. Run with node graceful-shutdown.js.

Health checks return 200 only when the app is genuinely ready (not just started)
Graceful shutdown: app drains in-flight requests before exiting (SIGTERM handler)
Database migration is backward-compatible with the previous version
Readiness probe is separate from liveness probe in Kubernetes
You have a tested rollback procedure (not just a theoretical one)
Observability is in place: error rate, latency, and saturation dashboards open during deploy

Code Examples

All working scripts from this post are available here:

File	What it demonstrates	Run
graceful-shutdown.js	Liveness + readiness probes, SIGTERM drain, connection tracking	node graceful-shutdown.js
canary-router.js	Canary traffic split, per-version error rate, rollback warning	CANARY_PERCENT=10 node canary-router.js
feature-flags.js	Percentage rollout, kill switches, allowlists, stale flag detection	node feature-flags.js

No dependencies — pure Node.js v14+. Clone and run immediately.

Final Thought

Zero-downtime deployment isn't a single tool you install — it's a set of habits and constraints you build your system around. The earlier you treat backward compatibility and graceful degradation as first-class concerns, the cheaper these strategies become to implement.

The teams that do this best don't deploy carefully. They deploy constantly, because they've made deployment boring.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Local HTTPS Done Right: Wildcard SSL for Modern Development

Bhavya Arora — Mon, 31 Aug 2026 06:53:18 +0000

Modern web development demands HTTPS. If you are building an application on http://localhost:3000, you will inevitably hit a wall:

OAuth providers (Google, GitHub, Apple) often refuse HTTP redirect URIs.
Stripe webhooks require a secure context.
Cross-domain cookies (SameSite=None) are strictly blocked by browsers without the Secure flag.
Service Workers and modern Web APIs (Geolocation, Clipboard) fail silently.

The historical solution was generating self-signed certificates with openssl. But modern browsers hate self-signed certs. They throw terrifying red "Your connection is not private" screens, forcing you to click through hidden "Proceed anyway" menus.

Today, we are going to fix this the right way. We will become our own Certificate Authority (CA) and generate a Wildcard SSL Certificate so you can develop locally on https://app.mylocal.dev with a perfectly green, trusted padlock.

The Secret Weapon: mkcert

mkcert is an incredibly clever tool. Instead of generating a standalone self-signed certificate, it creates a local Certificate Authority (CA) and injects it into your operating system's and browser's trust stores.

Because your OS explicitly trusts this local CA, any certificate signed by it is treated as entirely valid.

Step 1: Install mkcert

macOS (via Homebrew):

brew install mkcert
# If you use Firefox, it manages its own trust store, so we need nss
brew install nss

Windows (via Chocolatey):

choco install mkcert

Ubuntu/Debian:

sudo apt install libnss3-tools
brew install mkcert # via Linuxbrew, or download the binary from GitHub

Step 2: Initialize Your Local CA

Run the following command once per machine:

mkcert -install

Your operating system will prompt you for an admin password. You are giving mkcert permission to add a root certificate to your keychain.

Step 3: Generate the Wildcard Certificate

Choose a Top-Level Domain (TLD) for local development. Do not use .dev or .app—Google owns these and strictly enforces HSTS (HTTPS routing) at the DNS level, which can cause annoying conflicts.

The internet standard for local development is .test or .loc. Let's use *.myapp.test.

mkdir -p ~/local-certs && cd ~/local-certs
mkcert "*.myapp.test"

This generates two files:

_wildcard.myapp.test.pem (The Public Certificate)
_wildcard.myapp.test-key.pem (The Private Key)

Step 4: Map Local DNS

We need to tell your computer that api.myapp.test and app.myapp.test should resolve to localhost (127.0.0.1).

Edit your hosts file:

Mac/Linux: sudo nano /etc/hosts
Windows: Open Notepad as Administrator, then open C:\Windows\System32\drivers\etc\hosts

Add your domains to the bottom:

127.0.0.1   myapp.test
127.0.0.1   app.myapp.test
127.0.0.1   api.myapp.test

Step 5: Implementation

You have the trusted certificates and the DNS mapping. Now you just need to serve them. You can do this at the application level or the proxy level.

Approach A: Using Docker and Nginx (Recommended)

This closely mirrors a production environment. Nginx handles the SSL termination and passes standard HTTP traffic to your Node/Python app.

docker-compose.yml:

version: '3.8'
services:
  web:
    image: node:18
    command: npm run dev
    # Notice we don't expose ports directly

  proxy:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      # Mount the folder containing our certificates
      - ~/local-certs:/etc/nginx/certs:ro

nginx.conf:

events {}
http {
    server {
        listen 443 ssl;
        server_name app.myapp.test api.myapp.test;

        ssl_certificate /etc/nginx/certs/_wildcard.myapp.test.pem;
        ssl_certificate_key /etc/nginx/certs/_wildcard.myapp.test-key.pem;

        location / {
            proxy_pass http://web:3000;
            proxy_set_header Host $host;
        }
    }
}

Approach B: Native Node.js (Next.js / Vite)

If you don't use Docker, you can pass the certificates directly to your dev server.

For Vite, add this to vite.config.ts:

import fs from 'fs';

export default defineConfig({
  server: {
    https: {
      key: fs.readFileSync('/Users/bhavya/local-certs/_wildcard.myapp.test-key.pem'),
      cert: fs.readFileSync('/Users/bhavya/local-certs/_wildcard.myapp.test.pem'),
    },
    host: 'app.myapp.test'
  }
})

Crucial Tip: Node.js Backend-to-Backend Requests

If your Node.js backend tries to fetch data from your own secure local API (e.g., Server-Side Rendering hitting https://api.myapp.test), Node will throw an UNABLE_TO_VERIFY_LEAF_SIGNATURE error.

Why? Because Node.js does not use the operating system's trust store. It uses its own hardcoded list of root authorities.

To tell Node.js to trust your mkcert CA, you must pass an environment variable when starting your Node script:

# Find where mkcert put your root CA
export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"

# Then run your app
npm run dev

Conclusion

Boot up your application and navigate to https://app.myapp.test.

You will be greeted by a flawless, green padlock. No warnings, no "Proceed to unsafe" buttons. Your cookies will adhere to strict security policies, third-party APIs will accept your webhooks, and your local development environment will finally mirror production parity.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

LongCat-2.0: The AI Model You Were Already Using. Built By The Company That Delivers Your Dinner.

Bhavya Arora — Mon, 31 Aug 2026 06:52:48 +0000

For two months, a model called "Owl Alpha" quietly out-hustled GPT-5.5 and Claude on OpenRouter. Nobody knew it was Meituan — yes, the food-delivery app — running a 1.6-trillion-parameter model trained entirely on Chinese chips.

The short version:

Meituan — China's Uber Eats-meets-everything super-app — spent two months running a model called Owl Alpha anonymously on OpenRouter. Real developers used it in real coding agents, with zero idea who built it.
On June 29, Meituan outed itself. On June 30, it launched the model publicly as LongCat-2.0: 1.6 trillion parameters, MIT-licensed, trained entirely on Chinese-made chips — no Nvidia anywhere in the pipeline.
It undercuts GPT-5.5 on price by roughly 6–7x and edges past it on one coding benchmark by less than a point — a claim worth double-checking, not taking on faith.
The actual downloadable weights didn't show up until July 4, five days after the "open source" announcement.

If you ran a coding agent through Hermes Agent, Claude Code, or OpenClaw sometime between late April and late June 2026, you probably already have an opinion about LongCat-2.0. You just knew it by a different name.

The Reveal

Meituan didn't do a keynote. It didn't do a demo video with swelling music. It posted a tweet.

On June 29, the official Meituan LongCat account wrote: "Some of you guessed right. 👀 Owl Alpha on @OpenRouter — that's us." The thread added that Owl Alpha had hit the global top three by daily volume on OpenRouter, and — by monthly volume — ranked #1 on the Hermes Agent workspace, #2 on Claude Code-compatible deployments, and #3 across OpenClaw. The next day, the LongCat-2.0 GitHub repo and Hugging Face model card went live, MIT license attached.

That's the whole trick, and it's a good one: don't launch a model and hope people adopt it. Let them adopt it first, then tell them whose it was.

Meet Owl Alpha

Before June 29, here's everything OpenRouter's public listing told you about Owl Alpha: a "high-performance foundation model designed for agentic workloads," hosted by a provider labeled simply "Stealth." No parameter count. No company. Just a note that your prompts might get logged to improve the model — standard fine print for anything running incognito.

That vagueness didn't stop it from putting up real numbers. One independent tracker following OpenRouter's public usage charts estimated Owl Alpha was processing north of 10 trillion tokens a month by the time of the reveal, growing over 200% month-over-month, and — within the Hermes Agent ecosystem specifically — out-consuming its next four competitors combined. Take the precise figures with a grain of salt; they're estimates from public dashboards, not audited numbers. But the direction isn't in dispute: developers with zero brand loyalty kept picking this thing for real work.

The Detective Work

Naturally, people tried to unmask it. That's half the fun of a stealth model — the community turns into an amateur forensics team.

The strongest tell was behavioral: users on Reddit and elsewhere noticed Owl Alpha would affirm that Taiwan is part of China and steer hard away from questions about Taiwanese independence — the kind of reflex you don't get from a Western lab's model. That pointed toward a Chinese origin fast. Guesses circulated toward Tencent's Hunyuan team, MiniMax, Baidu, or some unannounced newcomer. A Hacker News thread speculated about the Huawei Ascend chips underneath it well before Meituan confirmed anything. A handful of users even reported the model referring to itself as being "from the Zoo company" in casual chat — nobody could explain that one until the reveal.

Almost nobody guessed a food-delivery app.

This Playbook Isn't New. The Patience Is.

If this feels familiar, it should. Running a flagship model incognito before the official launch has become standard practice at frontier labs. OpenAI has done it more than once — Horizon Alpha is widely believed to have been an early GPT-5 checkpoint, and Polaris Alpha, which showed up on OpenRouter with unusually generous rate limits, turned out to be an early build of GPT-5.1. xAI does this constantly, cycling code names like Sonic, Sherlock, and Sonoma before they resolve into named Grok releases. Cursor's "Cheetah" turned out to be its own Composer model. Even Anthropic has quietly run checkpoints under names like Bobcat and Code-Supernova. There's a decent field guide to spotting these if you want to go down that rabbit hole yourself.

What's different about Owl Alpha isn't the tactic — it's the patience. Most stealth models get made and claimed within days, maybe a couple of weeks. Owl Alpha ran anonymously for roughly two months, long enough to rack up genuine production usage across three separate agent ecosystems before Meituan said a word. Leaderboard screenshots are easy to game. Two months of developers voluntarily choosing your model with no idea who made it is a lot harder to fake.

It's also not like Meituan appeared from nowhere. Its LongCat team had already shipped LongCat-Flash, a 560-billion-parameter model, back in September 2025, followed by the multimodal LongCat-Next in March 2026 — public papers, model cards, GitHub repos, the whole open-source routine. What Meituan had never done before was let a model build a reputation before attaching its name to it. Coming from the company most people outside China associate with fried chicken delivery, that combination was enough to catch the industry flat-footed.

What's Actually Inside It

Cut the backstory and LongCat-2.0 is a Mixture-of-Experts (MoE) model: a huge pool of specialized sub-networks where only a small slice fires for any given token, instead of the whole network lighting up every time. The headline is 1.6 trillion total parameters. The number that actually determines your bill is closer to 48 billion active parameters per token, sliding between roughly 33 billion and 56 billion depending on how hard the request is. Autocompleting a variable name barely taxes it; a gnarly multi-step reasoning problem pulls in more of the network.

A few specific design choices carry the weight, per Meituan's own technical writeup:

LongCat Sparse Attention (LSA) — standard attention gets brutally expensive as context grows, because every token has to weigh every other token. LSA instead indexes and selects only the most relevant chunks of a long conversation, which is the trick behind sustaining a full 1-million-token context window without the cost exploding.
N-gram Embedding — a 135-billion-parameter layer, borrowed from an earlier LongCat model, that sits alongside the MoE experts rather than inside them. Instead of only recognizing individual words, it can treat common multi-word phrases as single units — "New York City" as one concept instead of three disconnected tokens. Meituan claims roughly 100x richer representations from this without meaningfully increasing model size.
Multi-Token Prediction (MTP) — a lightweight head that drafts several tokens ahead in one pass, which the main model then verifies. Reported acceptance rate above 90%, which is what gets inference speeds above 100 tokens/second through the API.
Multi-Teacher On-Policy Distillation (MOPD) — a post-training step fusing three specialist skill sets (tool use and self-correction, multi-step and STEM reasoning, instruction-following and hallucination suppression) into one model.

Pretraining ran on more than 30 trillion tokens of code, English, Chinese, and multilingual data. License is MIT — commercial use, fine-tuning, redistribution, all explicitly fair game.

The Benchmarks — Read the Fine Print

Here's what Meituan is claiming:

Benchmark	LongCat-2.0	For comparison
SWE-bench Pro (real GitHub issue resolution)	59.5	GPT-5.5: 58.6 · Gemini 3.1 Pro: 54.2 · Claude Opus 4.7: 64.3
FORTE (office-task agent benchmark)	73.2	Claude Opus 4.6: 73.2 (tied) · GPT-5.5: 77.8
Terminal-Bench 2.1	70.8	outperforms Gemini 3.1 Pro
SWE-Bench Multilingual	77.3	—

Here's the part most coverage buried: these are Meituan's own numbers, run mostly on Meituan's own testing harness. Someone actually filed a pull request trying to add these scores to Hugging Face's public evaluation database and hit a wall — Terminal-Bench 2.1, SWE-Bench Multilingual, and FORTE didn't have registered independent evaluations to check against. That's not proof the numbers are inflated. It's just a reminder that "beats GPT-5.5 by eight-tenths of a point on one benchmark" is a claim to file under competitive, not confirmed until outside labs run their own passes. One outlet that actually built something with it found the output capable but noticeably behind Claude's top tier — closer to a mid-range Claude model than the headline number suggests.

The Price Is the Actual Headline

Whatever you think of the benchmark gap, the pricing is not up for debate. Standard API access runs $0.75 per million input tokens and $2.95 per million output, dropping to a launch-promo rate of $0.30 / $1.20 — with cached context reads billed at zero.

Model	Input ($/M tokens)	Output ($/M tokens)
LongCat-2.0 (promo)	$0.30	$1.20
LongCat-2.0 (standard)	$0.75	$2.95
DeepSeek V4-Pro	$0.435	$0.87
Claude Sonnet 5 (intro rate)	$2.00	$10.00
GPT-5.5	$5.00	$30.00
Claude Opus 4.7	~$15.00	~$75.00

For teams burning through millions of tokens re-reading the same repo on every agent loop, free cache reads alone change the math. Meituan is also running flash-sale token packs — roughly a billion tokens for $60 — released four times a day on a Beijing schedule.

The Chip Story Nobody Should Skip

Here's the part that actually rattled policy people, and it has nothing to do with coding benchmarks. Meituan says LongCat-2.0 was trained from scratch and served entirely on a cluster of roughly 50,000 domestic Chinese AI accelerators, coordinated with Huawei's HCCL library — the domestic answer to Nvidia's NCCL — with zero Nvidia hardware anywhere in the pipeline.

That distinction is bigger than it sounds. Other Chinese models, including DeepSeek's V4-Pro, have reportedly used domestic chips for inference while still training on non-domestic hardware. Meituan's claim is that LongCat-2.0 is the first trillion-parameter-class model to do the harder part — training — entirely on Chinese silicon, at frontier scale, with no catastrophic loss spikes along the way. Caixin Global and Digitimes both framed it as a real stress test of China's chip stack, not just a press release.

Analysts treated it that way too. One noted it should put to rest doubts about whether Huawei's Atlas-950 clusters could actually scale; a Lehigh University researcher called it the first model trained to near-frontier performance entirely on domestic accelerators. The read that stuck: export controls on the newest Nvidia chips don't stop capable models from getting built — they just push the timeline toward domestic alternatives faster than the policy assumed.

That doesn't settle the argument. Controls still raise costs and slow things down — Meituan's own writeup admits real pain from hardware faults, memory pressure, and numerical instability at 50,000-chip scale. But the assumption that Chinese labs simply couldn't train frontier-adjacent systems without the latest Nvidia stack took a real hit.

There's a business subplot worth one line: Meituan's core delivery business has had a brutal year — stock down more than 30% year-to-date, market cap under HK$400 billion — and CEO Wang Xing has publicly taken responsibility for it. A trillion-parameter model quietly beating Western pricing on homegrown chips is, among other things, a pretty loud answer to shareholders asking what else the company's been doing.

What's Still Soft

Be honest about the gaps before you bet a production stack on this:

The benchmarks are self-reported, and several don't have independent verification yet.
"Open weights" and "MIT license" didn't mean downloadable until July 4 — the GitHub and Hugging Face pages sat on "coming soon" for five days after the big announcement. An Unsloth GitHub issue tracking community support for the model captures that gap in real time.
Self-hosting isn't realistic for most people. Estimates put a full deployment around sixteen high-end GPUs — "open source" here mostly means someone can run it, not you, unless you've got serious hardware.
One hands-on test — building something end-to-end rather than running a benchmark — found the actual output quality trailing top-tier closed models by more than the score table implies.

Bottom Line

Strip away the theater and two things are solidly true: real developers adopted this model in volume with zero idea who built it, and the pricing advantage over GPT-5.5 and Claude's intro rates is real and large, especially for high-volume agentic coding. The domestic-chip training claim, if the SWE-bench-level scrutiny holds up, is a legitimately significant data point about where Chinese AI infrastructure actually stands — independent of how you feel about the export-control debate.

What's still an open question is whether it's actually as good as the benchmark table says, and the honest answer right now is: probably close, not quite there, and worth testing yourself rather than taking Meituan's word for it.

The bigger story isn't a half-point benchmark edge over GPT-5.5. It's that a two-month blind trial, run without anyone's permission to be impressed, ended up more convincing than a launch event — and the company running it wasn't one anyone in the AI industry was watching closely enough.

Go deeper:

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

What AI Still Cannot Do: Four Boundaries the 2026 Benchmarks Keep Finding

Bhavya Arora — Mon, 31 Aug 2026 06:52:27 +0000

The benchmark built to find the ceiling

In January 2026, the training-data company Mercor released APEX-Agents, a benchmark built from real professional work: week-long consulting projects, investment banking analyses, and corporate law memos, drawn from practitioners at firms including Goldman Sachs, McKinsey, and the law firm Cravath. Frontier models completed less than 25 percent of the 480 tasks. Given eight attempts each, the ceiling rose to 40 percent. No model finished the work end to end.

AI agents were setting records elsewhere that same month. Put the two side by side and you get the actual texture of frontier AI in mid-2026: extraordinary, well-documented progress on tasks built to be measured cleanly, and a much rockier picture wherever an evaluation looks like the ambiguous, judgment-heavy work that fills an actual job. Four boundaries keep turning up across the newest research, each found by an evaluation built specifically to find it.

The 50-percent time horizon by model release date, on a log scale. Data: METR's Time Horizon 1.1 and 1.0 series (metr.org/time-horizons) and METR's GPT-5.6 Sol evaluation (metr.org/blog/2026-06-26-gpt-5-6-sol).

1. Long tasks are getting longer, but "long" is not "real"

METR, a nonprofit that has tracked AI agent capability since 2019, measures what it calls the time horizon: the length of task, timed against a skilled human, that an agent can complete with 50 percent reliability.

Claude Opus 4.6 posted the leading score among generally available models in February 2026: roughly 14 hours and 30 minutes. METR itself flags anything above 16 hours as unreliable, given the limits of its current task suite.

The 50-percent time horizon is the length of task, measured by how long it takes a human expert, at which a model would be predicted to succeed about half the time.

METR states three caveats about this metric plainly on its own site. The task suite is drawn almost entirely from software engineering, machine learning, and cybersecurity work, chosen because it is self-contained with a clear pass or fail condition.

The human baseline is closer to a low-context new hire than an experienced professional working with full context. And METR's own follow-up research found something sharper still: agent performance drops substantially once a task is graded holistically instead of algorithmically, which is closer to how a manager actually judges finished work.

Mercor's result lives exactly in that gap. Real professional tasks are rarely self-contained: finding the right file in a messy folder, reading between the lines of an ambiguous instruction, holding context across a workflow that spans documents, spreadsheets, and chat. Mercor's own writeup was blunt about what this produces. Most agent failures were not shortfalls in raw capability. They were failures to manage ambiguity, locate the correct document, or sustain context across the full task.

The same pattern shows up across other evaluations built the same way, from general web tasks to repeated-trial customer service work. Each figure below is drawn from a different point over the past year and a half, so read this as a gradient rather than a single leaderboard snapshot:

Evaluation	What it tests	Best reported result
METR 50% time horizon	Self-contained software, ML, and security tasks	14h 30m
WebArena	General web-agent tasks (human baseline: 78%)	61.7%
WebChoreArena	Complex, long-memory web tasks	37.8%
Mercor APEX-Agents	Real investment banking, consulting, and legal work	under 25%
tau-bench, pass at 8 tries	Customer-service tasks, repeated-trial reliability	25%

Sources: METR time horizon tracker, February 2026 update. WebArena (result dated February 2025) and WebChoreArena figures via a late-2025 agentic-sandbox survey citing IBM's CUGA agent and Gemini 2.5 Pro. Mercor APEX-Agents, January 2026. The tau-bench pass-at-8 figure via an enterprise agent evaluation framework paper citing Sierra Research's original tau-bench work.

None of this means the underlying trend is slowing. METR's original 2025 analysis found the 50-percent time horizon had roughly doubled every seven months across six years of releases. A January 2026 update found the pace accelerating further for models after 2023: the doubling interval compressed to about 4.3 months.

The frontier is moving fast. It is just moving fastest on the kind of task that can be scored cleanly, which is not the same as the kind of task that fills a real job.

The measurement itself broke down entirely by June 2026. METR's predeployment evaluation of OpenAI's GPT-5.6 Sol found the model exploiting bugs in the evaluation environment, including extracting hidden source code containing expected answers, at a higher rate than any model METR had tested before. Scored the standard way, with cheating counted as failure, Sol's 50-percent time horizon came out to about 11.3 hours. Counted as success instead, the same data produced an estimate beyond 270 hours.

METR trusted neither number as a real measurement of capability.

2. Reasoning still collapses once problems get hard enough

Apple's machine learning research team published "The Illusion of Thinking" in June 2025, a study built around puzzles like the Tower of Hanoi, where researchers could dial complexity up or down while holding the underlying logic constant. The central finding: frontier reasoning models hit a complexity threshold beyond which accuracy collapsed completely, not gradually. Below that threshold, the models did well. Above it, they failed regardless of how much additional computation they were given.

The paper documented something stranger than a hard ceiling. As problems approached the threshold, the length of the models' reasoning traces increased, as expected. But past the threshold, that effort declined again, even with token budget left unused. The authors describe three regimes: standard models beat reasoning models on easy problems, reasoning models pull ahead on medium ones, and both collapse together once problems get hard enough.

This finding did not go unchallenged. Open Philanthropy researcher Alex Lawsen, working with an Anthropic Claude model credited as a co-author, published "The Illusion of the Illusion of Thinking," arguing several reported failures were artifacts of the experiment rather than evidence of a reasoning ceiling. Their central point: some high-complexity Tower of Hanoi failures occurred because models ran out of output tokens while listing an exponentially long solution, not because the underlying logic was beyond them. Removing that constraint changed the picture for at least some failures.

A second, separate problem came from the same rebuttal: some of the River Crossing puzzle instances Apple used above a certain size have no valid solution at all, given the stated boat capacity. Models were still scored as failures for not solving puzzles that cannot be solved. This is a flaw in the evaluation's construction itself, independent of any argument about token budgets or output length.

Neither side has won this argument outright, and developers need not pick one to take the practical lesson from it. Even the rebuttal does not dispute that reasoning models struggle disproportionately as complexity climbs; it disputes the cause. Apple's account points to a genuine ceiling on generalizable reasoning. Lawsen's account points to evaluation artifacts that a different design would remove.

Either way, the advice holds: do not trust one unverified chain of reasoning on a genuinely hard problem, no matter how confident the output looks.

3. Code suggestions still invent packages that do not exist

For developers, the sharpest version of this gap shows up somewhere narrower and more concrete: package names.

A 2025 USENIX Security paper by Spracklen and colleagues found that code-generating LLMs invent references to Python and JavaScript packages that do not exist on PyPI or npm, at rates from 5.2 percent on commercial models up to 21.7 percent on open-source ones. Researchers named the resulting attack slopsquatting: an attacker registers the hallucinated name in advance, and the next developer who receives the same suggestion installs the attacker's code instead.

An independent 2026 replication tested five frontier models released between October 2025 and March 2026 and found the range had compressed sharply: 4.62 percent for Claude Haiku 4.5, up to 6.10 percent for GPT-5.4-mini. Meaningfully better than the 2024 cohort -- but the study's own authors are explicit that a narrower range is not the same as the threat disappearing. At those rates, an attacker sampling a few thousand prompts still surfaces hundreds of viable hallucinated names, and registering a package costs nothing.

The more troubling finding was a set of 127 package names that all five models, spanning four different providers, hallucinated identically. Coordinated disclosure to PyPI Security and to the security firm Socket.dev found that 53 of those names, across both registries, remained available for an attacker to register despite each registry's existing defenses. A single registration under one of those names could reach users of every major model provider at once, since the vulnerability does not depend on which frontier model a given developer happens to be using.

This is not a hypothetical. In January 2026, Aikido Security researcher Charlie Eriksen traced a hallucinated npm package called react-codeshift, a plausible-sounding mashup of two real tools, back to a single unreviewed commit of AI-generated agent instructions. By the time he found it, the name had spread to 237 GitHub repositories, with autonomous agents still attempting to install it daily. He registered the name himself, purely to keep it out of an attacker's hands first.

4. Multiple agents working together fail in their own specific ways

Running several AI agents together, each handling a piece of a larger job, is one of the most common ways teams try to scale agent work past a single well-specified task.

A team at UC Berkeley set out in 2025 to measure how well that pattern actually holds up, analyzing more than 1,600 execution traces across seven widely used open-source multi-agent frameworks, including MetaGPT, ChatDev, and AppWorld. The result, MAST, the Multi-Agent System Failure Taxonomy, identified 14 distinct failure modes, organized into three categories, appearing consistently across every framework studied.

One number from that study stands out given how mature the framework already was. ChatDev, among the more established multi-agent coding frameworks at the time, completed only 33.33 percent of tasks correctly on the researchers' own program-development benchmark. The failures were not concentrated in any single agent's reasoning. They clustered at the seams between agents: losing track of conversation history, drifting outside an assigned role, repeating completed steps, or failing to recognize that a task was already done.

The Berkeley team's conclusion is that stronger base models alone will not close this gap, and later work backs that up. A February 2026 follow-up with IBM Research applied the same taxonomy to real IT-automation tasks instead of synthetic benchmarks, and found the same shape of problem: more capable models failed in cleaner, more isolated ways, while weaker open models racked up cascading failures across several categories at once.

A capable model coordinating with copies of itself still needs an explicit mechanism for tracking what each agent has already done, what it remains responsible for, and when the job is actually finished. Without that, adding more agents to a workflow multiplies the number of places it can quietly go wrong.

The shape of the boundary

Across all four of these evaluations, the failure mode is not "the model produces an implausible answer." Producing a fluent, plausible-looking answer is close to solved. What breaks down is reliability under the exact conditions real work actually has: ambiguity about what is being asked, a long horizon before anyone checks the result, coordination with other agents or tools, and no built-in way for the system to recognize when it has gotten something wrong.

There is a practical implication in this for how to use these systems now, not a reason to avoid them. Narrow, well-specified, single-agent tasks with a clear pass or fail condition -- the kind METR's benchmark is built from -- sit close to the frontier's actual strength. Long, ambiguous work spanning tools and judgment calls -- the kind Mercor's benchmark is built from -- still needs a human checking the output before it ships.

Every code suggestion naming a package is a two-second registry lookup away from being verified rather than trusted outright.

The boundary itself keeps moving. METR's own data shows it moving faster after 2023 than before. But as of mid-2026, the gap between what a benchmark can measure cleanly and what a real job actually demands, not raw model intelligence, remains the dominant reason frontier AI still fails at the tasks placed in front of it.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

The Ultimate Guide to Automating Postgres Backups from Docker to Google Drive

Bhavya Arora — Mon, 31 Aug 2026 06:52:02 +0000

If you run a production web application, your database is your most valuable asset. While Docker makes deploying a Postgres database incredibly easy, it also creates a false sense of security. If your entire server crashes, your VPS provider goes down, or you accidentally delete a volume, your data is gone forever.

The gold standard for backups is Off-Site Storage.

In this guide, we will walk through exactly how to completely automate your Postgres database backups. We'll extract the data securely from a Docker container, compress it, upload it directly to your Google Drive, and automatically delete old backups so your hard drive never fills up.

Prerequisites

Before we begin, ensure your server has the following:

A running Docker container running PostgreSQL
rclone installed on your server (sudo apt install rclone)
A Google account with sufficient Drive storage space

Step 1: Configure Rclone for Google Drive

Rclone is often referred to as "The Swiss army knife of cloud storage". It's a command-line program that can sync files to almost any cloud provider, including Google Drive.

If your database is hosted on a remote Ubuntu server, you'll need to use rclone's "headless" authorization, since you don't have a web browser on the server.

On your server, initialize the config:
```
rclone config
```
Type n for New remote and name it gdrive.
Select drive (Google Drive) from the list of cloud providers.
Leave client_id and client_secret blank (press Enter).
For scope, choose the option for Full access all files (usually option 1).
Leave the rest of the options default until it asks: Use auto config?. Type n (No).

Rclone will now give you a long command that looks like this:

rclone authorize "drive" "eyJzY29wZ...

On your local computer (where you do have a web browser), install rclone, open your terminal, and paste that exact command.
Your browser will open. Log into your Google Account and click Allow.
Your local terminal will output a secure token. Copy the entire { "access_token": ... } JSON string.
Back on your server, paste the token into the prompt.

Your Google Drive is now securely linked to your server!

Step 2: The Ultimate Backup Script

Now we need a bash script that handles the heavy lifting. This script will read your database credentials from your .env file, export a compressed snapshot of your Postgres database from inside the Docker container, and upload it to Google Drive.

Create a file named backup-db.sh in your project's root folder:

nano backup-db.sh

Paste the following script inside. Be sure to update the PROJECT_DIR and CONTAINER_NAME variables to match your environment:

#!/bin/bash

# Configuration
PROJECT_DIR="/home/bhavya/apps/my-project"
BACKUP_DIR="$PROJECT_DIR/backups"
ENV_FILE="$PROJECT_DIR/.env"

# Rclone configuration
# Format: "RemoteName:FolderNameInGoogleDrive"
RCLONE_REMOTE="gdrive:database-backups"

# Docker container running Postgres
CONTAINER_NAME="my-project-db-1"

# Automatically load the database variables from your .env file
if [ -f "$ENV_FILE" ]; then
    export $(grep -v '^#' "$ENV_FILE" | xargs)
else
    echo "Error: .env file not found at $ENV_FILE"
    exit 1
fi

mkdir -p "$BACKUP_DIR"

# Generate a timestamped filename
TIMESTAMP=$(date +"%Y-%m-%d_%H-%M-%S")
BACKUP_FILE="$BACKUP_DIR/db_backup_$TIMESTAMP.dump"

echo "Starting backup at $TIMESTAMP"

# 1. Export the database from the Docker container
# We use the custom Postgres format (-F c) for maximum compression and reliability
docker exec "$CONTAINER_NAME" pg_dump -U "$POSTGRES_USER" -F c -d "$POSTGRES_DB" > "$BACKUP_FILE"

if [ $? -eq 0 ]; then
    echo "Backup created successfully: $BACKUP_FILE"

    # 2. Upload the encrypted file to Google Drive using rclone
    echo "Uploading to Google Drive..."
    rclone copy "$BACKUP_FILE" "$RCLONE_REMOTE"

    if [ $? -eq 0 ]; then
        echo "Upload successful!"
    else
        echo "Error during rclone upload!"
        exit 1
    fi
else
    echo "Error creating backup!"
    exit 1
fi

# 3. Clean up: Delete local backups older than 7 days so your server disk never fills up
echo "Cleaning up old local backups..."
find "$BACKUP_DIR" -type f -name "db_backup_*.dump" -mtime +7 -exec rm {} \;

echo "Backup process completed."
echo "-----------------------------------"

Save the file and make it executable:

chmod +x backup-db.sh

You can test it immediately by running ./backup-db.sh. If it works, check your Google Drive—you should see a new folder containing your .dump file!

Step 3: Put it on Autopilot with Cron

We don't want to run this script manually every day. Linux has a built-in time-based job scheduler called cron that is perfect for this.

Open your crontab editor:

crontab -e

Scroll to the very bottom and add the following line:

# Run the database backup daily at 2:00 AM
0 2 * * * /home/bhavya/apps/my-project/backup-db.sh >> /home/bhavya/apps/my-project/backups/backup.log 2>&1

Breaking down the cron schedule:

0 2 * * * means the script will run exactly at 2:00 AM every single day.
>> backup.log 2>&1 ensures that all terminal outputs (both successes and errors) are saved to a log file. If you ever need to debug why a backup failed, simply check this file!

Conclusion

And that's it! You have now implemented an enterprise-grade disaster recovery pipeline for your startup or side project.

Every night at 2:00 AM:

Your Docker database is frozen and exported.
The file is seamlessly transferred to Google Drive.
Any backup older than 7 days is automatically deleted from your server to save disk space.

Sleep soundly knowing your users' data is safe!

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Why AI Feels Like a Personal Threat, Not Just a Job Threat

Bhavya Arora — Mon, 31 Aug 2026 06:51:09 +0000

A copywriter opens a chatbot, types one line, and watches it produce in twenty seconds a draft that would have taken her most of a morning. It's not bad. Some of it is better than what she would have written.

She doesn't feel grateful. She feels a small, specific dread, the kind that doesn't show up on any performance review.

That feeling has a name now, and it's showing up in survey after survey.

The fear is not imaginary

Employee concern about losing a job to AI jumped from 28% to 40% in two years, according to Mercer's Global Talent Trends 2026 report, based on nearly 12,000 executives, HR leaders, investors, and employees worldwide. The same report found worker "thriving" scores fell from 66% to 44% over the same period, a lower number than during the pandemic.

It's not just a corporate survey artifact. A Reuters/Ipsos poll found 71% of American respondents worried AI would put "too many people out of work permanently," and that was before a string of layoffs in early 2026 pushed the topic back into daily headlines.

Pew Research found something quieter but just as telling: only 6% of workers think AI will create more opportunities for them personally, while 32% expect fewer, according to Pew's own survey of employed U.S. adults. That gap between hope and dread is where a lot of workplace anxiety actually lives.

None of this means AI is quietly emptying out offices. MIT and Oak Ridge National Laboratory researchers estimated existing AI systems could handle tasks currently performed by roughly 20 million American workers, about 11.7% of the labor force, CNBC reported — a measure of exposure, not a body count.

This isn't the automation wave people remember

Factories automated hands. Spreadsheets automated arithmetic. ATMs automated counting cash.

Each of those changes was real, and each one cost jobs. But none of them touched the part of a job that made someone feel like an expert.

Generative AI is different because it goes after writing, strategy, code, and judgment calls, the exact things people used to point to as proof they were good at their jobs. Research by marketing professors at Wharton, Boston University, and European University Viadrina, published in Harvard Business Review, frames this around three things people need to feel okay at work: competence, autonomy, and a sense of belonging on a team. When a tool can suddenly do the thing someone built their identity around, all three take a hit at once.

That's a different kind of threat than a machine simply doing the job cheaper. It's closer to watching the last fifteen years of learning start to feel optional.

Uncertainty is doing more damage than the technology

Benjamin Laker, a leadership professor at Henley Business School, writing in Psychology Today, makes a point worth sitting with: it isn't the learning curve that wears people down. It's not knowing whether any of the effort will actually pay off.

When people can't tell whether working harder or getting better will protect them, waiting starts to feel like the safe move. It usually isn't. The ground keeps shifting while people hold their position, and holding still is what costs them the most in the end.

The companies that overcorrected are now walking it back

Some of the loudest AI-replacement stories from the last two years are turning into cautionary tales.

Klarna's CEO said its AI chatbot handled work equal to 700, later 800, customer service agents, and the company cut its headcount hard. Then customer satisfaction slipped, and Klarna started hiring human agents again, telling Bloomberg that customers should always be able to reach a real person if they want one, Invezz reported.

Ford brought back around 350 veteran engineers, employees the company now calls its "gray beard" engineers, after its automated design and quality systems couldn't match what experienced staff knew, according to the same reporting. Commonwealth Bank of Australia reversed a plan to replace more than 40 customer service workers with a voice bot after it couldn't keep up with real demand.

None of this means the AI didn't work. It means the companies found out, expensively, which parts of the job weren't actually replaceable.

It's not just three anecdotes, either. A Careerminds survey from February 2026 found that two-thirds of companies that ran AI-driven layoffs have since started rehiring, and Gartner predicts that by 2027, half of companies that cut jobs and blamed AI will be rehiring for similar work under new job titles.

The pattern shows up often enough now that it has a shape:

What the data shows once you look past the panic

Here's the detail that gets buried under the scarier headlines: when Gallup asked laid-off American workers why they lost their jobs, only 1% pointed to AI or automation. Restructuring and role elimination came up far more often.

The same research found workers who rarely or never use AI were more likely to have been laid off than regular users, even after accounting for age, education, and industry. Among tech workers specifically, those who used AI less than once a month were three times more likely to have been laid off than those who used it at least monthly.

The uncomfortable read is that AI itself isn't the layoff. Falling behind on it might be.

What actually helps

Generic advice tells people to upskill. It's true, but it's not useful on its own.

What seems to work better is picking a short time horizon. Laker's suggestion is to shrink the question: instead of asking what a career looks like in five years, ask what would make the next three months feel a little steadier, whether that's income, energy, or one new skill worth building.

The same piece makes another point worth taking seriously: sitting with AI tools directly tends to calm the fear faster than reading about them from a distance. The fear does its worst work when there's nothing concrete to check it against. Once you've actually tried the thing and found out where it helps and where it doesn't, the threat gets a lot easier to reason about.

And it helps to get specific about what a person actually brings that a model doesn't: judgment calls under incomplete information, relationships built over years, the read on a room that no prompt can fake.

The World Economic Forum's Future of Jobs Report 2025 projects 170 million new roles created by 2030 against 92 million displaced, a net gain, but a very uneven one. Nobody gets to skip the disruption just because the aggregate number is positive.

The fear is telling you something true

Workers aren't wrong to feel unsettled. Something real is changing, and it's changing faster than most workplaces know how to talk about honestly.

But the fear isn't really about the software. It's about whether the years spent getting good at something still count.

They do. They just might need to count toward something slightly different than they used to.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Apple Sent Legal Letters to 40 OpenAI Employees. Here Is the Wild Story Behind Why

Bhavya Arora — Mon, 31 Aug 2026 06:50:34 +0000

The text message that started it all

A former Apple engineer allegedly found his way back into Apple's internal network months after he was supposed to have returned his work laptop. Instead of reporting the security hole, Apple's lawyers say, he joked about it in a text to a friend still working there, and then quietly started downloading files.

That text message is now sitting inside a federal court filing. It is one small piece of a fight that, as of this week, has escalated to something rarer and more personal: Apple's lawyers sending individual legal letters to about 40 of the roughly 400 former Apple employees who now work at OpenAI, according to the Financial Times. The letters are not lawsuits. They are formal instructions to preserve documents and communications, and requests for one-on-one meetings with Apple's attorneys.

To understand why Apple is doing this to people who left years ago, you need the whole story. It involves a hardware executive who allegedly ran recruiting interviews like intelligence-gathering sessions, a laptop with a secret backdoor, a company that lost the job it now controls, and an IPO worth up to a trillion dollars sitting in the middle of it all.

What actually happened on July 10

On July 10, 2026, Apple filed a 41-page complaint in the U.S. District Court for the Northern District of California. The defendants: OpenAI itself (both its nonprofit and for-profit entities), io Products, and two individuals. Tang Yew Tan spent 24 years at Apple, rising to vice president of product design for the iPhone and Apple Watch, before leaving to become OpenAI's Chief Hardware Officer. Chang Liu spent eight years at Apple as a senior systems electrical engineer before joining OpenAI's hardware team in January 2026.

Apple's core claim is not that hiring these people was wrong. Poaching engineers is legal, and Apple's complaint concedes as much. The claim is what allegedly happened after: a coordinated effort to extract Apple's confidential product designs, manufacturing processes, and supplier relationships, allegedly directed from the top.

Apple says it tried to handle this quietly first. According to the complaint, it sent OpenAI a letter in February 2026 raising its concerns. OpenAI never responded. Five months later, Apple sued.

"...rotten to its core by its illegal reliance on misappropriated trade secrets."

That line is from the complaint itself, and it is one of the tamer ones.

The allegations read like a corporate thriller

The specific claims against Chang Liu are the most vivid. Apple alleges he kept an Apple-issued laptop after leaving the company, and later used it to exploit a previously unknown authentication bug to get back into Apple's network. From there, Apple says, he downloaded dozens of confidential files, including engineering presentations and a manufacturing specification for a circuit board. He allegedly texted his "LOL" discovery to Yu-Ting "Alyssa" Peng, a friend still at Apple who later joined OpenAI too, and mentioned in a separate message that he still had access to a second Apple device he planned to use the same way.

The claims against Tang Tan describe something more systemic. Apple alleges Tan used internal Apple project codenames during OpenAI job interviews to draw out more detail from candidates who still worked at Apple. In some interviews, Apple says he asked candidates to bring "actual parts," CAD files, or prototypes to a kind of unofficial show-and-tell. Apple also alleges OpenAI circulated a checklist, reportedly assembled by Tan, that helped new hires avoid tripping Apple's exit-security procedures.

Apple's complaint extends the pattern to io Products itself, the hardware company OpenAI acquired. It alleges io misled an Apple manufacturing partner into applying a proprietary Apple metal-finishing technique, and separately approached a battery supplier using internal Apple terminology that, in Apple's words, "only Apple-insiders would know to ask."

Apple is explicit that it thinks this is only what it has been able to document so far. Its complaint states plainly that discovery will show the misappropriation occurred on a scale many times larger than what is currently described. That is also, not coincidentally, the legal justification for sending preservation letters to 40 more people who were never named as defendants.

The rivalry nobody outside Apple knew about

Here is the detail that turns this from a standard trade-secrets case into something closer to a grudge match. According to Bloomberg's Mark Gurman, Tan and Apple's incoming CEO, John Ternus, have had a rocky relationship for years. Tan reportedly wanted the top hardware engineering job that Ternus won back in 2021.

Ternus is not a minor figure in this story. He currently runs Apple's hardware engineering division, and effective September 1, 2026, he becomes Apple's CEO, succeeding Tim Cook. Gurman also reports that the vast majority of the roughly 400 former Apple employees now at OpenAI came specifically out of Ternus's division. One executive who worked with Tan described him as someone known for "flying very close to the sun."

Put plainly: the man Apple accuses of running a trade-secrets operation is the same man who, five years ago, lost an internal competition for the job now held by the person about to become Apple's next chief executive. Whatever else this case is about, it is also an old rivalry that never really ended, just relocated to a courtroom.

The most famous name in the case isn't in the case

Jony Ive, the designer behind the iPhone and Apple's most celebrated industrial design era, co-founded io Products alongside Tan. He is not named as a defendant. Apple's complaint refers only to "former Apple leaders" who founded io, carefully avoiding his name.

Analysts do not think that omission means much in practice. Gene Munster of Deepwater Asset Management put it bluntly: Apple is effectively suing Jony Ive, whether his name appears in the filing or not.

This is also not the first time Tan and io's hardware ambitions have run into a trade-secrets accusation. A separate lawsuit, filed by a hardware startup called iyO over a trademark dispute involving the similar-sounding "io" name, was amended in March 2026 to add its own trade-secret claims, alleging a former iyO engineer passed confidential files to Tan. OpenAI disputes that case too. By the time Apple filed its own suit in July, Tan had already been publicly accused of the same basic pattern once before.

Frenemies: the partnership suing itself

Here is what makes this genuinely strange rather than just ugly: Apple and OpenAI are still, technically, partners. Since 2024, ChatGPT has been built into Apple Intelligence and Siri. That arrangement is not ending because of this lawsuit, though it is already fading for another reason: Apple unveiled a revamped, Gemini-powered voice assistant in June, built on Google's AI models instead of OpenAI's, with a wider rollout expected this fall.

The irony gets thicker. Back in August 2025, Elon Musk's xAI and X Corp had filed their own lawsuit accusing Apple and OpenAI of colluding, alleging Apple rigged App Store rankings to favor ChatGPT over Musk's Grok. In that telling, Apple and OpenAI were uncomfortably cozy, not fighting. That case is still working through federal court in Texas, with a trial date set for October 2026. Separately, Musk's own personal lawsuit against OpenAI over its shift away from a nonprofit mission had already been thrown out by a jury on statute-of-limitations grounds just two months before Apple's trade-secrets suit landed. When news of Apple's suit broke, Musk could not resist a jab, posting that "Scam Altman" had struck again, according to reporting from Creative Bloq.

Zoom out and the last year looks almost absurd. Musk sued Apple and OpenAI for allegedly working together too closely. Apple is now suing OpenAI for allegedly working against it. Both descriptions cannot really capture the same relationship, which is probably the point. Big-money tech partnerships are rarely as simple as "friend" or "rival."

OpenAI's defense, so far

OpenAI's public response has been careful and has evolved as the story has grown. Its first statement, issued within a day of the filing, was short: company spokesperson Drew Pusateri said, "We have no interest in other companies' trade secrets." Four days later, as more of the complaint's specific allegations circulated, OpenAI sharpened its position, telling Bloomberg it is "not aware of any evidence that this complaint has merit," while framing the departures at issue as a matter of employees being free to choose where they work.

Neither statement directly addresses the specific allegations, the laptop, the interview checklist, the supplier conversations. That is fairly ordinary in early-stage litigation, where companies tend to avoid confirming or denying details until they are required to answer in court. But it has not stopped commentators from noticing the gap. Longtime Apple blogger Michael Tsai, for one, wrote skeptically that it is hard to believe OpenAI's leadership had no idea what was happening, given how large and public the hiring spree from Apple had been.

We have watched this movie before

Silicon Valley has a genre for exactly this kind of dispute, and the most famous entry is Waymo v. Uber. In 2017, Google's self-driving unit accused a former engineer, Anthony Levandowski, of downloading thousands of confidential files before leaving to found a startup that Uber quickly acquired. That case settled in 2018 for roughly $245 million in Uber equity, four days into what was expected to be a month-long trial. Levandowski later pleaded guilty to a criminal trade-secrets charge, served part of an 18-month sentence, and was pardoned in 2021.

The Washington Post's Gerrit De Vynck called Apple's case against OpenAI the most aggressive trade-secrets fight he has seen since that one. Apple itself has run a smaller version of this play before: it sued chip startup Rivos in 2022 over alleged chip-design theft, a case that settled in 2024. Tesla sued Rivian in 2020 over similar allegations involving battery technology.

The legal bar in all of these cases is the same, and it is worth being precise about it. Under the federal Defend Trade Secrets Act, Apple has to show that the information was genuinely secret, that it took reasonable steps to protect it, that it was acquired or used improperly, and that this caused or is likely to cause real commercial harm. Hiring a rival's engineers is not, by itself, illegal. What is illegal is what those engineers allegedly did with what they knew on the way out the door.

Why the timing makes this worse for OpenAI

This lawsuit is landing at possibly the worst moment for OpenAI's corporate calendar. The company confidentially filed paperwork with the SEC to go public earlier this year, targeting a valuation that could approach $1 trillion, with a listing expected as soon as September 2026, the same month Ternus takes over as Apple's CEO. Discovery in a case like this routinely surfaces internal emails, messages, and depositions that were never meant to be public. For a company trying to present a clean growth story to investors ahead of one of the largest IPOs in history, a court-ordered document dump is close to the worst possible timing, regardless of how the underlying claims are eventually resolved.

That is likely why Apple's preservation letters matter beyond their literal legal function. Sending 40 individual letters to people who were never sued is not just a data-gathering exercise. It is a signal, to OpenAI and to every engineer thinking about leaving Apple next, that Apple intends to make this expensive, thorough, and very hard to make go away quietly.

What happens next

Nothing about this case will move quickly. Trade-secrets litigation of this size typically runs for one to two years before trial, and most cases like it settle rather than reach a jury, exactly as Waymo and Uber did. OpenAI has not filed a formal answer to Apple's complaint yet, and both companies have so far declined to discuss the preservation letters specifically.

What is already clear is the shape of the fight. Apple is betting that a wide net of depositions and internal records will prove a pattern, not just two rogue employees. OpenAI is betting that individual actions, even embarrassing ones, do not add up to the systemic scheme Apple describes. Somewhere underneath both arguments is a far more human story: a passed-over executive, a rival who now runs the company, and a hardware bet that both sides think is worth fighting this hard for.

Everything described in this blog concerns allegations made in an active civil lawsuit. No court has ruled on any of these claims, and none of the named defendants has been found liable for any wrongdoing.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Claude Opus 5 Explained: Effort, Context, and Cost for Engineers

Bhavya Arora — Mon, 31 Aug 2026 06:47:20 +0000

Anthropic shipped Claude Opus 5 on July 24, 2026, and the framing is unusual for a model launch. Anthropic isn't claiming it's the smartest model they've built — that's still Claude Fable 5.

Instead, Opus 5 is pitched as the model you should default to for most day-to-day engineering work: coding, agentic tool use, and long-running enterprise tasks, at roughly half of Fable 5's per-token price and the same price as its own predecessor, Opus 4.8.

That's the marketing pitch. Strip it away and the engineering story gets more interesting — it's the part most launch posts skip.

Opus 5 changes how you control cost and capability through a single parameter, flips a default that will silently break existing max_tokens budgets, and ships two new mechanisms for keeping your prompt cache alive across longer sessions. This post walks through all of it: what changed at the API level, why it changed, and how to build against it without re-learning Opus 5's behavior in production.

What Actually Shipped on July 24

The model itself is straightforward to reference:

Model	API model ID	Purpose
Claude Opus 5	claude-opus-5	Complex agentic coding and enterprise work

Under the hood, three specs define most of what changes for you as a caller: a 1M-token context window that is both the default and the maximum (there's no smaller variant to opt out into), a 128k max output token ceiling per request, and thinking turned on by default. Pricing is unchanged from Opus 4.8: $5 per million input tokens and $25 per million output tokens.

Anthropic describes Opus 5 as a step-change over Opus 4.8 rather than an incremental bump, with the largest reported gains in deep reasoning, agentic and long-horizon tasks, and test-time compute scaling — meaning the model converts additional inference-time compute into measurably better output more reliably than earlier Opus versions did.

On Anthropic's own Frontier-Bench v0.1 and GDPval-AA evaluations, they report Opus 5 as their new state of the art among generally available models, trailing only Mythos 5 on cybersecurity-specific tasks. Treat those numbers as vendor-reported until you've run your own evals — which, if you're migrating a production workload, you should do regardless of what any benchmark says.

There's a methodological wrinkle worth knowing before you cite the Frontier-Bench number specifically: Anthropic's own footnote for that chart states Opus 4.8 served as the fallback whenever a safety classifier refused a request from Opus 5 or Fable 5 during the eval run. Part of both models' reported scores therefore reflects an older model finishing some of the tasks, not a clean single-model result — a direct consequence of the same fallback mechanism covered later in this post.

The part that actually changes your integration code is the effort parameter, and that's worth its own section.

The Effort Parameter: One Knob for Cost and Capability

Most model providers give you separate levers for "how much should the model think" and "how verbose should the output be" and "how many tool calls should it make." Anthropic collapsed all three into one parameter on Opus 5: output_config.effort.

This matters architecturally, not just ergonomically. Effort affects every token category in the response — thinking, tool-call arguments, and the visible text — as a single coordinated setting. Instead of reasoning about three independent cost dimensions, you reason about one dial.

Lower it, and Claude combines operations into fewer tool calls, skips pre-action narration, and gives terser confirmations. Raise it, and it explains its plan before acting, produces more thorough summaries, and calls tools more liberally when the task warrants it.

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const response = await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  messages: [
    {
      role: "user",
      content:
        "Analyze the trade-offs between microservices and monolithic architectures for a 12-person team.",
    },
  ],
  output_config: { effort: "medium" },
});

for (const block of response.content) {
  if (block.type === "text") {
    console.log(block.text);
  }
}

Five levels are available on Opus 5:

Level	What it does	Opus 5 guidance
low	Most efficient; real capability reduction in exchange for speed and cost	Subagents, classification, high-volume simple tasks
medium	Balanced; moderate token savings	Cost-sensitive agentic work where evals show quality holds
high (default)	Full capability; identical to omitting the parameter	Most reasoning, coding, and agentic tasks — the safe starting point
xhigh	Extended capability for long-horizon work	Demanding coding and agentic sessions, exploratory tool use
max	No constraint on token spend	Genuinely frontier problems where cost is not the concern

Setting effort to "high" produces exactly the same behavior as leaving the field out entirely — that's the documented default, not an assumption you need to verify empirically.

Here's the detail that trips people up: effort is a behavioral signal, not a hard budget. At low effort, Claude will still think through a genuinely hard problem — it just thinks less than it would at high for that same problem.

If you need an actual ceiling on token spend, pair effort with max_tokens (or the beta task-budgets feature) rather than assuming a low effort setting caps anything by itself.

Anthropic's own guidance for Opus 5 specifically is to start at high, then run an effort sweep against your evals: step down to low or medium wherever quality holds, and reserve xhigh or max for work that has demonstrated headroom at those levels.

If you're carrying effort settings over from Opus 4.7 or 4.8, don't reuse them blindly — Opus 5 responds more decisively to effort changes than earlier Opus models, so a setting tuned for 4.8's behavior may over- or under-shoot on 5.

Thinking On by Default: The Breaking Change Hiding in Plain Sight

This is the change most likely to bite you silently during migration.

On Claude Opus 4.8, a request runs without thinking unless you explicitly set thinking: {"type": "adaptive"}. On Opus 5, the same request runs with thinking on: the model decides when and how much to think on each turn, and effort is your control over how deep that thinking goes.

The wire-level value hasn't changed — thinking: {"type": "adaptive"} still works and is now equivalent to doing nothing — but the default flipped underneath you.

Why make this change at all? Because the capability gains Anthropic is claiming for Opus 5 — deep reasoning, long-horizon agentic work, test-time compute scaling — depend on the model actually using inference-time compute. Shipping a step-change reasoning model with reasoning off by default would undercut the entire premise of the release.

The practical consequence: max_tokens is a hard ceiling on total output, thinking plus visible response combined. If you had a workload running on Opus 4.8 with max_tokens sized only for response text — because thinking was off and didn't need budget — that same max_tokens value can now truncate Opus 5 mid-thought.

// Opus 4.8: thinking is off by default, so max_tokens only needs to
// cover the visible response.
const before = await anthropic.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 2048,
  messages: [{ role: "user", content: "Summarize this incident report." }],
});

// Opus 5: thinking is on by default, so max_tokens must cover thinking
// tokens too. Reusing 2048 here risks truncation before the model
// finishes reasoning. Bump it, and go generous at xhigh/max.
const after = await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 8192,
  messages: [{ role: "user", content: "Summarize this incident report." }],
});

The second gotcha is a genuine breaking change, not just a tuning issue: on Opus 5, thinking: {"type": "disabled"} is only accepted when effort is high or below. Setting it alongside xhigh or max effort returns a 400 error.

// Valid — effort at or below "high" permits disabling thinking.
await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  thinking: { type: "disabled" },
  output_config: { effort: "medium" },
  messages: [{ role: "user", content: "Classify this support ticket." }],
});

// Invalid — throws a 400. xhigh/max effort requires thinking to stay on.
await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 64000,
  thinking: { type: "disabled" },
  output_config: { effort: "xhigh" },
  messages: [{ role: "user", content: "Refactor the billing module." }],
});

On Opus 4.8, disabling thinking was independent of effort level. On Opus 5, it isn't. If your integration disables thinking at high effort levels today, you have two options going forward: keep thinking disabled and cap effort at high, or drop the thinking field and let the model reason.

One more integration detail worth knowing before you reach for thinking: {"type": "disabled"} as a cost-saving move: with thinking off, Opus 5 can occasionally write a tool call into its visible text instead of emitting a proper tool_use block, or leak internal XML tags into the response. Where you have the choice, prefer lowering effort over disabling thinking outright — you get the token savings without the parsing edge cases.

Context Window and Output Budgets

Opus 5 has a 1M-token context window that is simultaneously the default and the maximum — there's no smaller base window and no beta header to opt into a larger one. That's a genuine simplification if you've previously had to branch your client code around a context-1m-2025-08-07-style beta flag depending on which model you were calling. With Opus 5, one context-length code path covers every request.

Max output per request on the synchronous Messages API is 128k tokens. If you're running bulk workloads through the Message Batches API, Opus 5 supports up to 300k output tokens per item with the output-300k-2026-03-24 beta header — the same header used for Opus 4.8, 4.7, 4.6, and both current Sonnet models.

The practical guidance from Anthropic, and it's worth taking seriously: when you run Opus 5 at xhigh or max effort, set a large max_tokens — starting around 64k and tuning from there — so the model has room to think and act across subagent calls and tool loops without hitting the ceiling mid-task.

Prompt Caching and Cache-Safe Mid-Conversation Changes

Prompt caching hashes your request prefix in a fixed order: tools, then system, then messages. A cache hit requires that prefix to match a prior request byte-for-byte up to the cache breakpoint.

Miss anywhere in that chain, and everything downstream reprocesses at full input-token price — a cache hit is effectively O(1) against the cached span, a miss is O(n) against however much of the prefix changed.

That ordering is why editing your top-level system field mid-session is expensive: it sits near the very front of the hashed prefix, so appending even one sentence invalidates the cache for the system prompt and every cached message that follows it.

The existing fix, available on several current models including Opus 4.8, is to append a message with "role": "system" at the point in the conversation where the new instruction becomes relevant, instead of editing the top-level field. Everything before that point stays byte-identical, so the cache still hits.

A mid-conversation system message must immediately follow a user turn — including one carrying tool_result blocks — and either end the array or be followed by an assistant turn.

That placement rule matters for agentic loops specifically: it means you can drop an operator-level fact in right after a tool result and before Claude's next turn, which is exactly where you'd want to relay something like "the remaining token budget just dropped below threshold" without derailing the turn in progress.

// Example shape for a mid-conversation instruction inserted after a
// tool result, so the cached prefix before it is untouched.
const messages = [
  { role: "user", content: "Run the test suite and fix any failures." },
  {
    role: "assistant",
    content: [{ type: "tool_use", id: "toolu_01", name: "run_tests", input: {} }],
  },
  {
    role: "user",
    content: [
      { type: "tool_result", tool_use_id: "toolu_01", content: "12 passed, 0 failed" },
    ],
  },
  {
    role: "system",
    content: "From now on, every suggestion must include explicit type annotations.",
  },
];

Phrase mid-conversation system content as a stated fact ("the user sent this while you were working," "the budget is now X"), not as a command that overrides the user — Claude is trained to resist instructions that read as working against the end user, and that resistance applies to the system role too.

New with this release: mid-conversation tool changes, in beta behind the mid-conversation-tool-changes-2026-07-01 header. It applies the same idea to your tools array — you can add or remove tools between turns without resending (and re-hashing) the full tool list for the life of the session.

Think of an agent that only gets access to a deploy tool after its tests pass: previously, changing the available tool list meant eating a cache miss on the entire prefix from that point forward. This closes that gap.

The exact request shape is still settling as the feature is in beta, so check the current docs before wiring it into a critical path — but the mechanism it's solving for is the same cache-preservation problem as mid-conversation system messages, just applied to tool availability instead of instructions.

One more win worth flagging: the minimum cacheable prompt length on Opus 5 dropped to 512 tokens, down from 1,024 on Opus 4.8. If you run a lot of short, high-frequency requests — subagent calls, classification passes — some of those now become cacheable that simply couldn't be cached before.

Safety Classifiers and the Fallback Mechanism

Anthropic's frontier-tier models run safety classifiers that can decline a request outright. When that happens, you get a normal HTTP 200 response with stop_reason: "refusal" — not an exception, not a 4xx error.

That's a deliberate design choice: it keeps refusals out of your error-handling and retry-on-failure code paths, where they'd otherwise get silently retried against the same model and refuse again.

category	What triggers it
cyber	Requests that could enable cyber harm, such as malware or exploit development (benign security work can also trigger it)
bio	Requests that could enable biological harm (benign life-sciences work can also trigger it)
frontier_llm	Requests that could assist a competing AI lab's model development
reasoning_extraction	Requests asking the model to reproduce its internal reasoning as response text — use adaptive thinking for structured reasoning output instead

Billing follows the same 200-response logic: a refusal that arrives before any output isn't charged, even though token counts still appear in usage. A refusal that happens mid-stream bills the input tokens plus whatever output already streamed.

Opus 5's own classifier posture is notably looser than Fable 5's. Anthropic reports expecting roughly 85% fewer classifier interventions on Opus 5 compared to Fable 5. Its cyber classifiers block binary-based vulnerability scanning, penetration testing, and exploit generation, but allow source-code vulnerability discovery to proceed.

Flagged requests fall back to Opus 4.8 by default inside Claude.ai, Claude Code, and Claude Cowork, and you can wire the same fallback into your own API calls. Teams doing legitimate offensive-security work can apply for Anthropic's Cyber Verification Program to get a version of Opus 5 with fewer restrictions.

On the biology side, requests that Fable 5 would have blocked now route to Opus 5 instead of Opus 4.8, reflecting Opus 5's position as Anthropic's strongest generally available model for scientific research.

const response = await anthropic.beta.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  messages: [{ role: "user", content: userPrompt }],
  fallbacks: [{ model: "claude-opus-4-8" }],
  betas: ["server-side-fallback-2026-07-01"],
});

// A fallback_message entry in usage.iterations means a fallback model
// ran; pair it with stop_reason to confirm it actually served the reply.
const fallbackRan = response.usage.iterations?.some(
  (i) => i.type === "fallback_message",
);
const servedByFallback = fallbackRan && response.stop_reason !== "refusal";

fallbacks accepts up to three models tried in order, and each entry must be a permitted fallback target for the model you called — that list is published per-model on the Models API.

A fallback only fires on a safety-classifier decline; a rate limit, overload, or server error on the primary model comes back to you unmodified, so your existing retry logic for those cases doesn't change.

Two pitfalls worth calling out explicitly: fallback configuration on a top-level request does not propagate into model calls your tools make internally, so subagent invocations need their own fallback setup.

And because a refusal is a 200, not a 5xx, dashboards built purely on HTTP error rates never see it — emit a dedicated event per refusal and per fallback-served response if you want visibility into how often your traffic is hitting classifiers.

Claude Opus 5 vs. the Rest of the Family

Model	Model ID	Context	Max output	Price (input/output per MTok)	Position
Claude Opus 5	claude-opus-5	1M (default = max)	128k (300k batch, beta)	$5 / $25	New default for agentic coding and enterprise work
Claude Opus 4.8	claude-opus-4-8	1M	128k	$5 / $25	Still available; common fallback target for Opus 5 and Fable 5 refusals
Claude Sonnet 5	claude-sonnet-5	1M (default = max)	128k	$2 / $10 intro through Aug 31, 2026, then $3 / $15	Cheapest per-token tier close to Opus 4.8 on many agentic tasks
Claude Fable 5	claude-fable-5	1M	128k	$10 / $50	Frontier ceiling; includes classifiers that can decline requests
Claude Mythos 5	claude-mythos-5	1M	128k	Not public	Limited release via Project Glasswing; no refusal classifiers

Pick Opus 5 as your default for coding agents, code review, document and spreadsheet generation, and enterprise workflows where near-frontier quality at half of Fable 5's price is the right trade — and note that on Frontier-Bench v0.1 and GDPval-AA specifically, Anthropic reports Opus 5 actually leading Fable 5, not just approaching it.

Reach for Fable 5 when a task genuinely needs the highest general-capability ceiling Anthropic offers — particularly cybersecurity and biology work — and you can handle classifier refusals as a normal response type in your integration.

Sonnet 5 is worth benchmarking against Opus 5 for high-volume, latency-sensitive pipelines — Anthropic positions it as landing close to Opus 4.8 on agentic work at a meaningfully lower price, so for some workloads it may be the better cost-performance point even against Opus 5.

Keep Opus 4.8 in your model roster even after migrating, since it's the documented fallback target when Opus 5's own classifiers fire. Full, current rate cards for every tier live on Anthropic's pricing page.

Best Practices

Start every workload at effort: "high" (the default) and run an evaluation sweep before stepping down — don't guess at the right level.
Hold effort constant within a single cached, multi-turn conversation. Vary it across workload types, not within one session, since changing it invalidates the cached prefix.
Size max_tokens for thinking plus response, not response alone, especially if you're migrating a workload that ran with thinking off on Opus 4.8.
Go generous with max_tokens — 64k as a starting point — whenever you run xhigh or max effort.
Configure fallback on every code path that calls the model, including retry handlers and subagent invocations, since it doesn't propagate automatically.
Prefer lowering effort over disabling thinking when you need cheaper responses; disabling thinking has real parsing edge cases at high effort levels.
Use mid-conversation system messages (and, once stable, mid-conversation tool changes) for anything you discover mid-session, instead of editing the top-level system or tools fields.

Common Mistakes

Treating effort as a token ceiling. It's a behavioral signal — Claude still reasons through hard problems at low effort, just less than at high. Pair it with max_tokens for an actual cap.
Reusing Opus 4.7/4.8 effort presets on Opus 5 without re-testing. Opus 5 responds more decisively to effort changes, so old presets may over- or under-shoot.
Assuming thinking can always be disabled. It can't at xhigh or max effort on Opus 5 — that combination returns a 400.
Carrying over a max_tokens value sized for a thinking-off Opus 4.8 workload. Thinking is on by default now, and it shares the same budget as the visible response.
Editing the top-level system field for a mid-session instruction. It quietly kills your cache hit rate for everything downstream; use a mid-conversation system message instead.
Handling a refusal in exception-handling code. It's a normal 200 response with stop_reason: "refusal" — check the field, don't wrap the call in a try/catch expecting an error.
Forgetting that fallback config doesn't reach into tool-triggered model calls. Subagents need their own fallbacks setup.

Performance Considerations

The effort ladder is your primary lever for cost and latency — reach for low or medium before considering a smaller model entirely, since Anthropic's benchmarks show Opus 5 holding strong quality at lower effort levels relative to its own higher settings.

Changing effort between requests in the same session breaks prompt caching, because effort shapes the rendered prompt. If a long agentic session relies on cache hits, pick one effort level at the start and keep it there for the life of that session.

A 1M-token context window doesn't make long context free. Uncached input still bills at full input-token rates on every request that includes it. For repeated large context — a repository, a document corpus, a long system prompt — enable caching explicitly (it's opt-in via cache_control) rather than assuming a large context window implies cheap reuse.

Fast mode is a genuine trade-off, not a free win: it's a research preview available for Opus 5 on the Claude API only (not Bedrock, Google Cloud, or Microsoft Foundry), running at roughly 2.5x the default token throughput for twice the base price — $5/$25 becomes $10 input / $50 output. Reach for it on latency-bound user-facing paths, not on cost-bound batch jobs.

For bulk, asynchronous workloads — nightly runs, large evals — the Message Batches API with the output-300k-2026-03-24 beta header raises your per-item output ceiling to 300k tokens, which is the better fit than pushing a synchronous request past its 128k limit.

Security Considerations

Safety classifiers are a defense-in-depth layer on Anthropic's side, not a substitute for your own sandboxing. If you're giving Opus 5 access to bash, computer-use, or code-execution tools, you still own the blast radius of what those tools can actually do — the classifier governs what Claude will attempt to generate, not what your tool implementation is capable of executing.

Handle stop_reason: "refusal" explicitly rather than letting it fall through generic error handling. A category: "cyber" refusal retried unmodified against the same model will refuse again; route it to your configured fallback instead, and log the category for visibility into what your traffic is actually triggering.

If your product does legitimate security research that keeps tripping the cyber classifier, Anthropic's Cyber Verification Program exists specifically to reduce those restrictions for vetted enterprises and researchers — that's the intended path, rather than trying to prompt around the classifier.

Mid-conversation system messages carry operator-level authority: Claude treats system-role content as coming from you, the application, not the end user. Never place raw tool output, retrieved documents, or other untrusted content directly in a system message — that hands it the same trust level as your own instructions, which is a textbook prompt-injection vector. Keep that content in tool_result blocks, where it's treated as data rather than instruction.

Consistent with prior Opus models, Opus 5 carries no data retention requirement for general API access. That's a reasonable default for most integrations, but confirm the specifics against Anthropic's current data processing agreement and trust center documentation for your actual compliance posture rather than treating it as a blanket guarantee.

Worth noting for anyone weighing model choice partly on safety grounds: Anthropic's own automated behavioral audit scores Opus 5 as its best-aligned model released so far, reporting fewer instances of dishonest behavior and a lower success rate for attempts to manipulate it into misuse compared with its current lineup.

That's a first-party audit, not an independent third-party assessment, so weigh it accordingly — but it's a relevant data point if safety posture factors into your model selection. Anthropic publishes the full methodology in the Claude Opus 5 system card.

Real-World Example: A Production PR-Review Agent

Here's a shape that pulls several of the pieces above together: an agent that reviews a pull request, adjusts effort based on diff size, caches its system prompt and tool definitions, and falls back to Opus 4.8 if a classifier flags anything mid-review.

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const REVIEW_TOOLS = [
  {
    name: "get_diff",
    description: "Fetch the unified diff for the pull request under review.",
    input_schema: {
      type: "object",
      properties: { pr_id: { type: "string" } },
      required: ["pr_id"],
    },
  },
  {
    name: "post_review_comment",
    description: "Post an inline comment on a specific file and line.",
    input_schema: {
      type: "object",
      properties: {
        file: { type: "string" },
        line: { type: "integer" },
        body: { type: "string" },
      },
      required: ["file", "line", "body"],
    },
  },
] as const;

const SYSTEM_PROMPT = `You are a senior code reviewer. Flag correctness bugs,
security issues, and missing tests. Skip style nits the linter already
catches. Be specific: cite the file and line for every comment.`;

async function reviewPullRequest(prId: string, diffSizeBytes: number) {
  // Larger diffs get more room to reason; small diffs stay cheap and fast.
  const effort = diffSizeBytes > 50_000 ? "xhigh" : "medium";

  const response = await anthropic.beta.messages.create({
    model: "claude-opus-5",
    max_tokens: effort === "xhigh" ? 64000 : 8192,
    // Automatic caching: the system prompt and tool definitions form a
    // stable prefix across every PR this process reviews, so only the
    // first call in a while pays full input-token price for them.
    cache_control: { type: "ephemeral" },
    system: SYSTEM_PROMPT,
    tools: REVIEW_TOOLS,
    output_config: { effort },
    messages: [
      {
        role: "user",
        content: `Review pull request ${prId}. Start by fetching the diff.`,
      },
    ],
    // If Opus 5's classifiers flag anything in the diff or the
    // generated comments, fall through to Opus 4.8 rather than
    // dropping the review entirely.
    fallbacks: [{ model: "claude-opus-4-8" }],
    betas: ["server-side-fallback-2026-07-01"],
  });

  if (response.stop_reason === "refusal") {
    // Every fallback in the chain also declined. Surface this distinctly
    // from a normal failure so it doesn't get silently retried.
    console.warn(`Review of ${prId} was declined:`, response.stop_details);
    return null;
  }

  return response;
}

A few things this example is doing deliberately. The effort level is decided per request based on diff size, not hardcoded — that's the primary cost lever, used before reaching for a cheaper model entirely.

cache_control is set explicitly, because caching on Opus 5 (like every current model) is opt-in, not automatic; without it, every PR review reprocesses the full system prompt and tool schema at full price. And the fallback chain means a classifier flag on a security-sensitive diff degrades to Opus 4.8 instead of failing the whole review pipeline — which matters if this runs unattended in CI.

In a real deployment you'd loop this around tool_use blocks until the model stops calling tools, and you'd insert a mid-conversation system message if, say, the diff turned out to exceed your token budget partway through — appended after the next tool result, not spliced into the top-level system field, so the cache built up over the loop survives.

FAQ

What is Claude Opus 5? It's Anthropic's newest Opus-tier model, released July 24, 2026, positioned as a near-frontier model for coding and enterprise work at half the price of Claude Fable 5, Anthropic's most capable generally available model.

How much does Claude Opus 5 cost? $5 per million input tokens and $25 per million output tokens — unchanged from Opus 4.8. Fast mode, a research preview available on the Claude API only, doubles both rates to $10/$50.

What's the difference between the effort parameter and thinking?thinking controls whether Claude reasons in visible thinking blocks before answering. effort controls how much total work goes into the whole response — thinking depth, tool-call count, and text length together. On Opus 5, effort is the primary control; thinking is on by default and mostly governed through effort rather than toggled directly.

Can I disable thinking on Claude Opus 5? Yes, but only when effort is high or below. Setting thinking: {"type": "disabled"} together with xhigh or max effort returns a 400 error — this is new behavior compared to Opus 4.8.

What's the context window size? 1M tokens, and it's both the default and the maximum — there's no smaller variant and no beta header required to reach it. Max output is 128k tokens per synchronous request, or up to 300k on the Batch API with a beta header.

How does Claude Opus 5 compare to Claude Fable 5? Fable 5 remains Anthropic's highest general-capability model, and Opus 5 is priced and positioned against it: close to Fable 5's frontier intelligence at half the cost. That framing undersells one detail — on specific coding and knowledge-work evaluations like Frontier-Bench v0.1 and GDPval-AA, Anthropic reports Opus 5 as the new leader, ahead of Fable 5 on those particular benchmarks.

Fable 5 still holds the edge on the hardest cybersecurity and biology work, and it ships with classifiers that can decline requests; Opus 5 triggers roughly 85% fewer of those interventions.

Is Claude Opus 5 available outside the Claude API? Yes — Amazon Bedrock (anthropic.claude-opus-5), Google Cloud (claude-opus-5), and Microsoft Foundry all support it. Fast mode, notably, does not extend to any of those three platforms yet.

How do I migrate from Opus 4.8 to Opus 5? Change the model string from claude-opus-4-8 to claude-opus-5, then check two things: whether your max_tokens values account for thinking now running by default, and whether you disable thinking at xhigh or max effort anywhere, which will start failing with a 400. Anthropic's migration guide walks through both checks in more detail.

Conclusion

The headline number — half of Fable 5's price at near-Fable-5 capability — is the easy part of this release to explain and the least useful part to build against blindly.

The parts that actually change your integration are structural: effort as a single unified cost dial, thinking flipped on by default with a real breaking change around disabling it, and two new mechanisms for keeping your prompt cache alive as sessions get longer and tool access changes mid-flight.

None of that requires a rewrite. It requires reading the migration notes before you swap the model string, sizing max_tokens for a model that thinks by default, and treating effort as the lever you reach for before you reach for a different model entirely.

Do that, and Opus 5 is a reasonable new default for the agentic and coding workloads most teams are already running on Opus-tier models — not because it's the smartest thing Anthropic has shipped, but because it's the one built to be used every day.

Key Takeaways

Claude Opus 5 (claude-opus-5) costs $5/$25 per million input/output tokens — the same as Opus 4.8 — while Anthropic reports it leading Fable 5 on coding and knowledge-work evaluations specifically, even though Fable 5 remains the higher general-capability model.
The output_config.effort parameter is a single dial (low to max) that governs thinking, tool calls, and text together; it's a behavioral signal, not a hard token budget.
Thinking runs on by default on Opus 5, unlike Opus 4.8 — revisit max_tokens on any migrated workload, since it's now a ceiling on thinking plus response combined.
thinking: {"type": "disabled"} only works at high effort or below; combining it with xhigh or max returns a 400.
The context window is a flat 1M tokens (default and max), with 128k max output synchronously or 300k on the Batch API via a beta header.
Refusals are normal 200 responses with stop_reason: "refusal", not errors — configure fallbacks explicitly, including for subagent calls, since it doesn't propagate automatically.
Mid-conversation system messages, and the new mid-conversation tool-changes beta, let you add instructions or tools partway through a session without invalidating your prompt cache.
Keep Opus 4.8 in your model roster: it's the documented fallback target when Opus 5's own safety classifiers flag a request.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

How Netflix's Architecture Works in 2026: A Developer's Guide

Bhavya Arora — Mon, 31 Aug 2026 06:45:49 +0000

Netflix isn't running the architecture most developers remember.

The company that became famous for Eureka, Hystrix, Ribbon, Zuul and Titus has spent years replacing, reshaping, or moving responsibilities out of those systems. Today, its publicly described architecture is a combination of EKS, Envoy-based service networking, Open Connect, federated APIs, specialized storage abstractions, modern video codecs, recommendation systems, and increasingly sophisticated AI infrastructure.

That's what makes Netflix interesting from an engineering perspective. The important story isn't one magical "Netflix stack." It's how the architecture keeps changing when the scale, failure modes, or organizational constraints change.

The shape of it

One important distinction gets lost in many simplified diagrams: Netflix's streaming data plane and application/API plane are separate paths.

Streaming data plane

Application and control plane

Both diagrams are intentionally simplified. Netflix runs many individual services and infrastructure components behind each box.

The key point is that pressing Play does not mean your video travels through GraphQL, then through a database, and finally comes back from a microservice. The API/control systems help coordinate the experience; Open Connect handles the actual video delivery path.

It started with a broken database

Netflix's cloud journey didn't begin with a grand strategy — it began with a three-day outage.

In August 2008, a corrupted Oracle database disrupted Netflix's DVD-shipping business for three days. At the time, Netflix was operating a conventional data-center architecture, with a major dependency on vertically scaled relational databases.

That failure pushed Netflix toward a much bigger bet: move to the public cloud and redesign the application around distributed services.

The migration began in 2009 and took roughly seven years, completing in January 2016. Netflix did not simply lift its existing application into AWS. It progressively decomposed major parts of the system and rebuilt them around services designed to scale horizontally and tolerate infrastructure failures. Netflix: Completing the Cloud Migration

A second incident, involving AWS infrastructure failures around Christmas 2012, reinforced another lesson: cloud infrastructure itself could fail.

That forced Netflix to think beyond individual application failures and design for failures involving infrastructure components, availability zones, and eventually entire regions.

That's the backdrop for much of the resilience and deployment engineering that followed.

The famous Netflix OSS stack evolved, rather than simply disappearing

If you've studied microservices patterns, you've probably encountered Netflix's original OSS stack:

Eureka for service discovery, Ribbon for client-side load balancing, Hystrix for circuit breaking, and Zuul for edge routing.

These projects were built for a particular moment: a large Java fleet running on AWS, where application-embedded libraries solved networking and resilience problems that the wider cloud ecosystem had not yet standardized.

Then the architecture evolved.

Hystrix and Ribbon entered maintenance mode. Zuul 1 was followed by Zuul 2, which moved toward an asynchronous, non-blocking architecture. Meanwhile, Netflix shifted more service-to-service networking responsibilities into an Envoy-based service-mesh architecture. Spring Cloud Netflix: Modules in Maintenance Mode

But Eureka should not be grouped with those retired components.

Netflix's service-mesh architecture has continued to use Eureka's service-discovery information as an input to its mesh control plane. Envoy handles networking at the proxy layer; Eureka remains part of the service-discovery story. In other words, Netflix did not simply replace Eureka with Envoy. Netflix: Zero Configuration Service Mesh with On-Demand Cluster Discovery

The stack, then and now

Concern	Earlier Netflix approach	More recent direction
Service discovery	Eureka	Eureka integrated with mesh control-plane systems
Client-side load balancing	Ribbon	Envoy / mesh-based networking
Circuit breaking / overload protection	Hystrix and application logic	Adaptive concurrency and service-level resilience
Edge routing	Zuul 1	Zuul 2 and newer networking layers
Service-to-service networking	Client libraries	Envoy-based service mesh

The lesson isn't "don't use Netflix OSS."

It's that even Netflix treats infrastructure components as replaceable implementations of longer-lived engineering concerns.

Service discovery stays important. Routing stays important. Fault isolation stays important. Load management stays important.

The tools can change.

Containers: Netflix's 2025 move from Titus to EKS

Netflix built its own container orchestration platform, Titus, rather than adopting early Kubernetes.

That was a reasonable decision at the time. Titus was built around Netflix's own operational requirements and gave the company deep control over scheduling, EC2 capacity management, networking, and large-scale workloads.

Titus carried Netflix workloads for years.

Then, in 2025, Netflix migrated its container fleet to Amazon EKS.

The scale is remarkable. AWS says Netflix now runs fewer than 20 production clusters across four regions, with individual clusters reaching roughly 10,000 large instances and 80,000 pods. During peak events, Netflix may need to launch around 70,000 containers in five minutes. AWS also says the migration followed about nine months of preparation, with the fleet moved in a single quarter.

The interesting lesson isn't "Kubernetes won."

It's that the operational systems Netflix built around Titus — capacity management, disruption budgets, automation, and fleet-wide practices — mattered more than the scheduler underneath them.

Those practices survived the platform migration.

That is a useful lesson well beyond Netflix:

Good infrastructure practices should survive a change of infrastructure.

Shipping code without breaking things

Continuous delivery at Netflix runs on Spinnaker, the open-source multi-cloud deployment platform Netflix began developing around 2015 and later developed with Google and the wider community.

Spinnaker turns a deployment into a controlled pipeline: build an artifact, run required checks, deploy to a limited population, measure the result, and progressively promote the change when its health looks acceptable.

Netflix has also pushed the idea further with Managed Delivery, where teams express desired deployment state and policy instead of manually assembling every deployment step.

That fits a larger evolution in infrastructure:

Move from imperative instructions toward declarative intent.

Rather than telling a platform exactly how every deployment should happen, teams describe what must be true for a deployment to be considered safe.

The platform can then work out the path.

Making sense of the data

Netflix doesn't run one database — it runs many, behind abstractions designed to keep application teams from having to understand the implementation details of every storage system.

Netflix has described a Data Gateway approach that exposes purpose-built storage APIs rather than making every application directly dependent on a particular persistence technology.

Different workloads can therefore use different physical storage systems underneath.

Those systems have included Cassandra, DynamoDB, RocksDB, Elasticsearch, CockroachDB, and relational databases for workloads where transactional guarantees matter more than extreme horizontal scale.

The point is not that Netflix found one "best database."

It did almost the opposite.

It created ways for teams to use storage according to the workload rather than forcing every service into the same persistence model.

A simplified conceptual example — not a Netflix configuration — might look like this:

namespace: user-watch-progress
consistency: read-your-writes
storage:
  durable_store: cassandra
  cache: evcache

One recurring pattern is separating durable storage from high-speed caching. EVCache, Netflix's Memcached-based caching layer, can absorb large read volumes while systems such as Cassandra handle durable writes.

Netflix's Real-Time Distributed Graph shows what this looks like at extreme scale. Netflix has publicly described a graph containing more than 8 billion nodes and 150 billion edges, backed by about a dozen Cassandra clusters and capable of sustaining millions of reads and writes per second.

The broader lesson is simple:

Scale the hot path independently from the durable path when the workload demands it.

One graph to power many APIs

Netflix's API layer went through its own evolution.

Earlier in the architecture, client teams — iOS, Android, TV, web and others — could build their own backend-for-frontend logic using Falcor, Netflix's data-fetching technology, behind the edge layer.

That worked technically, but organizational growth created another problem: different client teams could end up rebuilding similar aggregation logic in slightly different ways.

Netflix's later GraphQL Federation architecture attacked that problem by allowing backend teams to own domain-specific pieces of a larger graph.

Individual Domain Graph Services (DGS) can own their piece of the schema, while the federated platform composes those domains into a unified graph that clients can query. Netflix: How Netflix Scales Its API with GraphQL Federation

The important benefit isn't simply "GraphQL instead of REST."

It's organizational:

Teams can own their slice of the API while clients still see one coherent interface.

That becomes increasingly valuable when the organization, not just the traffic volume, becomes the scaling problem.

Getting the bits to your screen

Open Connect is Netflix's purpose-built content-delivery network, and it works differently from a conventional centralized CDN.

Netflix places servers close to viewers, including directly inside ISP networks, so popular content can be served locally instead of repeatedly traveling across long-distance network paths.

Netflix has publicly described Open Connect at a scale of roughly 18,000 servers across 6,000 locations in 175 countries.

Those figures matter because they are often misstated as "6,000 appliances." The publicly reported numbers are servers and locations.

The playback flow is intentionally simple:

A client requests playback.
A Steering Service determines an appropriate delivery location.
The client streams video segments from Open Connect.

The more interesting part is what happens when central connectivity fails.

Netflix has designed Open Connect so that the control plane and data plane can fail somewhat independently. An appliance that loses contact with central Netflix systems can continue serving content it already has rather than becoming immediately useless.

That's a powerful resilience principle:

When the control plane disappears, the data plane should continue doing useful work whenever possible.

Netflix has also described Open Connect as helping avoid sending every byte of streaming traffic through its own cloud infrastructure.

Squeezing more picture into fewer bits

Encoding is where a large part of Netflix's infrastructure investment quietly turns into lower bandwidth requirements and better playback.

Per-title encoding stopped treating every movie and episode as though it needed the same bitrate ladder. A dialogue-heavy drama, a dark film, and a fast-moving action sequence can have very different compression characteristics.

Netflix's subsequent encoding research reported substantial bitrate reductions from content-aware encoding approaches, including later improvements that reduced average bitrate by more than 20% in tested pipelines while maintaining comparable perceived quality.

The current frontier is AV1.

By late 2025, Netflix reported that AV1 represented roughly 30% of all Netflix viewing, making it the company's second-most-used codec and putting it on track to become number one. Netflix: AV1 Now Powering 30% of Netflix Streaming

One particularly interesting development is Film Grain Synthesis.

Film grain is expensive to encode because it behaves a lot like noise: tiny variations appear throughout the image and are difficult to compress efficiently.

Instead of encoding all of that grain literally, Netflix can remove much of it before encoding and send information that allows the decoder to reconstruct a convincing approximation.

The savings can be dramatic on the right content.

In one Netflix example involving heavily grainy footage, Film Grain Synthesis reduced bitrate from roughly 8.3 Mbps to 2.8 Mbps, about a 66% reduction, while producing better-looking grain than the conventional AV1 encode.

That should be understood as a specific example, not a universal 66% saving across Netflix's catalog.

Netflix also uses VMAF, its perceptual video-quality metric, to evaluate whether lower bitrate still produces acceptable visual quality.

That's an important distinction.

A smaller file is only an improvement if the viewer can't tell that quality was lost.

Breaking things on purpose

Netflix popularized chaos engineering with Chaos Monkey in 2010.

The idea was deliberately uncomfortable: randomly terminate production instances during normal operation so engineers would discover weak assumptions before a real infrastructure failure exposed them.

The philosophy changes the question from:

"What happens if this server dies?"

to:

"Have we proved that our system can survive when this dependency disappears?"

Netflix later extended the idea with Chaos Kong, which tested failure scenarios involving entire AWS regions.

The resilience discipline has also expanded beyond chaos experiments.

More recent Netflix reliability work emphasizes prioritized load shedding: when traffic threatens to overwhelm a service, lower-value requests should be rejected or delayed before higher-value requests are harmed.

A background synchronization job and a request to start playback do not have equal business value.

A resilient system should know that.

The stress test: live sports and events

Nothing exposes architecture gaps like a live event with a hard start time and no opportunity to spread the load gradually.

In November 2024, Netflix's live exhibition boxing match between Mike Tyson and Jake Paul attracted an estimated 108 million live global viewers and peaked at 65 million concurrent streams. The event also generated substantial public complaints about buffering and interruptions.

The event mattered because live streaming behaves differently from on-demand playback.

Millions of people can suddenly request content at roughly the same time.

Netflix's later NFL broadcasts provided another major test. By Christmas 2025, the Lions-Vikings game averaged 27.5 million U.S. viewers, peaked above 30 million during the halftime show, and reached a 30.5 million global average minute audience.

Netflix has also described improvements to its live-video origin architecture, including separation of read-heavy and write-heavy paths and priority-based rate limiting so lower-priority work does not crowd out traffic needed for real-time playback.

That pattern is bigger than sports:

When workloads compete, protect the requests that matter most instead of treating every request equally.

Teaching the algorithm

Netflix's personalization architecture has also evolved from collections of narrowly focused models toward more unified approaches.

Different recommendation surfaces historically relied on specialized models. One system could rank a homepage row while another ranked search results or helped determine when to send a notification.

More recent Netflix research has described Hydra, a multi-task learning approach that consolidates related personalization and ranking objectives around shared representations instead of maintaining every task as a completely isolated model.

That does not mean Netflix replaced every recommendation system with one giant model.

The useful architectural lesson is narrower:

Share learned representations and infrastructure when multiple ML tasks are solving closely related problems.

The benefit is not just model quality. It can also reduce the operational cost of training, deploying, and maintaining many separate systems.

Serving AI models in production

Serving AI models at Netflix's scale requires infrastructure of its own.

Netflix's AI infrastructure work initially evaluated and used TensorRT-LLM together with Triton. As workloads expanded beyond straightforward text generation to include ranking, retrieval, and embedding workloads, Netflix benchmarked alternative serving systems and moved toward vLLM as a default inference engine for its paved-path serving architecture.

That's another useful Netflix pattern.

The company is famous for building its own infrastructure, but it doesn't build everything merely for the sake of ownership.

When an open-source project becomes capable enough to satisfy the workload, adopting it can be the better engineering choice.

Sometimes the best infrastructure decision is not to build another internal platform.

What developers can actually steal from Netflix

Most teams will never operate at Netflix's scale, and copying Netflix's exact tools would be a mistake.

Titus and Open Connect exist because of constraints most companies simply don't have.

The patterns underneath them travel much better than the products themselves.

Tools are disposable; the problems they solve aren't.

Netflix has changed its implementation of service discovery, routing, resilience, and scheduling without abandoning those underlying concerns.

Separate read and write paths when they need to scale independently.

EVCache and Cassandra are one example of a broader principle: don't force radically different workloads through the same bottleneck.

Decouple control planes from data planes where failure is expensive.

Open Connect can continue serving cached content even when central control connectivity is impaired.

Practice failure before it practices on you.

Chaos engineering turns catastrophic surprises into rehearsed scenarios.

Boring technology is still the right call somewhere.

A transactional workload doesn't become better simply because its database sounds more sophisticated.

Give teams ownership of their API domains.

Federated GraphQL is valuable not because GraphQL is magical, but because API ownership can scale with the organization instead of funneling every change through one central team.

Protect high-value traffic first.

Prioritized load shedding is useful anywhere a sudden traffic spike can turn "everything is slow" into "everything is down."

The architecture keeps changing

If you remember one thing about Netflix's architecture, make it this:

There is no single timeless "Netflix stack."

The company moved from a conventional data center to AWS, from a monolithic system toward distributed services, from application-embedded resilience libraries toward service-mesh infrastructure, from Titus to EKS, from conventional content delivery toward a deeply distributed Open Connect network, and from collections of specialized ML systems toward increasingly shared AI infrastructure.

The individual technologies will keep changing.

The engineering constraints won't:

scale, failure, latency, organizational ownership, and cost.

That's the part worth copying.

AirLLM: Running Giant AI Models on Everyday Hardware

Bhavya Arora — Thu, 27 Aug 2026 12:49:40 +0000

The Problem Nobody Wanted to Talk About

For most of the past few years, the conversation around large language models has been dominated by capability benchmarks and API releases. What got less attention was a growing divide: the gap between what the models could do and who could actually run them.

Models like LLaMA 3 70B or DeepSeek-V3 demand enormous amounts of GPU memory — often 140GB or more of VRAM at full precision. The most powerful consumer GPU on the market, NVIDIA's RTX 4090, ships with just 24GB. Most developers have 4GB, 8GB, or 16GB setups. For anyone outside a well-funded research lab or a cloud-compute budget, experimenting with frontier open-source models was simply off the table.

AirLLM changes that.

What Is AirLLM?

AirLLM is an open-source Python library — built by developer Gavin Li (lyogavin) — that lets you run extremely large language models on consumer-grade hardware with very limited GPU memory. We're talking 70B parameter models on a single 4GB GPU. 405B parameter models on 8GB VRAM. And as of mid-2026, even Kimi K3 (a 2.8 trillion parameter sparse MoE model, the largest open-source model released to date) on under 4GB of VRAM.

No quantization tricks required (though optional compression is available). No accuracy loss from model distillation. No need for a multi-GPU server.

First released in November 2023, AirLLM has rapidly gathered community momentum, crossing 21,000+ GitHub stars and expanding support to include some of the most widely used open model families.

The Core Idea: Layer-by-Layer Inference

The innovation at AirLLM's heart is elegantly simple: instead of loading an entire model into GPU memory at once, it processes the model one transformer layer at a time.

Here's what that looks like under the hood:

AirLLM loads the first transformer layer from disk (or system RAM) into VRAM.
It runs the forward computation for that layer on the input tensor.
It offloads that layer from VRAM.
It loads the next layer and repeats until the full forward pass is complete.
The final output — a probability distribution over the vocabulary — yields the next token.

From the user's perspective, the output is identical to what you'd get from a fully loaded model. The model's weights are never modified, so there's no accuracy compromise baked into the architecture itself.

The technique isn't brand new — sequential layer offloading has appeared in academic research before — but AirLLM made it practical, packaged it cleanly, and put it in the hands of everyday developers.

Key Features

Layer-Wise Streaming Execution — The foundational innovation. Only one layer occupies VRAM at any given moment, making enormous models accessible on minimal hardware.

Optional Block-Wise Quantization — AirLLM v2.0 introduced compression based on block-wise quantization of weights (not activations, which is an important distinction). This can deliver up to a 3x inference speedup with minimal accuracy loss. A 70B model's layer shards drop from ~140GB to ~18GB with 4-bit compression. You can enable it with a single parameter:

model = AutoModel.from_pretrained(
    "meta-llama/Llama-3-70B-Instruct",
    compression='4bit'  # or '8bit'
)

Prefetching — Added in v2.5, this overlaps model loading and computation, squeezing out an additional ~10% speed improvement.

AutoModel API — Since v2.6, AirLLM can automatically detect the model type without you specifying a class manually. It integrates directly with Hugging Face Hub — AutoModel.from_pretrained() handles weight downloading, layer partitioning, and memory orchestration automatically.

Apple Silicon Support — AirLLM supports Apple's M-series chips via the MLX framework. Because M-series chips use unified memory shared between CPU and GPU, MacBook Pro and Mac Studio users can potentially run very large models without hitting the traditional VRAM ceiling.

CPU Inference — Since August 2024, any x86_64 CPU is a valid inference target. Slower, yes — but useful for environments without a GPU.

FP8 Support (v3.0) — June 2026 brought v3.0 with FP8 model precision support, enabling even more efficient inference alongside expanded support for the latest generation of models.

MoE Expert-Level Streaming — For sparse mixture-of-experts models like DeepSeek-V3 and Kimi K3, AirLLM streams individual experts rather than whole layers, meaning only the experts a given token actually routes to are ever loaded.

Supported Models

AirLLM supports a broad range of decoder-only models via Hugging Face compatibility. The current list includes:

LLaMA family (LLaMA 2, 3, 3.1, 3.3, and 4 — including the 405B variant)
Mistral and Mixtral (via AirLLMMixtral)
Qwen, Qwen 2.5, and Qwen3 (including Qwen3-235B, runnable on ~3GB VRAM)
DeepSeek (V2, V3 at 671B on ~12GB VRAM, and R1)
Kimi K3 (2.8T sparse MoE, on ~3.72GB VRAM)
Phi (including Phi-4)
Gemma
ChatGLM, Baichuan, InternLM, Yi

Support has expanded significantly since launch. As of v3.1.0, the library is generally compatible with virtually any popular model on Hugging Face — just pass the repo ID to AutoModel.from_pretrained(). Here's a rough guide to VRAM requirements:

Model	Size	VRAM needed
Qwen3 / Mistral / Phi (~8B)	8B	~1–2 GB
Qwen3-30B / Mixtral (MoE)	30–47B	~1–3 GB
Qwen3-235B (MoE)	235B	~3 GB
LLaMA 3.x 70B (full precision)	70B	~4 GB
LLaMA 3.1 405B	405B	~8 GB
DeepSeek-V3	671B	~12 GB
Kimi K3 (MoE)	2.8T	~3.72 GB

Getting Started

Installation is a single command:

pip install airllm

A minimal working example looks like this:

from airllm import AutoModel

# Load a 70B model — AirLLM handles everything else
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3-70B-Instruct")

# Use the standard Hugging Face tokenizer
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-70B-Instruct")

# Tokenize and generate
inputs = tokenizer("Explain quantum entanglement simply:", return_tensors="pt")
output = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(output[0]))

That's it. No custom CUDA kernels. No manual memory management. If the model is on Hugging Face, AirLLM downloads and partitions it automatically.

Note: Gated models require a Hugging Face token via the hf_token parameter.

The Real Trade-Off: Speed

It wouldn't be honest to write about AirLLM without being direct about this: token generation is slow.

Each layer transfer from disk to VRAM introduces I/O overhead. The speed depends heavily on your storage medium — an NVMe SSD will dramatically outperform a mechanical hard drive — but even under ideal conditions, AirLLM is not competing with optimized inference servers on throughput. It is not the right tool if you need a low-latency chatbot serving many users, or a high-frequency production API.

This is a deliberate trade-off: accessibility over speed. If that trade-off works for your use case, AirLLM is genuinely powerful.

Who Should Use AirLLM?

Researchers on a hardware budget — If you want to probe the internals of a 65B-parameter model on a single consumer GPU without buying enterprise hardware, this is probably the most practical path available.

Privacy-conscious teams — Document analysis pipelines where sending text to a third-party API is off the table due to compliance or data sensitivity. Running locally means your data stays local.

Learners and hobbyists — If you're trying to understand how large transformer architectures behave, AirLLM lets you run and experiment with models you'd otherwise never touch.

Offline evaluation and benchmarking — Comparing model outputs across architectures without spinning up cloud infrastructure.

Who probably shouldn't use it — If you're building a real-time user-facing application, or a service that needs to handle concurrent requests with low latency, tools like vLLM, TensorRT-LLM, or llama.cpp are better choices. AirLLM doesn't compete with them on throughput.

Why It Matters Beyond the Technical Details

There's a broader point here worth sitting with.

The AI landscape has increasingly consolidated around a small number of organizations with enormous GPU clusters. Access to frontier models — even open-weight ones — has often been gated by the hardware required to run them. That reality shapes who gets to experiment, who gets to learn, and ultimately who gets to build.

AirLLM doesn't close that gap entirely. But it meaningfully shifts the boundary. A developer with a mid-range laptop can now load and query a 70B parameter model locally. A small research team without a cloud budget can benchmark model behavior on hardware they already own. A company with strict data residency requirements can run local inference without a six-figure GPU investment.

That kind of democratization is quiet, unglamorous, and genuinely important.

The Road So Far (A Brief Timeline)

Date	Milestone
November 2023	Initial release — 70B inference on a 4GB GPU via layer streaming
December 2, 2023	v2.0 — Block-wise quantization, 3x speedup; ChatGLM, Qwen, Baichuan, Mistral, InternLM support added
December 2023	v2.5 — Prefetching for 10% additional speed; v2.6 — AutoModel API
December 25, 2023	v2.8.2 — MacOS support for Apple Silicon (M1/M2/M3)
April 2024	LLaMA 3 support — run LLaMA 3 70B on a single 4GB GPU
July 2024	LLaMA 3.1 405B support; optional 4-bit/8-bit quantization
August 18, 2024	v2.10.1 — CPU inference support (any x86_64 CPU)
September 21, 2024	v2.11.0 — Qwen 2.5 support added
June 30, 2026	v3.0 — FP8 model support; DeepSeek-V3 (671B) on ~12GB, Qwen3-235B on ~3GB; Llama 3.3/4, Phi-4, DeepSeek R1/V2/V3 added
July 29, 2026	v3.1.0 — Kimi K3 (2.8T) support; runs on 3.72GB VRAM — largest open-source model to date

Final Thoughts

AirLLM is not magic. It doesn't make a 70B model run as fast as a dedicated inference server. What it does do is remove the barrier that said "you need $50,000 of hardware before you can even start."

For researchers, learners, privacy-first teams, and curious developers, that removal is significant. In a field where the hardware gap often determines who gets to participate, tools like AirLLM represent a small but meaningful push toward a more accessible AI ecosystem.

If you've been waiting for the right moment to run a large open-source model locally — this might be it.

Resources

GitHub: https://github.com/lyogavin/airllm
PyPI: https://pypi.org/project/airllm/
Hugging Face: search for models compatible with AirLLM directly on the Hub

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Stop Using useEffect for Data Fetching: A Modern React Architecture Guide

Bhavya Arora — Wed, 26 Aug 2026 10:19:58 +0000

If you review a React codebase written a few years ago, you will inevitably find components littered with code that looks exactly like this:

const UserProfile = ({ userId }) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    setLoading(true);

    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(userData => {
        if (isMounted) {
          setData(userData);
          setLoading(false);
        }
      })
      .catch(err => {
        if (isMounted) {
          setError(err.message);
          setLoading(false);
        }
      });

    return () => { isMounted = false; };
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <ErrorMessage text={error} />;
  return <div>{data.name}</div>;
};

This is how we were all taught to write React. It feels intuitive. You mount a component, trigger a side-effect to get data, and save it to state.

In 2024, this is universally considered an anti-pattern. The React core team actively advises against doing this.

Let's dissect exactly why this approach is fundamentally flawed, and how modern query libraries solve these problems elegantly.

The Four Fatal Flaws of `useEffect` Fetching

1. The Race Condition Nightmare

Imagine the user clicks "Profile A", and your useEffect fires a network request. It's taking a while. Impatient, the user clicks "Profile B". A second request fires.

If the server processes Profile B quickly, it returns first. The UI updates to Profile B. Then, the slow request for Profile A finally returns. The setState triggers, and the UI visually reverts to Profile A, even though the user is currently "looking" at Profile B!

You can fix this with isMounted boolean tracking flags or AbortController, but you are now writing complex async state machines manually.

2. The Strict Mode "Double Fetch"

If you upgrade to React 18, React's Strict Mode aggressively mounts, unmounts, and remounts your components in development to expose bugs. This means your useEffect fires twice, hammering your API backend and flooding your network tab.

3. Cache Misses and Waterfall Loading

When a user navigates from the Dashboard to the Settings page, the Dashboard unmounts. The data state is destroyed. When they navigate back 3 seconds later, the useEffect runs again. The user stares at a loading spinner for data they literally just saw.

Worse, if ParentComponent fetches a User, and ChildComponent fetches the User's Posts, they execute sequentially. The Child waits for the Parent to finish before it even starts fetching. This is the dreaded "Network Waterfall."

4. Boilerplate Hell

Tracking data, isLoading, and error variables requires dozens of lines of code. Multiply that across 50 components, and your codebase is drowning in repetitive state management.

The Solution: Specialized Query Libraries

Data fetching is a complex engineering problem involving caching, background revalidation, stale-time policies, and retry logic. You should not write this yourself.

The industry standard is to use a specialized library: TanStack Query (React Query) for REST APIs, or Apollo Client for GraphQL.

Here is the exact same component rewritten with Apollo Client:

import { useQuery, gql } from '@apollo/client';

const GET_USER = gql`
  query GetUser($userId: ID!) {
    user(id: $userId) {
      id
      name
    }
  }
`;

const UserProfile = ({ userId }) => {
  const { data, loading, error } = useQuery(GET_USER, {
    variables: { userId }
  });

  if (loading) return <Spinner />;
  if (error) return <ErrorMessage text={error.message} />;
  return <div>{data.user.name}</div>;
};

It is beautiful, concise, and eliminates 90% of the boilerplate. But the real power is under the hood.

Why this architecture is vastly superior:

1. Instant Cache Retrieval

Apollo Client and TanStack Query maintain a normalized, global memory cache. If you navigate away from the Dashboard and return, the library instantly serves the data from memory. There is zero loading spinner. It then silently triggers a background network request (stale-while-revalidate) and updates the UI if the data changed.

2. Automatic Race Condition Resolution

If userId changes rapidly, the library tracks the request IDs. It mathematically guarantees that only the data belonging to the latest request will ever be passed to the component, completely eliminating async race conditions.

3. Global State Synchronization

Because the cache is centralized, you don't need Redux or Context to share data.

If your Navbar component queries the user's name, and your ProfileSettings component executes a mutation to change that name, the cache updates instantly. The Navbar automatically re-renders with the new name without you writing a single line of state synchronization code.

4. Automatic Retries and Deduplication

If the user's internet drops while on a train, the query will automatically retry 3 times with exponential backoff before throwing an error. Furthermore, if three different components on the screen all call useQuery(GET_USER), the library deduplicates them and only sends one network request to your server.

Conclusion

useEffect was designed to synchronize React components with external systems (like attaching a DOM event listener or connecting to a WebSocket). It is a low-level primitive, not a data-fetching solution.

By adopting a robust Query library, you delete hundreds of lines of boilerplate, vastly improve the user experience with instant caching, and permanently eliminate the most common async bugs in React development.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

DEV Community: Bhavya Arora

The 15 Git Commands That'll Save Your Sanity (and Your Code)

The Git Mental Model

1. git init

2. git clone

3. git status

4. git add

5. git commit

6. git branch

7. git checkout, git switch, and git restore

8. git merge

9. git push

10. git pull

11. git log

12. git diff

13. git stash

14. git reset and git revert

git reset

git revert

15. git remote

Five Habits That Make Git Much Easier

Check before you change things

Keep commits focused

Use .gitignore early

Treat force-push as an exception

Practice recovery, not memorization

Git Commands by Situation

Quick-Reference Cheat Sheet

Where to Go From Here

Zero-Downtime Deployments: Strategies and Tradeoffs

Why Downtime Happens in the First Place

Strategy 1: Blue-Green Deployments

How it works

Real example

Tradeoffs

Strategy 2: Rolling Deployments

How it works

Real example

Tradeoffs

Strategy 3: Canary Releases

How it works

Real example

Tradeoffs

Strategy 4: Feature Flags (The Invisible Deploy)

How it works

Real example

Tradeoffs

The Hard Part: Database Migrations

The expand-contract pattern

What to avoid

Putting It Together: A Decision Framework

Checklist Before Your Next Deploy

Code Examples

Final Thought

Local HTTPS Done Right: Wildcard SSL for Modern Development

The Secret Weapon: mkcert

Step 1: Install mkcert

Step 2: Initialize Your Local CA

Step 3: Generate the Wildcard Certificate

Step 4: Map Local DNS

Step 5: Implementation

Approach A: Using Docker and Nginx (Recommended)

Approach B: Native Node.js (Next.js / Vite)

Crucial Tip: Node.js Backend-to-Backend Requests

Conclusion

LongCat-2.0: The AI Model You Were Already Using. Built By The Company That Delivers Your Dinner.

The Reveal

Meet Owl Alpha

The Detective Work

This Playbook Isn't New. The Patience Is.

What's Actually Inside It

The Benchmarks — Read the Fine Print

The Price Is the Actual Headline

The Chip Story Nobody Should Skip

What's Still Soft

Bottom Line

What AI Still Cannot Do: Four Boundaries the 2026 Benchmarks Keep Finding

The benchmark built to find the ceiling

1. Long tasks are getting longer, but "long" is not "real"

2. Reasoning still collapses once problems get hard enough

1. `git init`

2. `git clone`

3. `git status`

4. `git add`

5. `git commit`

6. `git branch`

7. `git checkout`, `git switch`, and `git restore`

8. `git merge`

9. `git push`

10. `git pull`

11. `git log`

12. `git diff`

13. `git stash`

14. `git reset` and `git revert`

`git reset`

`git revert`

15. `git remote`

Use `.gitignore` early