DEV Community: Arindam Majumder

A Beginner's Guide to GitHub Stacked PRs

Arindam Majumder — Fri, 07 Aug 2026 18:21:14 +0000

Large pull requests are difficult to review well.

They combine too many concerns, make feedback harder to act on, and often leave reviewers deciding where to start.

GitHub Stacked PRs offers a more deliberate workflow: split one large change into a sequence of small, dependent pull requests (PRs) that can be reviewed independently.

In this tutorial, you will learn what stacked PRs are, when to use them, and how to manage a complete stack using GitHub CLI. We will use a small authentication feature as an example, breaking it into database, API, and interface layers.

If you need a visual demonstration, I have also made a video walkthrough of this workflow.

What Are GitHub Stacked PRs?

A stacked pull request is a chain of two or more PRs in the same repository. The bottom PR targets your trunk branch, usually main, and every PR above it targets the branch directly below it.

For example, an authentication feature might be organized like this:

feat/login-ui        → PR #3 (base: feat/auth-api)
feat/auth-api        → PR #2 (base: feat/user-model)
feat/user-model      → PR #1 (base: main)
main

Each layer contains one discrete, reviewable change. A reviewer opening feat/auth-api sees the API work introduced by that layer, not the database work already included in feat/user-model.

GitHub also displays the stack relationship in the pull request interface, so the full context remains available.

This differs from simply splitting a feature into arbitrary branches. The order matters: a layer can depend on code in the same branch or a lower branch, but not on code higher in the stack. Put foundational work, such as schema changes and shared types, near the bottom; put code that consumes those foundations, such as endpoints and UI components, above it.

Why Use Stacked PRs?

Stacked PRs are useful when a change is too large for one focused review but its pieces must be developed in order. They let you open the first layer for review and immediately continue building the next layer instead of waiting for a merge.

The main benefits are:

Smaller, more focused diffs: Reviewers can concentrate on one concern at a time.
Earlier feedback: You can request feedback on a data model or API contract before the rest of the feature is complete.
Clearer dependencies: The branch structure documents which work builds on which foundation.
Safer high-volume development: This is especially helpful when coding agents generate a larger feature in several logical steps.
Less manual Git work: GitHub can cascade rebases through a stack when lower layers change or merge.

Stacks are not the right answer for every change. Use a normal PR for a small, self-contained fix. A stack adds coordination overhead, so its layers should be meaningful on their own, not tiny fragments created only to increase the number of PRs.

Prerequisites

Before starting, make sure you have:

A GitHub repository with a default branch such as main.
GitHub CLI version 2.0 or later installed and authenticated. If needed, run gh auth login.
The GitHub Stacked PRs extension installed:

gh extension install github/gh-stack

GitHub Stacked PRs is currently in public preview, so the interface and commands may evolve. All branches in a stack must also live in the same repository; cross-fork stacks are not supported.

Create Your First Stack

We will create a three-layer stack for an authentication feature:

A user model.
Authentication API routes.
A login interface.

Start from an up-to-date local copy of your default branch:

git switch main
git pull --ff-only origin main

1. Initialize the bottom layer

Run gh stack init with a branch name to create the first branch and register a stack locally:

gh stack init feat/user-model

The bottom branch is based on the repository's default branch unless you explicitly choose another base with --base. Make the database or domain-model changes on this branch, then commit them as you normally would:

git add src/models/user.ts migrations/
git commit -m "Add user model"

You can also run gh stack init without a branch name and select the first layer interactively.

2. Add a dependent API layer

Once the user-model work is committed, create a branch above it:

gh stack add feat/auth-api

This creates and checks out feat/auth-api at the current HEAD. Implement the login and session routes, then commit the work:

git add src/routes/auth.ts src/services/session.ts
git commit -m "Add authentication API"

The API branch now contains the commits from the user-model layer plus its own commits. However, its eventual PR diff will show only the API-specific changes because its base branch is feat/user-model.

3. Add the UI layer

Create the third layer while you are on the current top branch:

gh stack add feat/login-ui

Add the form and client-side integration, then commit:

git add src/components/LoginForm.tsx src/pages/login.tsx
git commit -m "Add login interface"

Use gh stack view at any point to inspect the local order, branch names, associated PR links, and recent commits:

gh stack view

Tip: Add a new branch when the concern changes or the current layer has grown large enough to make review difficult. A database migration, an API contract, and a UI implementation are usually better review units than three random groups of files.

Submit the Stack to GitHub

When the layers are ready, submit them together:

gh stack submit

This command pushes every branch, creates or updates a PR for each branch, and links the PRs as one stack on GitHub. In an interactive terminal, it opens an editor where you can review each PR title and description and choose whether it is ready for review or a draft.

For automation or a quick initial submission, use:

gh stack submit --auto

By default, the non-interactive form creates new PRs as drafts. Add --open if the new PRs should be ready for review immediately:

gh stack submit --auto --open

After submission, the stack looks like this on GitHub:

PR #1: Add user model          → main
PR #2: Add authentication API  → feat/user-model
PR #3: Add login interface     → feat/auth-api

The PR page includes a stack map that shows the layers and their status. Reviewers can jump between the PRs without returning to the pull request list.

Review Stacked Pull Requests

The best way to review a complete stack is from bottom to top. Start with the foundational model, then review the API that depends on it, then the interface that uses that API. This mirrors the dependency order and provides the full story.

Each PR should also make sense as a focused review on its own. If reviewing one layer requires holding too much unrelated information in mind, consider restructuring the stack so that the layer becomes more atomic.

GitHub evaluates each stacked PR against the requirements of the bottom PR's base branch. In practice, this means branch protection rules and pull-request CI checks associated with main apply throughout the stack, including layers that directly target another feature branch.

Update a Stack After Feedback

Feedback often arrives on the lower layers first. For example, a reviewer might ask you to rename a field in feat/user-model after you have already built the API and UI on top of it.

Check out the layer you need to change, make the correction, and commit it:

gh stack checkout feat/user-model
# Edit the model files
git add src/models/user.ts
git commit -m "Rename user identifier field"

Then rebase the dependent branches in order:

gh stack rebase

gh stack rebase fetches from the remote and runs a cascading rebase from the trunk upward. If Git reports a conflict, resolve it, stage the resolved files, and continue:

git add <resolved-files>
gh stack rebase --continue

Finally, push the updated branches and refresh their PRs:

gh stack submit

For routine maintenance, gh stack sync is often the simplest option:

gh stack sync

It fetches updates, reconciles the local and remote stack, fast-forwards the trunk when possible, cascades rebases when needed, pushes branches, and synchronizes PR state. If a rebase rewrites branch history, the extension uses --force-with-lease when pushing, which protects against overwriting a remote update you do not have locally.

Merge a Stack

Stacked PRs merge from the bottom upward. You can merge one layer, a contiguous portion of the stack, or the whole stack:

Merge the bottom PR to land only that PR.
Merge a middle PR to land it and every unmerged PR below it.
Merge the top PR to land the entire stack.

You cannot merge a middle layer while leaving an unmerged dependency below it. After a partial merge, GitHub automatically rebases and retargets the remaining upper layers so that the next unmerged PR is ready to continue through review.

GitHub supports merge commits, squash merges, and rebase merges for stacks, and the final history matches the result of merging the PRs individually from bottom to top.

Best Practices for GitHub Stacked PRs

Use these guidelines to keep stacks readable and easy to maintain:

Make each layer independently reviewable. A layer can depend on lower layers, but its purpose should be clear in its own title, description, and diff.
Keep the stack shallow when possible. Two to five thoughtful layers are easier to reason about than a long chain of micro-PRs.
Order layers by dependency. Put shared types, migrations, and core logic below their consumers.
Use descriptive branch and PR names. Names such as feat/user-model and feat/auth-api make the stack map immediately understandable.
Submit early as drafts. This gives teammates visibility and lets you ask for architecture feedback before implementation is complete.
Sync before continuing work after lower layers merge. This keeps local branches aligned with GitHub's updated stack.
Explain the stack in the PR descriptions. A short sentence such as “Part 2 of 3: adds the API on top of the user model” helps reviewers understand the intended sequence.

Conclusion

GitHub Stacked PRs turn a large, difficult-to-review change into a series of focused, connected reviews. The workflow is straightforward: initialize a bottom branch, add layers as the work gains dependencies, submit the stack, and keep it synchronized as reviews and merges happen.

Start with a feature that naturally separates into two or three layers. Once your team is comfortable reviewing one focused change at a time, stacked PRs can make large changes feel much more manageable.

How to Use Kimi K3 with Claude Code

Arindam Majumder — Fri, 07 Aug 2026 12:47:34 +0000

Frontier coding models are becoming more capable, but using them for every task can become expensive quickly.

That matters when an AI agent is part of your daily development workflow.

The answer is not to use a cheaper model blindly. It is to match the model to the task. A strong open-weight model can handle repository exploration, test writing, documentation, contained refactors, and many routine implementation tasks. Save premium models and extra review for the work where the stakes or ambiguity truly justify them.

In this tutorial, you will use Kimi K3 with Claude Code through Nebius Token Factory Relay. The relay lets Claude Code communicate with Nebius-hosted open models without changing the workflow you use in the terminal.

For a visual walkthrough, watch the accompanying video:

What You Will Learn

By the end of this tutorial, you will be able to:

Explain what Kimi K3 is and when it makes sense to use it.
Create a Nebius Token Factory API key.
Install and configure Nebius TF Relay.
Launch Claude Code with Kimi K3.
Confirm that the model is working before you give it a real coding task.

What Is Kimi K3?

Kimi K3 is Moonshot AI’s flagship open-weight model. It is built for coding, agentic workflows, long-context tasks, and knowledge work. The model uses a Mixture-of-Experts architecture with 2.8 trillion total parameters and 104 billion active parameters per token. Moonshot reports a one-million-token context window and native vision capabilities in its technical report.

The model has attracted attention because it performs competitively on coding and agentic benchmarks while being available as open weights. Independent testing from Artificial Analysis places it close to leading proprietary models on agentic knowledge work. Moonshot’s own evaluation suite reports strong results across coding, agentic, long-context, and multimodal evaluations.

Benchmarks are useful context, but they are not a guarantee for your project. They use fixed prompts, tools, and scoring systems. The practical question is whether the model gives you reliable output on your codebase at an acceptable cost and speed.

Kimi K3 is a good model to try for:

Understanding an unfamiliar codebase
Writing or improving tests
Refactoring a well-defined area of a project
Drafting documentation and technical notes
Investigating an error before making a change

For sensitive security work, complex migrations, high-impact architecture decisions, or production changes, use the model and review process that give you the highest confidence.

Note: Kimi K3’s published model context window is one million tokens. Nebius TF Relay currently lists a 262K context window for its Kimi K3 route. The provider you use determines the limits, pricing, availability, and performance you actually receive.

How Nebius TF Relay Works

Claude Code is designed to communicate with Anthropic’s Messages API. Nebius Token Factory provides hosted open models through an OpenAI-compatible API. Those two APIs do not speak the same format.

Nebius TF Relay runs locally and translates between them. Claude Code sends requests to the relay, the relay converts them for Nebius, and the response is converted back for Claude Code. This means you can keep using the terminal interface, repository tools, and approval flow you already know.

The setup looks like this:

Component	Role
Claude Code	Your coding-agent interface
Nebius TF Relay	Local protocol bridge
Nebius Token Factory	Hosted inference provider
Kimi K3	The model that generates responses

Prerequisites

Before you begin, make sure you have the following:

Claude Code installed locally. Use the official installation guide if needed.
A Nebius Token Factory account.
A terminal on macOS, Linux, or WSL.
An optional Tavily API key if you want web search inside the relay.

You will also need a Nebius Token Factory API key. Create one from the Nebius API-key page. Copy it to a secure location when it is created.

Do not commit the key to Git, paste it into an AI prompt, or show it in a video recording.

Step 1: Install Nebius TF Relay

Install the relay with the project’s installer:

curl -fsSL https://nebius-tf-relay.vercel.app/install.sh | sh

This installs the nebiusrelay command and shortcuts such as nclaude.

If you work in a company or security-sensitive environment, inspect the project source before running a shell installer from the internet. That is good practice for any third-party developer tool.

After installation, check that the command is available:

nebiusrelay

You should see the relay’s interactive menu.

Step 2: Configure Your Nebius API Key

Run the configuration command:

nebiusrelay configure

When prompted, paste your Nebius Token Factory API key. The setup will also ask for a Tavily API key. You can skip this if you do not need web search.

The relay stores its configuration locally. You can also supply the key through an environment variable instead:

export NEBIUS_API_KEY="your_nebius_api_key"

Using an environment variable is useful for temporary sessions and automated environments. On a shared machine, use a secret manager or another protected credential workflow so that the key is not exposed in shell history.

Step 3: Launch Claude Code Through the Relay

Move into the repository where you want to work, then run:

nebiusrelay claude

You can use the shorter alias as well:

nclaude

The relay starts Claude Code with the Nebius endpoint and credentials configured for that session. It does not require you to permanently replace your existing Claude Code settings.

If Claude Code is not installed, the relay will tell you and point you to the official installation path.

Step 4: Select Kimi K3

Once Claude Code opens, use the model selector:

/model

Select Kimi K3 from the list.

Nebius TF Relay fetches the available model catalog when it starts, so the exact choices can change over time. Kimi K3 is documented as the relay’s default coding model, but it is worth checking the selected model before you begin a session.

Step 5: Verify the Setup With a Safe Prompt

Before asking the agent to change code, start with a read-only task. This confirms that the relay, credentials, model selection, and repository access are all working.

Use this prompt:

Read this repository without changing files. Identify the application entry point,
the test command, and the three highest-risk areas to modify. Cite the files you used.

This is a better first test than a vague request such as “build a feature.” It gives you evidence that the model can inspect the repository and follow constraints without making changes.

After that succeeds, try a small, bounded task. For example:

Inspect the failing test. Do not edit files yet. Explain the likely root cause,
the minimum fix, and the tests you would run after the change.

Review the proposal before you approve edits. Then inspect the diff and run the relevant tests yourself.

Key Takeaways

Kimi K3 is a capable open-weight model for coding, agentic work, and long-context tasks.
Nebius TF Relay lets you access it inside Claude Code without changing your normal terminal workflow.
You need a Nebius Token Factory API key, the relay, and the nclaude command to get started.
Start with a read-only prompt, then validate every code change with a diff review and tests.
Use the model that best matches the risk and complexity of the task—not necessarily the most expensive one.

Kimi K3 with Claude Code is not a replacement for engineering judgment. It is a practical way to add another strong model to your workflow and reserve expensive frontier-model usage for the situations where it has the most value.

I Ran the Same Login Through BrowserAct and Playwright. One Got Flagged as a Bot

Arindam Majumder — Tue, 04 Aug 2026 13:01:01 +0000

Agent browser automation works beautifully until it meets a real website.

The agent clicks through a demo page and looks unstoppable. Then you point it at a logged-in dashboard, or a form whose selectors moved after last week's redeploy, or a login that wants an SMS code. The reasoning model is fine. The layer underneath it was never built for this.

I spent a few days running BrowserAct through a JS-rendered page and a full login flow, then wrote the same login as a Playwright script to find where the two approaches diverge. Everything below is output I captured on Windows through WSL, including the run that failed while telling me it had worked.

What Playwright is built for

Playwright is deterministic. You know the page, you write selectors against it, you assert on outcomes. For CI end-to-end tests or scripted flows against a UI your team owns, it's hard to beat, because the script encodes knowledge you already have before the run starts.

That assumption is where agent workflows diverge, mostly because the agent doesn’t know the page.

In an agentic workflow, an agent arrives at a page it has never seen, on a DOM that may have shifted since the last run. Hand it raw HTML and you’re handing it thousands of tokens of nested markup with no stable handle to act on. It infers which node is the search box, guesses a selector, and hopes the guess survives the next render. When the layout changes, the guess breaks silently.

A script solves this by knowing the answer in advance. An agent can't, so it needs the page described in a form it can reason over. I wanted to see what that description actually looks like, so I ran some tests.

What the agent receives

I installed the CLI first, expecting the usual dependency archaeology:

uv tool install browser-act-cli --python 3.12

It resolved cleanly and dropped a single executable.

Another thing that caught my attention next was that the CLI refuses to ship the agent's instructions as a static file. The skill stub points at a command instead:

browser-act get-skills core --skill-version 2.0.2

Workflow content comes back matched to the installed version, so the guidance can't drift away from the binary driving it. For a tool whose commands change across releases, I thought that was a real answer to instruction rot.

The loop it served me is Open, State, Interact, Verify, Close. State is the part that matters, and here's what I got back against quotes.toscrape.com/scroll:

url=https://quotes.toscrape.com/scroll
|SCROLL|<html /> (0.0 pages above, 0.7 pages below,
        left=0,top=0,width=1905,height=1716)
    [1]<a />
        Quotes to Scrape
    [2]<a />
        Login
    "The world as we have created it is a process of our thinking..."
    by
    Albert Einstein
    Tags:
    [3]<a class=tag />
        change

Every actionable element carries an index. To reach login, the agent clicks [2], and it does that without writing a selector or holding a DOM model between turns. I also liked that scroll position arrives as page-fractions, since the agent knows 0.7 of a page sits below it without measuring anything.

I captured the same moment visually with screenshot --full:

The viewport was 1716 pixels tall and had not been scrolled, yet the capture runs all the way to the footer. Between them these are two views of one moment, the screenshot for a human auditing what happened and the indexed state for the agent deciding what to do next.

Where network capture earns its place

State told me what was rendered, but I wanted to know where it came from, so I pulled the XHR traffic:

method,status,mime_type,url
POST,,,https://ogads-pa.clients6.google.com/$rpc/...GetAsyncData
GET,200,application/json,https://quotes.toscrape.com/api/quotes?page=1

That second row is the interesting one. The page renders its cards from a JSON endpoint, which means an agent can read api/quotes?page=1 directly rather than parsing rendered markup back into structured data. The first row is a Google ads call the page also fired, and I'd note that real capture always includes noise the agent has to filter.

One gotcha I hit: without --format json the CLI writes CSV, which will bite you if you're piping into a parser.

The failure that reported success

The scroll taught me more than anything that worked.

I opened the page, read state, ran scroll down --amount 3, waited, then read state again. Both snapshots came back identical. Same top=0, same tag indices [1] through [19]. Only page=1 had been fetched, when a successful scroll should have pulled page=2.

I assumed a race condition, so I re-ran the whole thing with wait stable --timeout 15000 and a second settle pass. Same result.

What threw me is that the command had reported success both times, echoing back scrolled=down amount=3 with exit code 0. That confirms the command executed, which turns out to be a very different claim from the viewport having moved. When I read the page markdown, Loading... was still sitting at the bottom.

Calibration fixed it. Running --amount 3000 gave me this:

|SCROLL|<html /> (0.7 pages above, 2.1 pages below, height=3794)

Compare that against the earlier height=1716. The document had more than doubled, which only happens when new content loads, and the network capture confirmed where it came from:

json

{"url": "https://quotes.toscrape.com/api/quotes?page=1", "status": 200}
{"url": "https://quotes.toscrape.com/api/quotes?page=2", "status": 200}

So the amount behaves like pixels, and my original 3 meant three pixels of movement on a 1716-pixel viewport. That's a documentation gap rather than a bug.

The lesson sits in the first attempt, though. Nothing errored anywhere in that sequence. Every command returned success, every state snapshot looked valid, and the page underneath had not moved at all. Verification has to come from the page's own evidence, whether that's a changed scroll position, a taller document, or a new network call. An agent trusting exit codes here would have confidently reported reading a list it never scrolled.

Crossing a login boundary

A public page is the easy case. I wanted to know whether state survives authentication, so I pointed the loop at saucedemo.com, a Sauce Labs sandbox with published credentials.

Here's what I got before logging in:

{"url":"https://www.saucedemo.com/","title":"Swag Labs",
 "text":"[1]<div id=root />\n\t[2]<input placeholder=Username id=user-name />\n\t[3]<input placeholder=Password type=password />\n\t[4]<input id=login-button type=submit />"}

I typed into [2] and [3], then clicked [4]:

url=https://www.saucedemo.com/inventory.html
    [2]<button id=react-burger-menu-btn /> Open Menu
    [3]<a class=shopping_cart_link />
    [9]<a id=item_4_title_link /> Sauce Labs Backpack  $29.99
    [10]<button id=add-to-cart-sauce-labs-backpack /> Add to cart

The URL moved, the indices renumbered against a completely different page, and the session carried authentication forward. [10] is now a real add-to-cart action, and nothing in my setup had to know in advance that a product grid was coming.

I did fumble this on the first attempt, which is worth passing on. I picked indices 1, 2, and 3 for username, password, and submit, when the correct mapping was 2, 3, and 4, because [1] was the root <div id=root /> wrapper. The state had shown me that correctly and I misread it. Re-reading state fixed it in a single turn, which I'd contrast against a stale selector, since that one needs a human to open the script and rewrite it.

The network capture then surfaced something I wouldn't have predicted:

json

{"url": "https://events.backtrace.io/api/unique-events/submit", "status": 401}

No authentication call at all. Sauce Demo does its auth client-side, so the only traffic I captured was Backtrace telemetry returning 401. If I'd built an agent that confirms login by watching for an auth response, it would have failed here silently, and one command told me that.

Running the same login in Playwright

Then I wrote the same flow as a script: goto, fill #user-name and #password, click #login-button, wait for the inventory URL. Headless Chromium, exit code 0, six products found.

Both tools passed. I'd add context, though, because Sauce Demo is a test sandbox with stable documented IDs, built so that selector-based scripts have something predictable to hit. It's the most favourable page Playwright will ever see.

What interested me more is what Sauce Demo couldn't test. It never challenged either tool, with no fingerprinting and no interstitial anywhere in the flow. So my run measured whether a form can be driven, and told me nothing about whether the browser reaches the page at all.

So I pointed both at deviceandbrowserinfo.com/are_you_a_bot. BrowserAct's stealth browser came back with this:

json

{"isBot": false, "details": {
  "hasBotUserAgent": false, "hasWebdriverTrue": false,
  "isPlaywright": false, "isHeadlessChrome": false,
  "isAutomatedWithCDP": false, "hasSuspiciousWeakSignals": false}}

My Playwright script came back with this:

json

{"isBot": true, "details": {
  "hasBotUserAgent": true, "hasWebdriverTrue": true,
  "hasWebdriverInFrameTrue": true,
  "isAutomatedWithCDP": true, "isAutomatedWithCDPInWebWorker": true}}

Five separate flags tripped. The user agent announced itself, navigator.webdriver read true in the main frame and inside frames, and the CDP automation was visible from both the page and a web worker. The page rendered "You are a bot" where the other run had said "You are human!"

I should be clear that this is default headless Playwright. Stealth plugins exist for exactly this reason and would change the result, so the fair framing is that hardening is work you take on yourself, while the stealth browser arrived that way.

bot.sannysoft.com agreed on the BrowserAct side, showing WebDriver missing, the Chrome object present, and PluginArray correct. I noticed one nuance in the fp-collect output, where webDriver: true sits alongside webDriverValue: false, and that reflects the property existing while set to false, which is standard Chrome rather than a leak.

	BrowserAct	Playwright (default)
How it clicks	Index from live state	Selector written in advance
Needs the page mapped first	No	Yes
Sauce Demo login	Reached inventory	Reached inventory
Detection verdict	`isBot: false`	`isBot: true`, five flags

Two housekeeping notes from these runs. My stealth quota ran out partway through, so the scroll confirmation used local Chrome, though scroll behaviour is identical either way. And when I ran under WSL without sudo, the apt install of Chromium libraries failed, at which point BrowserAct unpacked the dependencies into ~/.local/share/ and loaded them through LD_LIBRARY_PATH rather than dying. I'd call that a good default, though expect a slow first run while it fetches.

When BrowserAct is the right tool

Four situations came up across these runs where BrowserAct did something a plain script would have struggled with, and I hit each one directly.

On quotes.toscrape.com/scroll I never wrote a selector. I read indexed state, acted on [2], and re-read after the page changed. When I point an agent at a site it hasn't seen, or at a UI that shifts between runs, that loop is what lets it keep going instead of stalling on a selector that no longer matches. This is the case for research and monitoring work, where the target is rarely a page you built.

The detection run is the one I keep coming back to. My stealth browser cleared deviceandbrowserinfo and sannysoft as human on the same page where my headless Playwright tripped five flags and got "You are a bot." An agent that reasons perfectly is useless when the site fingerprints it and never serves the page. On protected targets that's the reason I'd reach for the stealth browser rather than a raw headless script.

The SauceDemo login showed me the third. I authenticated, landed on /inventory.html, and the session carried forward into a page with real add-to-cart actions I hadn't seen before the login. For a dashboard check or an account operation, the part that only exists after login is the whole job, and the session held across that boundary without me scripting the transition.

The fourth came out of the network capture. On the quotes run it handed me the api/quotes endpoint the page was reading from, and on SauceDemo it showed me the auth was client-side with no login call at all. When the data I want arrives over XHR, reading it from the network beats parsing rendered cards, and it told me how each page actually worked rather than how it looked.

I'll keep one thing honest, though. If the page is one you own, the selectors are stable, and nothing is trying to keep you out, a plain Playwright script is simpler and cheaper than an agent loop. My SauceDemo login proved that much, since both tools passed and the script had less to reason about. BrowserAct earned its cost on the runs where the page was unfamiliar, protected, gated behind a session, or feeding data through a network call, and that describes production more often than it describes a sandbox.

Try it against one workflow

If your agent works in clean demos but falls over on real sites, the test that told me the most was a small one.

Point it at a single workflow you care about, then check the page's own evidence rather than the exit code.

That's where a browser layer either earns its keep or shows you that a script was fine all along.

Did Cursor Kill the Model Router Companies?

Arindam Majumder — Wed, 22 Jul 2026 22:16:21 +0000

Cursor has launched Cursor Router, an intelligent model-routing system designed for teams and enterprises.

// Detect dark theme var iframe = document.getElementById('tweet-2079993729532989500-41'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2079993729532989500&theme=dark" }

On the surface, it sounds familiar: inspect a request, decide how difficult it is, and send it to the model that offers the best balance between quality and cost.

That is already the central promise behind products such as OpenRouter, Not Diamond, Portkey, Martian, and Amazon Bedrock Intelligent Prompt Routing.

But Cursor's entry into this market is different in one important way: Cursor does not operate outside the workflow.

It owns the coding environment in which the request is created, processed, evaluated, and, if the result is useful, accepted into the codebase.

Cursor has not literally killed the model-routing industry. It may, however, have made standalone model routing much harder to sell as an independent product for AI-assisted software development.

What Is an AI Model Router?

Different AI models are good at different jobs. A frontier reasoning model might be necessary for a complex architectural change, while a smaller and cheaper model could easily rename a variable, explain a function, or generate routine boilerplate.

Without routing, users often select one powerful model and use it for everything. This is simple, but inefficient. Easy work gets completed at frontier-model prices even when a less expensive model could produce an equally useful result.

A model router sits between the user and a collection of models. It analyzes each request and chooses where to send it. Depending on the platform, that decision may consider:

Task type and complexity
Expected response quality
Cost and latency
Model availability
Provider reliability
Context-window requirements
Security and data-retention policies

The basic pitch is compelling: use expensive intelligence only when it is actually needed.

How Cursor Router Works

According to Cursor, approximately 60% of its developers select a single model as their daily driver. Cursor Router attempts to eliminate that habit by classifying every request before an AI model begins working.

The router analyzes the query, available context, task complexity, and domain. It combines those signals with Cursor's knowledge of how individual models behave on real coding tasks. The request is then sent to the model considered most appropriate for the job.

Cursor offers three routing modes:

Intelligence prioritizes frontier-level performance.
Balance aims for strong quality at a more practical cost.
Cost seeks the highest useful intelligence while minimizing token spending.

Administrators can control which modes are available, decide how the router is rolled out across teams, and allow or block specific models.

Cursor says it trained the router using more than 600,000 live requests and evaluated it through online A/B tests covering millions of additional requests.

During early access, participating enterprises reportedly achieved frontier-level performance at roughly 30–50% lower cost. Cursor also reports that broader online testing produced frontier-quality results with savings of approximately 60%.

These are Cursor's own results and should be independently validated across different organizations and workloads. Even so, the scale and type of its training data reveal why this launch matters.

Cursor's Real Advantage Is Not the Classifier

The model-selection algorithm is only part of Cursor Router's advantage. The more important asset is Cursor's position inside the development workflow.

A general-purpose router can see the prompt and perhaps some application metadata. Cursor can potentially learn from a much richer sequence of events:

What the developer asked
What code and project context surrounded the request
Which model generated the response
Whether the developer accepted or rejected the result
How much of the generated code survived later edits
Which models perform best for particular coding tasks

This creates a powerful feedback loop. Cursor routes hundreds of millions of coding requests each week and can observe signals that are closely connected to real developer satisfaction. Instead of optimizing only for benchmarks or synthetic evaluations, it can optimize using evidence from production coding workflows.

That distribution advantage is difficult for an external router to reproduce. Cursor owns the interface, the context, and the outcome signal.

The Existing Router Market

Cursor is entering an increasingly crowded category.

OpenRouter

OpenRouter provides a unified API for accessing hundreds of models across numerous inference providers. Its Auto Router automatically selects a model for each prompt and is powered by Not Diamond. OpenRouter also handles provider selection, pricing preferences, and fallbacks.

Its value extends well beyond model classification. For developers building general AI applications, one API key, broad model access, provider redundancy, and standardized request handling remain important infrastructure benefits.

Not Diamond

Not Diamond specializes in intelligent model routing and prompt optimization. Developers can use a pre-trained router or train a custom router using their own application data. This makes it applicable to customer support, document processing, research, sales, and other workloads, not only coding.

Not Diamond also powers OpenRouter's Auto Router, demonstrating that specialized routing technology can be distributed through larger platforms rather than sold only as a standalone destination.

Portkey

Portkey positions routing as one capability within a broader AI gateway. Its platform includes conditional routing, fallbacks, retries, load balancing, caching, guardrails, budget controls, and observability.

These operational features solve problems Cursor Router is not primarily designed to address. A company running several production AI applications may need centralized governance and reliability across all of them, regardless of which editor its developers use.

Amazon Bedrock

Amazon Bedrock Intelligent Prompt Routing dynamically routes prompts between supported models in the same model family. It predicts response quality and attempts to choose the best quality-and-cost combination. For organizations already committed to AWS, routing can therefore become a native cloud capability rather than another external service.

This highlights the broader trend: model routing is being absorbed into the platforms that already own inference, application infrastructure, or user workflows.

Did Cursor Kill the Router Companies?

Not exactly.

Cursor Router is optimized around software development and is currently offered to Teams and Enterprise customers across Cursor's desktop, web, iOS, CLI, and SDK experiences. It does not replace a general AI gateway for companies operating many models across multiple applications and departments.

Independent routing platforms can continue to compete through capabilities such as:

Routing for non-coding workloads
Custom evaluation data and application-specific routers
Bring-your-own-provider keys
Cross-provider failover and load balancing
Centralized security and compliance controls
Cost tracking across several applications
Guardrails, caching, rate limits, and observability
Self-hosted or cloud-neutral deployment

What Cursor has threatened is the narrowest version of the router-company pitch: we will inspect your coding prompt and select the best model for it.

When that capability is built directly into the coding product and trained using feedback the coding product uniquely owns it becomes difficult to justify another service between the developer and the model.

Routing Is Becoming a Platform Feature

The history of software infrastructure is filled with standalone products that eventually became native platform features. Logging, authentication, analytics, deployment, and monitoring all followed versions of this pattern. A new technical requirement first creates a specialized market. Then larger platforms absorb the most universal parts of the solution.

AI model routing appears to be entering that stage.

OpenRouter has integrated automatic selection into its multi-model gateway. Amazon has added routing to Bedrock. Portkey includes it within an operational AI gateway. Cursor now embeds it directly into an AI coding environment.

This does not mean routing technology has no value. It means the value is moving. A basic classifier that chooses between a cheap model and an expensive model may no longer be enough to support an entire company. Successful router businesses will need proprietary outcome data, specialized workflows, custom optimization, governance, or infrastructure that platforms cannot easily reproduce.

What This Means for AI Development

Cursor Router points toward a future in which users stop manually choosing model names.

Most people do not want to compare benchmarks every week or decide whether a particular request requires Claude, GPT, Gemini, Grok, or another model. They want the best available outcome within their preferred limits for cost, speed, and privacy.

The model picker may eventually become an advanced setting rather than the center of the AI interface. Products will compete on how well they understand intent, assemble context, select intelligence, operate tools, and evaluate the final result.

In that world, the winning router may not be the company with the smartest isolated classifier. It may be the platform with the richest understanding of the work being performed.

Cursor already owns that context for millions of coding interactions. Cursor Router is its attempt to turn that context into an economic and product advantage.

Conclusion

Cursor did not kill OpenRouter, Not Diamond, Portkey, Martian, or the wider routing ecosystem. Those products serve broader infrastructure needs, and many provide features far beyond automatic model selection.

But Cursor has delivered a serious warning to every standalone router company: if your entire product is choosing a model, the platform that owns the workflow may eventually choose it for you.

For AI coding, model routing is no longer merely an external infrastructure category. It is becoming a native feature of the development environment.

The router companies are not dead but the simple router pitch might be.

Open Knowledge Format (OKF) Explained

Arindam Majumder — Fri, 10 Jul 2026 05:43:48 +0000

Large language models are becoming more capable every day, but they all depend on one thing: high-quality context.

Projects like Andrej Karpathy's LLM Wiki have sparked conversations around representing knowledge in a way that's easier for both humans and AI to understand. The Open Knowledge Format (OKF) takes a different approach by introducing an open, vendor-neutral format for representing knowledge using Markdown and YAML.

In this video, we'll explore:

What the Open Knowledge Format (OKF) is
Why it was created
How it differs from traditional knowledge catalogs
The structure of an OKF bundle
How the Reference Agent generates knowledge automatically
How the Visualizer turns knowledge into an interactive graph
Why treating knowledge as code could become an important idea for AI systems

Whether you're building AI applications, developer tools, documentation systems, or simply interested in how knowledge is evolving in the AI era, this video will give you a solid understanding of OKF and the ideas behind it.

If you enjoyed the video, consider subscribing for more content on AI engineering, open source, developer tools, and modern software architecture.

Building a Debate Council of LLMs to Stress-Test NVIDIA Cosmos 3

Arindam Majumder — Wed, 24 Jun 2026 13:19:01 +0000

A benchmark score tells you how a model did on a test. It does not tell you whether the model can hold a position, take a punch, and adjust without falling apart.

That second thing is what I wanted to know about NVIDIA Cosmos 3, which NVIDIA had just shipped. So instead of running yet another eval, I did something more fun. I built the model an arena and made it argue with itself.

// Detect dark theme var iframe = document.getElementById('tweet-2061515414837100955-360'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2061515414837100955&theme=dark" }

The result is Cosmos Arena, a multi-agent debate council. You hand it a motion, something like "This house believes AGI will arrive before 2035," and five roles fight it out:

An Advocate argues for, a Skeptic argues against
They trade rebuttals across several rounds
An optional Pragmatist pokes holes in both sides
An Arbiter scores everything and hands down a verdict

Here is the catch that makes it a real test: every seat runs on the same model. The only thing that changes is the role.

That is surprisingly hard to fake. A model that just knows how to sound smart will produce two confident speeches that never touch. A model that can actually reason opens round two by answering the exact weakness the other side exposed in round one. You watch the difference happen, turn by turn.

This tutorial is the full build. By the end you will have a working Streamlit app, you will get why the orchestration uses LangGraph instead of one model pretending to be everyone, and you will know how to serve Cosmos 3 through Nebius Token Factory.

First, what Cosmos 3 actually is

Let me be honest about the model up front, because it is not a normal chat model, and the name can mislead you.

NVIDIA built Cosmos 3 for Physical AI: robots, autonomous vehicles, factory floors, anything that has to understand motion, causality, and physics in the real world. NVIDIA launched it on June 1, 2026 at GTC Taipei and calls it the first fully open omnimodel with native vision reasoning.

Under the hood it is a Mixture-of-Transformers that pairs a reasoning transformer with an expert generation transformer. One half thinks about object interactions, motion, and space. The other half generates video and action trajectories.

The whole point is to let a robot reason before it acts, which cuts physical AI training cycles from months down to days. The NVIDIA technical blog goes deep if you want the full picture.

So why use a robotics world model to run a debate? Because that reasoning transformer is the interesting part. NVIDIA trained it to reason about the physical world, and I wanted to see how well that transfers to something it was never sold for: a pure-language argument, no images, no video, just ideas. That transfer tells you far more than a single-prompt score ever will.

Cosmos 3 specs at a glance

Here are the details that matter for this project.

Property	Cosmos 3 Super	Cosmos 3 Nano
Total parameters	64B	16B
Split	32B reasoner + 32B generator	8B reasoner + 8B generator
Architecture	Mixture-of-Transformers (reasoning + generation)	Mixture-of-Transformers
Built for	Post-training robotics and AV models at the highest physics accuracy	Fast video and action reasoning in a fraction of a second
License	OpenMDW (open for commercial and non-commercial use)	OpenMDW
Released	June 1, 2026 (GTC Taipei)	June 1, 2026

A few more things worth knowing:

It is genuinely omnimodal. It takes in and generates text, images, video, ambient sound, and action sequences, all in one model.
It was trained on one of the largest multimodal physical AI datasets out there, billions of samples across text, image, video, sound, and action.
It shipped with a Cosmos Coalition of robotics and AI labs (Agile Robots, Black Forest Labs, Runway, Skild AI, and others) building on top of it.
NVIDIA is upfront about the limits: generation can drift over time, and the reasoning can still hallucinate, since there is no physics simulator actually running in the loop.

For our build, the parts that matter are the reasoner tower and how well the model holds a role. The debate leans hard on both.

Where it runs: Nebius Token Factory

A 64B omni-model is not something I want to babysit on my own GPUs. So every model call in this project goes through Nebius Token Factory.

Token Factory is Nebius's production inference platform. It takes open and partner models, including NVIDIA's, and serves them behind one fast, OpenAI-compatible API, with the posttraining and governance pieces handled for you.

NVIDIA models like Nemotron already run there, and Nebius has been building cloud infrastructure with NVIDIA specifically for robotics and physical AI. That makes it a natural home for Cosmos.

Why it fits this project so well:

OpenAI-compatible API. Anything built for OpenAI works with a base-URL swap. The base URL is https://api.tokenfactory.nebius.com/v1/.
Drop-in LangChain support. The langchain-nebius package gives you a ChatNebius model that slots straight into LangGraph.
No GPUs to provision. You point at a model name and pay per token. That is the whole setup.
One key for five seats. Every council member shares a single NEBIUS_API_KEY, so there are no per-agent credentials to juggle.

Grab a key from the Nebius Token Factory console and you are ready.

What we are building

The council has five roles. Four of them are model calls. The fifth, the Moderator, is the graph itself, and that turns out to be the decision that makes everything work.

Role	Node	Job
The Advocate	`proponent`	Argues for the motion, rebuts the Skeptic each round
The Skeptic	`opponent`	Argues against the motion, rebuts the Advocate each round
The Pragmatist	`pragmatist`	Independent member who stress-tests both sides (optional)
The Arbiter	`judge`	Scores logic, evidence, and rebuttal, then gives a verdict
The Moderator	the graph	Routes turns, threads the transcript, decides when to stop

The flow goes from opening statements, through alternating rebuttal rounds, to an optional reality check, and finally a scored verdict:

        +--------------+      +-------------+
START ->|  proponent   | ---> |  opponent   | --> (more rounds?)
        +--------------+      +-------------+         |
              ^  more rounds: next_round              | no
              +---------------------------------------+
                                                      v
                                  (pragmatist?) -> judge -> END

Why a graph and not one clever prompt

You could try the lazy version: one prompt that says "argue both sides of X, then judge it." It reads fine and proves nothing.

The problem is that the model writes the "for" case and the "against" case in a single breath. They do not respond to each other, because they were written together. There is no exchange, just a model acting out the idea of a debate.

A real debate needs structure that a prompt cannot promise:

Each side gets its own turn, so each argument is a focused generation
A rebuttal sees what the other side actually just said
Rounds stack up, so later the Advocate answers a real objection instead of repeating its opener
The judge reads the full transcript and scores it on fixed criteria

That is a state machine, not a prompt, which is exactly what LangGraph is for. Putting the structure in code means each role gets its own isolated call, rebuttals genuinely see the prior turn, and the round count is enforced rather than left to the model's mood.

Prerequisites

Python 3.11 or higher
A Nebius Token Factory account and API key
uv for dependencies (pip install uv)

The dependency list is short on purpose:

dependencies = [
    "langgraph>=1.0",
    "langchain-nebius>=0.1.3",
    "langchain-core>=0.3",
    "python-dotenv>=1.1.1",
    "streamlit>=1.47.0",
]

Project layout:

cosmos_arena_debate_council/
  app.py              # Streamlit UI and live debate streaming
  cosmos_council.py   # LangGraph debate graph: nodes, routing, model
  pyproject.toml      # Dependencies
  .env.example        # Environment variable template
  assets/             # NVIDIA and Nebius logos

Get set up:

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/advance_ai_agents/cosmos_arena_debate_council
uv sync
cp .env.example .env   # then add your NEBIUS_API_KEY

Your .env:

NEBIUS_API_KEY=your_api_key_here
# Optional overrides
COSMOS_MODEL=nvidia/Cosmos3-Super-Reasoner
NEBIUS_BASE_URL=https://api.tokenfactory.nebius.com/v1/

Step 1: Wire up Cosmos 3 and handle the reasoning channel

This is the one gotcha that will trip you up, so it goes first.

The stock ChatNebius integration reads the answer from message.content, the usual OpenAI shape. But Cosmos, served as a reasoner, often puts its answer in a non-standard reasoning field and leaves content empty. Use the integration as-is and every council member comes back blank.

The fix is a small subclass that folds the reasoning field back in. If content is empty, the reasoning is the answer. If both are there, the reasoning becomes separate chain-of-thought for the UI to show.

from langchain_core.outputs import ChatResult
from langchain_nebius import ChatNebius

DEFAULT_BASE_URL = "https://api.tokenfactory.nebius.com/v1/"
DEFAULT_MODEL = "nvidia/Cosmos3-Super-Reasoner"


class CosmosChatNebius(ChatNebius):
    """ChatNebius that surfaces the non-standard `reasoning` field."""

    def _create_chat_result(self, response, generation_info=None) -> ChatResult:
        result = super()._create_chat_result(response, generation_info)
        response_dict = response if isinstance(response, dict) else response.model_dump()
        for gen, choice in zip(result.generations, response_dict.get("choices") or []):
            reasoning = (choice.get("message") or {}).get("reasoning")
            if not reasoning:
                continue
            message = gen.message
            if (message.content or "").strip():
                # Real answer present, keep reasoning as separate chain-of-thought.
                message.additional_kwargs.setdefault("reasoning_content", reasoning)
            else:
                # Empty content, so the reasoning is the answer.
                message.content = reasoning
        return result

Cosmos can also do it the other way, wrapping its reasoning in <think> tags inside the content. A small splitter pulls the two apart so the UI never mixes thinking into the actual argument:

import re

_THINK_RE = re.compile(r"<think>(.*?)</think>", re.DOTALL | re.IGNORECASE)


def split_reasoning(text: str) -> tuple[str, str]:
    """Separate the visible answer from the model's <think> reasoning."""
    text = text or ""
    reasoning_parts = [m.strip() for m in _THINK_RE.findall(text)]
    clean = _THINK_RE.sub("", text).strip()
    if "<think>" in clean.lower():  # unclosed reasoning block
        idx = clean.lower().index("<think>")
        reasoning_parts.append(clean[idx + len("<think>"):].strip())
        clean = clean[:idx].strip()
    return clean.strip(), "\n\n".join(p for p in reasoning_parts if p).strip()

A shared factory ties it together. Every seat calls this same function, so the model never changes, only the prompt does:

import os


def build_model(api_key=None, model=None, base_url=None, temperature=0.6) -> ChatNebius:
    """Create the shared Cosmos reasoner backed by Nebius Token Factory."""
    return CosmosChatNebius(
        model=model or os.getenv("COSMOS_MODEL", DEFAULT_MODEL),
        api_key=api_key or os.getenv("NEBIUS_API_KEY"),
        base_url=base_url or os.getenv("NEBIUS_BASE_URL") or DEFAULT_BASE_URL,
        temperature=temperature,
    )

Step 2: Give each seat a persona

The roles are just system prompts, but they are written to force genuinely different behavior. The Advocate and Skeptic are told to rebut the other side point by point before adding anything new. The Pragmatist takes no side. The Arbiter has to produce a fixed scorecard. Here are two of them:

PROPONENT_PROMPT = (
    "You are The Advocate, a council member in the Cosmos Arena debate.\n"
    "Your role: argue persuasively and rigorously IN FAVOR of the motion.\n\n"
    "Guidelines:\n"
    "- Make the strongest honest case for the motion.\n"
    "- Ground claims in reasoning, evidence, and concrete examples.\n"
    "- If you are given the opposition's prior argument, directly REBUT it "
    "point by point before adding new arguments.\n"
    "- Be sharp and confident, but never fabricate facts.\n"
    "- Keep it focused: 3-5 tight paragraphs in markdown. End with your "
    "single strongest line.\n"
    "- Output ONLY your argument. Do not narrate your process."
)

JUDGE_PROMPT = (
    "You are The Arbiter, the impartial judge of the Cosmos Arena debate.\n"
    "You will be given the full debate transcript.\n\n"
    "Deliver your verdict as markdown with EXACTLY these sections:\n\n"
    "### Scorecard\n"
    "A markdown table scoring each side (Proponent, Opponent) from 0-10 on "
    "**Logic**, **Evidence**, and **Rebuttal**, with a **Total** column.\n\n"
    "### Verdict\n"
    "State the winner (or an honest draw) in one bold sentence, then 2-3 "
    "sentences justifying it based strictly on the arguments made.\n\n"
    "### Strongest Argument\n"
    "Quote or paraphrase the single most decisive point.\n\n"
    "### What Would Change the Outcome\n"
    "One short paragraph on the evidence or reasoning that would flip the result."
)

This is where you find out if Cosmos 3 can really be five different people. Weaker models leak. The Skeptic starts agreeing, or the Arbiter picks a winner before it reads anything. A strong reasoner keeps the seats clean all the way through.

Step 3: Model the debate as state

The whole debate lives in one typed state object. The trick is transcript, an append-only list. Each node returns only its single new turn, and LangGraph's reducer, operator.add, tacks it onto the running transcript. That means each streamed update is exactly one new turn, which is perfect for a live UI.

import operator
from typing import Annotated, TypedDict


class Turn(TypedDict):
    speaker: str   # proponent | opponent | pragmatist | judge
    round: int     # debate round (0 for judge and pragmatist)
    text: str      # the visible argument
    reasoning: str # the model's chain-of-thought, if any


class DebateState(TypedDict):
    motion: str
    current_round: int
    # operator.add makes each node APPEND its turn to the transcript.
    transcript: Annotated[list[Turn], operator.add]

One small helper grabs the other side's most recent turn. This is the piece that makes rebuttals real instead of generic:

def _latest(transcript: list[Turn], speaker: str) -> str:
    for turn in reversed(transcript):
        if turn["speaker"] == speaker:
            return turn["text"]
    return ""

Step 4: Write the nodes

Each council member is a node: one model call with a role prompt and a user prompt built from the live transcript. Watch how the proponent's prompt changes between the opening round and later rounds. From round two on, it gets handed the Skeptic's latest argument and told to rebut it point by point. That is the whole difference between a debate and two people talking past each other.

def _say(model, system_prompt: str, user_prompt: str) -> tuple[str, str]:
    response = model.invoke([
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_prompt},
    ])
    answer, inline_reasoning = split_reasoning(response.content or "")
    reasoning = response.additional_kwargs.get("reasoning_content") or inline_reasoning
    return answer, reasoning


def proponent_node(state: DebateState) -> dict:
    rnd = state["current_round"]
    if rnd == 1:
        user = (
            f"The motion before the council:\n\n> {state['motion']}\n\n"
            "Deliver your OPENING case in favor of the motion."
        )
    else:
        user = (
            f"The motion before the council:\n\n> {state['motion']}\n\n"
            "The Skeptic's most recent argument was:\n\n"
            f"{_latest(state['transcript'], 'opponent')}\n\n"
            f"This is round {rnd}. Rebut the Skeptic point by point, then "
            "press your strongest new arguments for the motion."
        )
    text, reasoning = _say(model, PROPONENT_PROMPT, user)
    return {"transcript": [Turn(speaker="proponent", round=rnd, text=text, reasoning=reasoning)]}

The judge node works the same way but reads the entire transcript and produces the scorecard. Since the transcript is already clean and structured, there is no fragile report parsing. Clean text in, verdict out.

Step 5: Let the graph moderate

Here is the payoff. The Moderator is not a model deciding what comes next, it is plain deterministic routing. START to proponent to opponent, then a conditional edge decides: run another round, or wrap up? If rounds remain, bump the counter and loop back. If not, run the optional Pragmatist, then the Arbiter, then end.

from langgraph.graph import END, START, StateGraph


def build_debate_graph(model, rounds: int = 2, use_pragmatist: bool = True):
    # ... node definitions: proponent, opponent, pragmatist, judge ...

    def route_after_opponent(state: DebateState) -> str:
        if state["current_round"] < rounds:
            return "increment_round"
        return "pragmatist" if use_pragmatist else "judge"

    builder = StateGraph(DebateState)
    builder.add_node("proponent", proponent_node)
    builder.add_node("opponent", opponent_node)
    builder.add_node("increment_round", increment_round_node)
    builder.add_node("judge", judge_node)
    if use_pragmatist:
        builder.add_node("pragmatist", pragmatist_node)

    builder.add_edge(START, "proponent")
    builder.add_edge("proponent", "opponent")
    builder.add_conditional_edges(
        "opponent",
        route_after_opponent,
        ["increment_round", "pragmatist", "judge"]
        if use_pragmatist
        else ["increment_round", "judge"],
    )
    builder.add_edge("increment_round", "proponent")
    if use_pragmatist:
        builder.add_edge("pragmatist", "judge")
    builder.add_edge("judge", END)

    return builder.compile()

Step 6: Stream it live in Streamlit

The UI streams with stream_mode="updates", so each member's argument shows up the moment its node finishes. Color-coded card, correct round, and a collapsible panel that exposes Cosmos 3's chain-of-thought.

for update in graph.stream(
    initial_state(motion), config={"recursion_limit": 60}, stream_mode="updates"
):
    delta = next(iter(update.values()))
    new_turns = delta.get("transcript") if isinstance(delta, dict) else None
    if not new_turns:          # skip the increment_round bookkeeping step
        continue
    turn = new_turns[-1]
    card.complete(turn["text"], turn["reasoning"], live=True)

Run it:

uv run streamlit run app.py

Open http://localhost:8501, pick your number of rounds (1 to 4) and whether to seat the Pragmatist, type in a motion, and hit "Convene the Council."

What it looks like in action

Let me run the motion "This house believes AGI will arrive before 2035."

The Advocate opens strong on compute scaling curves, efficiency gains, and the money pouring into the field. Confident, concrete, ends on a sharp line.

The Skeptic does not blink. A trend line is not a mechanism, benchmark progress is not general capability, and "before 2035" is a specific claim that needs a specific argument the other side has not made.

Round two is where it gets good. The Advocate opens by quoting the Skeptic's "no mechanism" point and answering it head-on before pressing forward. The rebuttal threading is working. This is now an actual exchange.

The Pragmatist steps outside the fight and calls it: both sides are arguing definitions. What would really settle it is a measurable capability threshold tied to a date. Name it, or you are just debating vibes.

Then the Arbiter closes with a scorecard:

Side	Logic	Evidence	Rebuttal	Total
Proponent	7	6	8	21
Opponent	8	7	7	22

It gives the win to the Skeptic, narrowly. The Advocate argued well and rebutted directly, but leaned on extrapolation where the Skeptic demanded a mechanism, and that hard 2035 deadline raised a bar the Advocate never quite cleared.

The fun part is not who won. It is that the round-two rebuttal genuinely engaged the round-one objection. That only happens if the model can hold a position, absorb a counter, and adjust, which is exactly the reasoning I was trying to see.

What this tells you about Cosmos 3

Running a few motions through the arena surfaces things a benchmark never will.

Role discipline. Does the Skeptic stay skeptical for four straight rounds, or quietly start agreeing? Cosmos held its seats.
Rebuttal quality. Do later rounds answer the specific prior point, or just restate the opener with new adjectives? This is the clearest signal of real reasoning, and you can see it live.
Judgment calibration. Does the Arbiter's verdict actually follow from the transcript, or does it pick a side and backfill? Read the scorecard against what was said and you will know fast.

A debate is really a reasoning stress test in disguise: adversarial, multi-turn, and either self-consistent across rounds or not. For a model whose reasoner was trained mostly on physical and spatial problems, watching it carry that reasoning into abstract language debate is a genuinely interesting result.

The trade-offs, honestly

This is not free. A two-round debate with the Pragmatist is six full reasoning-model calls: the Advocate twice, the Skeptic twice, the Pragmatist, and the Arbiter. Reasoning models also emit a lot of thinking tokens. More rounds means more cost and more waiting.

For this use case it is worth it, because the structure is the product and watching the reasoning unfold is the whole point. For a plain question-and-answer task, it would be massive overkill. Match the architecture to the job.

Wrapping up

You now have a working multi-agent debate council. It models a structured debate as an explicit LangGraph state machine instead of a prompt, threads real rebuttals through a shared append-only transcript, runs every seat on NVIDIA Cosmos 3 while surfacing its chain-of-thought, and serves the whole thing through one Nebius Token Factory key over an OpenAI-compatible API.

From here the graph makes it easy to keep going. Add seats like a Historian or a Domain Expert. Let the Arbiter call a tie-breaker round. Wire in retrieval so arguments cite real sources. Or run a tournament of motions and chart which side the model tends to favor. Each one is just a few more nodes and edges.

Want to try it? Clone the repo, grab a Nebius Token Factory key, and convene your own council. Pick a motion you genuinely cannot call, and see how Cosmos 3 reasons its way through it.

Built by Arindam Majumder. Part of the awesome-ai-apps collection, powered by LangGraph, NVIDIA Cosmos 3, and Nebius Token Factory.

The Best Vercel Analytics Alternative When You Outgrow the Free Tier

Arindam Majumder — Sat, 13 Jun 2026 20:16:35 +0000

TL;DR

Vercel Analytics is a convenient starting point for Vercel-hosted projects, especially when you only need simple traffic analytics.
The Hobby plan includes a capped monthly Web Analytics allowance. If your site grows beyond that allowance, you may need to upgrade or move to another analytics setup.
Speed Insights is separate from Web Analytics and has its own data-point limits and pricing model.
Raah is a strong Vercel Analytics alternative when you want traffic analytics, Core Web Vitals, network performance, third-party script monitoring, frontend errors, and user journeys in one dashboard.
You do not need to move your app away from Vercel to use Raah. Add one lightweight beacon and keep your existing hosting workflow.

Vercel Analytics is one of the easiest ways to add traffic analytics to a Vercel-hosted site. If you already deploy with Vercel, the setup is simple, the dashboard is clean, and the data is useful enough for many early projects.

But the free tier has limits.

On the Hobby plan, Vercel Analytics includes a capped amount of monthly Web Analytics events. Once your site grows beyond that allowance, tracking can stop until the next billing cycle unless you upgrade. Vercel also prices additional Web Analytics events on paid plans, and Speed Insights has its own separate usage model.

That is fine for some teams. But if you want predictable analytics, privacy-friendly tracking, Web Vitals, network performance, and user behavior insights in one place, you may want a Vercel Analytics alternative.

That is where Raah fits.

Why people look for a Vercel Analytics alternative

Most people do not start looking for an alternative because Vercel Analytics is hard to use. They start looking because their needs change.

Common reasons include:

Your site is growing beyond the Hobby analytics allowance.
You do not want analytics tied to your hosting provider.
You want traffic analytics and performance monitoring in one dashboard.
You need deeper frontend observability than pageviews alone.
You want cookie-free analytics without consent banner complexity.
You want to monitor Core Web Vitals, API calls, third-party scripts, and user journeys together.
You deploy across Vercel, Netlify, Cloudflare, custom servers, or multiple platforms.

Vercel Analytics is convenient if your whole world lives inside Vercel. Raah is built for teams that want analytics to follow the product, not the hosting provider.

Vercel Analytics free tier: what to know

Vercel's Hobby plan includes a free Web Analytics allowance, but it is capped. Vercel's public pricing also lists paid Web Analytics usage at a per-event rate on paid plans.

Speed Insights is separate from Web Analytics. On the Hobby plan, Vercel provides a free Speed Insights allowance for one project, with its own data-point limits.

That means your actual analytics setup may involve more than one usage bucket:

Web Analytics events
Speed Insights data points
Add-ons if you are on a paid plan
Usage-based pricing as traffic grows

For small personal projects, this may be enough. For a growing product, SaaS app, content site, or startup landing page, those limits can become part of your analytics decision.

For the exact current numbers, always check the official Vercel pricing page and Speed Insights limits and pricing documentation.

What to use instead: Raah

Raah is a privacy-first website analytics and frontend observability platform for developers.

You add one lightweight script to your site, and Raah gives you:

Pageviews and visitor analytics
Referrers and UTM campaign tracking
Device, browser, country, and city breakdowns
Core Web Vitals monitoring
Network request performance
API and endpoint timing
Third-party script performance
User journey visibility
Frontend error tracking
Performance alerts
Cookie-free tracking without fingerprinting

Raah is built for teams that want to understand both traffic and user experience.

Traditional analytics tools tell you what pages people visit. Raah also helps you understand whether those pages are fast, which APIs are slow, which third-party scripts are hurting performance, and where users are coming from.

Vercel Analytics vs Raah

Feature	Vercel Analytics	Raah
Basic pageview analytics	Yes	Yes
Works outside Vercel	Limited by setup and use case	Yes
Cookie-free analytics	Yes	Yes
Core Web Vitals	Via Speed Insights	Yes
Network request monitoring	Limited	Yes
API performance from the browser	Limited	Yes
Third-party script performance	Limited	Yes
User journey insights	Limited	Yes
Privacy-friendly by default	Yes	Yes
Hosting-provider independent	No	Yes

Vercel Analytics is a good fit if you want simple analytics for a Vercel project.

Raah is a better fit if you want a fuller picture of what users experience after they land on your site.

When should you switch from Vercel Analytics?

You should consider switching when analytics becomes part of how you run the product, not just something you occasionally check.

For example, switch when you want to answer questions like:

Which marketing campaigns are bringing users who actually engage?
Which pages are slow for real users?
Are API calls slowing down the user journey?
Which third-party scripts are hurting load time?
Where are users dropping off?
Are performance issues happening for specific countries, browsers, or networks?
Can I monitor analytics and frontend reliability in one dashboard?

If you only need a simple pageview counter, Vercel Analytics may be enough.

If you need traffic analytics plus real-user performance monitoring, Raah gives you a broader view.

How to add Raah to a Vercel site

You do not need to move your app away from Vercel to use Raah.

Raah works with Vercel-hosted sites, Next.js apps, React apps, Astro sites, Vue apps, Nuxt apps, SvelteKit apps, and other frontend frameworks.

The setup is usually one script tag:

<script
  defer
  src="https://t.raah.dev/script.js"
  data-pid="YOUR_PROJECT_ID"
  data-domain="YOUR_DOMAIN"
></script>

After deployment, open your Raah dashboard and visit your site. Data usually starts appearing within a few minutes.

If you use Next.js, you can also follow the framework-specific setup in the Raah beacon installation guide.

Why Raah is a strong Vercel Analytics alternative

The biggest reason to use Raah is that it combines analytics and frontend observability.

You do not just see that a page received traffic. You can see whether the experience was good.

That matters because traffic without performance context can be misleading. A campaign may bring users, but if the landing page has poor LCP, slow API calls, or a blocking third-party script, those users may leave before converting.

Raah helps you connect those dots:

Acquisition: Where users came from.
Behavior: What pages and journeys they followed.
Experience: How fast the site felt.
Reliability: Which requests, scripts, or errors affected the session.

That makes Raah useful not only for marketers, but also for founders, developers, and product teams.

Final verdict

Vercel Analytics is a convenient starting point for Vercel projects. The free Hobby allowance is useful for small sites, but growing products often need more flexibility, deeper visibility, and analytics that are not tied to one hosting platform.

If you are looking for a Vercel Analytics alternative that gives you privacy-friendly web analytics, Core Web Vitals, network performance, third-party script monitoring, and user journey insights in one dashboard, Raah is built for that.

You can keep hosting on Vercel.

Just use Raah to understand what your users are actually experiencing.

[Boost]

Arindam Majumder — Tue, 09 Jun 2026 16:13:29 +0000

Arindam Majumder for Raah

Jun 9

Introducing Raah

#web #webanalytics #webdev #javascript

3 min read

Introducing Raah

Arindam Majumder — Tue, 09 Jun 2026 14:30:00 +0000

Today, we are introducing Raah, a privacy-first analytics and frontend observability platform for teams that need a clearer view of what real users experience in production.

Most products treat analytics, performance, errors, and uptime as separate problems. In practice, they are the same question from different angles: are people finding your product, using it, and getting a fast, reliable experience?

Raah answers that from one lightweight beacon. You get traffic analytics, Core Web Vitals, browser errors, API timing, third-party script impact, alerts, and status pages in one dashboard, without cookies or fingerprinting.

The goal is simple: help small teams move from scattered signals to production truth.

Why we built Raah

Most teams stitch together analytics, Web Vitals tooling, error tracking, uptime checks, and backend monitoring. Each tool is useful on its own, but the complete picture is still hard to read.

You may know a page received traffic, but not whether it loaded slowly. You may know an API was healthy from your server logs, but not whether users on a regional network saw high latency. You may know conversion dropped, but not whether a third-party script, JavaScript error, or poor INP contributed to the problem.

Raah is built around a simple belief: product and engineering teams should be able to see user behavior and user experience together.

What Raah gives you

Raah starts with the questions teams ask every week:

How many people visited, where did they come from, and which pages mattered?
Which pages are slow for real users, not just in a lab test?
Which API endpoints are creating the worst p95 or p99 experience?
Are errors concentrated in a browser, region, ISP, or release?
Did a marketing campaign bring traffic that actually engaged?
Can we explain an incident with real user evidence?

Instead of forcing those answers across several dashboards, Raah brings the main signals into one workflow.

Analytics without the usual privacy baggage

Raah tracks visits, pageviews, referrers, UTM campaigns, devices, geography, sessions, and engagement without setting cookies or fingerprinting users.

That makes it a practical alternative for teams that want useful product analytics without turning a simple website into a consent and tracking project.

The goal is not to recreate every enterprise marketing analytics feature. The goal is to give developers, founders, and product teams a clear read on what is happening and what deserves attention.

Frontend observability built in

Traffic alone does not tell you whether the experience was good. Raah also captures frontend reliability and performance signals from real browsers:

Core Web Vitals including LCP, CLS, INP, FCP, and TTFB
Browser-level network timing including DNS, TCP, TLS, TTFB, and download phases
API endpoint latency, error rate, and percentile breakdowns
JavaScript errors and unhandled promise rejections
Third-party script performance
Session-level context for debugging what happened

Real user network monitoring

Synthetic checks are useful, but they run from known locations under controlled conditions. They do not show what every user saw from their own browser, device, ISP, and geography.

Raah captures browser-level network telemetry from live traffic, so you can compare API and page performance by endpoint, country, ISP, status code, and timing phase.

That matters when a service looks healthy from your infrastructure but feels slow to customers in a specific region or network.

Built for small teams that need production truth

Raah is designed for teams that need practical visibility without a heavyweight rollout:

SaaS teams debugging inconsistent endpoint latency
Founders watching traffic, campaigns, performance, and reliability from one place
Agencies managing client websites without cookie-heavy analytics setups
Product teams connecting user behavior to frontend experience
Engineering teams that want alerts and evidence before users complain

You can start with a single script tag and let real traffic populate the dashboard.

Getting started

Create a project in the Raah dashboard.
Install the lightweight script.
Let live traffic populate metrics.
Use breakdowns by endpoint, ISP, geography, and session context to investigate outliers.

Raah was built to help teams move from “we think it is fine” to “we know what users are seeing.”

Claude Opus 4.8: Effort Controls, Dynamic Workflows, and an Honest-by-Default Coding Agent

Arindam Majumder — Fri, 29 May 2026 04:51:37 +0000

The frontier model race has been moving in fits and starts. OpenAI shipped GPT-5.5 and a new Codex line. Google pushed Gemini 3.1 Pro and a faster Gemini Flash. xAI keeps iterating on Grok. And now Anthropic has shipped Claude Opus 4.8, only 41 days after Opus 4.7, which is an unusually short release cycle for them and a clear signal about how the rest of 2026 is going to feel.

Opus 4.8 is not a flashy rebrand. The headline numbers are real (SWE-bench Pro at 69.2%, USAMO 2026 at 96.7%, GraphWalks at 1M tokens jumping from 40.3% to 68.1%), but the more interesting story is structural: effort controls you can dial per request, dynamic workflows that orchestrate hundreds of parallel subagents, a fast mode that is roughly three times cheaper than it used to be, and a measurable drop in the kind of overconfident, slightly-deceptive coding behavior that makes agents annoying to trust.

In this article, I will walk you through everything you need to know about Opus 4.8. We will cover the release details, the new effort tiers, the Dynamic Workflows feature in Claude Code, the pricing changes, the honesty and alignment improvements, two practical things you can build with it today, and an honest assessment of where it still falls short. By the end, you should have a clear mental model of when to upgrade, when to wait, and how to actually use the new controls.

What Is Claude Opus 4.8?

Claude Opus 4.8 is Anthropic's new flagship model, released on May 28, 2026 and available immediately across the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. The API model ID is claude-opus-4-8. It ships at the same headline price as Opus 4.7, keeps the 1M-token context window, and is positioned squarely at agentic coding, long-horizon reasoning, and multi-day workflows.

Here is what makes Opus 4.8 stand out:

Effort controls everywhere: low, high (default), extra (xhigh), and max tiers you can pick per request, with high tuned to spend roughly the same tokens as Opus 4.7's default while doing better work.
Dynamic Workflows in Claude Code: a research preview that lets the model plan a job, spin up hundreds of parallel subagents, verify their outputs adversarially, and resume across multi-day runs.
Cheaper fast mode: 2.5× output speed at $10/$50 per million tokens, roughly three times cheaper than the previous Opus fast mode.
Honesty by default: a four-fold reduction in unreported code flaws versus Opus 4.7, a 0% rate of uncritically reporting flawed results (the first Claude model to hit zero on that test), and a ten-fold reduction in overconfidence.
Big agentic coding gains: SWE-bench Pro at 69.2%, leading every published competitor on that benchmark.
Long-context retrieval breakthrough: GraphWalks BFS at 1M tokens jumps from 40.3% to 68.1% F1, the biggest single benchmark gain of the release.
New API ergonomics: the Messages API now accepts system entries inside the messages array, letting you update instructions mid-task without breaking the prompt cache.

Pricing and Availability

Opus 4.8 launches at the same standard rate as Opus 4.7, which keeps the upgrade math simple.

Standard: $5 per million input tokens, $25 per million output tokens.
Fast mode: $10 / $50 per million tokens for roughly 2.5× the output speed. Anthropic describes this as "three times cheaper than fast mode for previous models," which is the real story here: latency-sensitive workloads that were borderline on the old Opus fast mode become economically reasonable on 4.8.
Context window: 1,000,000 tokens, unchanged from 4.7.
Access: Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry, claude.ai, Claude Code, Cowork, and (as of release day) GitHub Copilot.

Because price did not move, the upgrade decision for most teams is just a function of whether the benchmark and reliability gains help your specific workload.

Benchmark Performance

The benchmark deltas are the cleanest part of the release.

Coding

SWE-bench Pro: 69.2% (up from 64.3% on Opus 4.7). For comparison, GPT-5.5 sits at 58.6% and the next competitor at 54.2%.
SWE-bench Verified: 88.6% (up from 87.6%).
SWE-bench Multilingual: 84.4% (up from 80.5%).

Opus 4.8 leads every SWE-bench variant. This is the most useful headline number for anyone building a coding agent today.

Math and Reasoning

USAMO 2026: 96.7% (up from 69.3% on 4.7). A 27.4-point jump in one model cycle is not a normal benchmark delta. Anthropic is describing this as a qualitative change in mathematical reasoning depth, not a tuning win.

Long-Context Retrieval

GraphWalks BFS at 1M tokens: 68.1% F1 (up from 40.3%).
GraphWalks Parents at 1M tokens: 83.3% F1 (up from 56.6%).

This is the release's biggest relative lead. If your application leans hard on long-context retrieval (legal review, large repo navigation, research synthesis), 4.8 is a different model than 4.7 for that work.

Other Notable Scores

HLE with tools: 57.9%
OSWorld-Verified (computer use): 83.4%
MCP-Atlas: 82.2%
Finance Agent v2: 53.9%

Where It Regressed

GPQA Diamond: 93.6% vs 94.2% on 4.7. Near-saturated benchmark, so variance at the top is expected, but worth flagging.
Terminal-Bench 2.1: 74.6%, behind GPT-5.5's 78.2%.
Multilingual tasks: trails Gemini 3.1 Pro and GPT-5.5 in several languages.

Take the benchmarks as directional. The honesty and reliability deltas below matter more for production use.

Effort Control: The Knob You Have Been Waiting For

Opus 4.8 exposes four effort tiers, and you can set them per request.

Low: fast responses, minimal token use. Best for summarization, classification, and simple Q&A.
High (default): Anthropic's "best balance" tier. Tuned to spend similar tokens to Opus 4.7's default while outperforming it on coding.
Extra (xhigh): recommended for difficult tasks and long-running async workflows.
Max: maximum token depth. Reserve for quality-only priorities where you do not care about cost.

The effort knob is exposed in claude.ai and Cowork (all plans), in Claude Code via the existing effort menu, and in the API. Claude Code's rate limits have been raised to accommodate the new high default. This is the kind of control that used to live behind enterprise sales conversations, and getting it as a first-class request parameter is a quiet but meaningful win.

A practical migration heuristic: move to Opus 4.8 on the default high tier first, then sample representative tasks at xhigh to model the token-cost delta before turning it on in production.

Dynamic Workflows: Hundreds of Subagents, Multi-Day Jobs

The biggest new feature in this release is Dynamic Workflows, a research preview inside Claude Code that lets Opus 4.8 orchestrate work normally reserved for a small engineering team.

The capability, in short:

The model plans a job.
It spins up tens or hundreds of parallel subagents to execute pieces of it.
Other agents adversarially try to refute the findings before they are reported.
State is checkpointed, so jobs survive interruptions and resume across multi-day runs.
Coordination happens outside the conversation thread, so the main session stays responsive.

The use cases Anthropic is pointing at:

Codebase-wide bug hunts and dead-code discovery.
Security and hardening audits.
Large migrations: framework swaps, language ports, API deprecations.
Verification-heavy tasks where you want independent attempts plus an adversarial reviewer.

The canonical case study is Bun's Zig-to-Rust port, run by Jarred Sumner: 750,000 lines of Rust generated, 99.8% of the test suite passing, eleven days from first commit to merge. The workflow first mapped lifetime requirements, then parallel writers generated every .rs file with two reviewers per file, and an overnight fix loop addressed a data-copy optimization. That is a real-world result, not a benchmark.

Activation

Inside Claude Code, you turn it on in any of three ways:

Enable auto mode in Claude Code.
Ask explicitly: "create a workflow."
Toggle the ultracode setting, which sets effort to xhigh.

The first trigger shows you a preview and requires confirmation. Dynamic Workflows is available on Max, Team, and Enterprise (admin-enabled), and via the APIs.

Token Cost Warning

Workflows consume substantially more tokens than standard sessions. Plan your budgets before flipping this on in production. The same feature that finishes a quarter's worth of work in days will also spend a quarter's worth of tokens in the same window if you do not watch it.

Honesty, Reliability, and Alignment

This is the part of the release that does not show up cleanly in a benchmark table but matters most for anyone shipping agents.

Code Honesty

Four-fold reduction in unreported code flaws versus Opus 4.7.
Code summary honesty: fails to flag important events only 3.7% of the time.
Uncritically reporting flawed results: 0%. First Claude model to score zero on that test.
Overconfidence: more than ten-fold improvement over Opus 4.7.
Lazy investigation: perfect score. Opus 4.7 gave incorrect answers 25% of the time on the same probe.

Read those as one trend: Opus 4.8 is significantly less likely to hand you a confident-sounding summary that papers over a real problem. Bridgewater Associates' testimonial in Anthropic's launch coverage explicitly calls out "Opus 4.8's tendency to proactively flag issues with the inputs and outputs of an analysis" as the differentiator.

Alignment

Stronger prosocial behavior and user-autonomy support.
Substantially lower deceptive and misuse-enabling behaviors than 4.7.
Reckless or destructive actions reduced significantly.
Overall alignment risk rated "very low."

Agentic Security Caveat

One regression worth taking seriously: prompt-injection robustness dropped. Gray Swan attack success rate climbed to roughly 9.6%, up from 6.0% on Opus 4.7. If your pipeline ingests untrusted external content (scraped web pages, user-submitted documents, third-party tool output) review your sandboxing approach before upgrading.

API Enhancements You Should Actually Notice

The Messages API now accepts system entries inside the messages array. In practice that means you can update instructions mid-task without breaking the prompt cache, which has been a real pain point for long-horizon agents.

Concrete use cases:

Adjusting tool permissions partway through a session.
Reallocating a token budget after a planning step.
Injecting environment context (the user just switched repos, a long-running job finished) without restarting the whole conversation.

For long-running agentic workflows, this single change is more useful than it sounds.

How Opus 4.8 Compares to the Field

A short read on where 4.8 sits today:

vs. GPT-5.5:

Opus 4.8 leads on SWE-bench Pro (69.2% vs 58.6%) and on GDPval-AA ELO by roughly 121 points.
GPT-5.5 still leads Terminal-Bench 2.1 (78.2% vs 74.6%).

vs. Gemini 3.1 Pro:

Opus 4.8 leads on SWE-bench variants and long-context retrieval.
Gemini 3.1 Pro leads on GPQA Diamond (94.3% vs 93.6%) and on several multilingual tasks.

Read those numbers as "Opus 4.8 is the strongest agentic coding model right now, but the multilingual and terminal-harness wins are not universal."

Honest Assessment: Strengths and Limitations

Opus 4.8 is the most useful coding model Anthropic has shipped, but it is worth going in with calibrated expectations.

Where it shines:

Agentic coding gains are real. The SWE-bench Pro lead over GPT-5.5 is large enough to matter on real workloads.
The honesty improvements (four-fold drop in unreported flaws, zero rate on uncritical reporting, ten-fold drop in overconfidence) translate directly into less time spent double-checking the agent.
Dynamic Workflows is a genuine shift, not a gimmick. The Bun port is the kind of result that would have been a quarter of work and is now eleven days.
Effort control as a first-class parameter is the right primitive for cost-aware agent design.
Fast mode at roughly one-third the previous price unlocks latency-sensitive workloads that were borderline before.
Same pricing as 4.7 makes the upgrade decision easy.

Where to be careful:

Prompt-injection robustness regressed (Gray Swan ~9.6% vs 6.0%). If you handle untrusted content, audit your sandbox before upgrading.
Terminal-Bench 2.1 still trails GPT-5.5. If your workload is shell-heavy, benchmark both.
Multilingual tasks remain a relative weakness. Gemini 3.1 Pro and GPT-5.5 win in several languages.
Dynamic Workflows can burn tokens fast. Budget carefully or you will discover the cost on your invoice.
Vending-Bench 2 regressed, hinting at potential issues with highly structured, multi-step transactional interactions. Worth testing if that is your domain.
Pipelines tightly tuned to 4.7 prompts will need re-validation. The honesty improvements change how the model communicates uncertainty, which can ripple through downstream parsing.

When to Upgrade and When to Wait

Upgrade from Opus 4.7 if:

You run agentic coding workflows and want the honesty improvements.
Long-context retrieval is core to your product (the GraphWalks delta is the biggest gain in the release).
You have been hitting silent failures or overconfident outputs.
You want fast mode at the new lower price.

Stay on Opus 4.7 if:

Your production pipeline is meticulously prompt-tuned to 4.7 and you do not have a re-validation window.
You rely on the GPQA Diamond delta at the top of the curve.
You ingest untrusted external content and cannot tighten sandboxing right now.

A safe default migration path: switch the model ID, leave effort at high, validate a representative sample of tasks, then experiment with xhigh for the hardest workloads.

What to Learn Next

A few directions worth exploring once you have Opus 4.8 running:

Effort tuning per workload: profile token spend at each tier on real traffic. The right tier is almost never the same across your app.
Dynamic Workflows playbooks: build templates for codebase audits, migrations, and dead-code sweeps. The reusable bit is the workflow shape, not the prompt.
Mid-task system messages: refactor your long-horizon agents to use the new in-array system entries instead of restarting threads.
Mythos preview: Anthropic has hinted that Mythos-class models will reach general availability in the coming weeks, with the same same-price upgrade pattern. Worth tracking.
Cheaper-with-Opus-capability tier: Anthropic also signaled cheaper models with Opus-level capability are in the works, which will reshape which tier you run by default.

Anthropic's documentation, the Claude API release notes, and the model card for Opus 4.8 are the best primary sources for any of this.

Final Thoughts

Opus 4.8 is not a rebrand and it is not a victory lap. It is a focused release that pushes on the parts of agentic coding that actually slow teams down: silent failures, overconfident summaries, single-thread workflows, and a coarse effort model. The benchmark wins are real, but the more durable shift is structural. Effort controls give you a cost dial. Dynamic Workflows give you a way to run multi-day jobs. The honesty improvements give you a model you can trust to flag its own mistakes.

The 41-day cycle from 4.7 to 4.8, the Mythos hints, and the cheaper-fast-mode pricing together signal that Anthropic is racing. That is good for everyone building on top of these models, but it also means the right play is to upgrade incrementally, measure what changed, and keep your prompts and sandboxes loose enough to absorb the next jump.

If you are building agents right now, switch the model ID, leave effort at high, test your hardest workloads at xhigh, and try one Dynamic Workflow on something you have been putting off. That is enough to see why this release matters.

Building AI Agents That Actually Remember: Memory Systems Explained

Arindam Majumder — Thu, 28 May 2026 14:39:46 +0000

You built an AI agent. It calls tools, plans multi-step workflows, and the first time you run it, the demo feels magical. Then you run it again the next day, and it greets you like a stranger. Same clarifying questions. Same mistakes. Same steps reconstructed from scratch.

That is not a tooling problem. That is a memory problem.

Most agents shipping today are stateless. They execute inside a loop, but they do not accumulate knowledge across runs. Every session starts at zero, which means every improvement they appeared to make last time is gone. If agents are going to automate real work, they have to get better the longer you use them. That only happens with memory, and not just stored data, but structured, evolving memory that compresses experience into knowledge.

In this article, I will break down what memory really means inside an agent, where the standard implementations fall short, how to design memory as a first-class layer in your agent loop, and finally how a system like Engram handles this in practice. By the end, you should have a clear mental model for adding real long-term memory to whatever you are building.

If you like Video more, You can watch this:

What "Memory" Actually Means in an Agent

When people say "memory" in AI, they usually mean storing chat history and pulling it back later. That is not memory. That is replay.

An agent already has context during execution. The system prompt, the tools, the intermediate tool calls, the partial outputs, all of it sits inside the model's context window for the duration of a single run. The moment the run ends, that context evaporates.

The common patch is to dump everything into a vector database, then retrieve the chunks that look semantically similar to the next prompt. This keeps the agent informed, but it does not make it smarter. It is the equivalent of handing someone a transcript of a meeting they never attended and hoping they get up to speed.

Real memory does something more interesting. It compresses raw experience into reusable knowledge. Humans do not remember entire conversations word for word. We remember conclusions, preferences, and patterns. Agents need the same transformation layer between raw execution and stored memory, or they will keep drowning in their own logs.

How Most Agents Are Built Today

The default agent loop looks roughly like this:

The user gives the agent a task.
The agent plans a sequence of steps.
It calls tools, observes results, and produces an output.
The whole transcript is dumped into a database, often a vector store.
On the next run, similar chunks are retrieved and injected back into the prompt.

At a glance, this feels like memory. In practice it builds a system that can recall but cannot learn.

The agent never refines what it knows. It never resolves contradictions. It never updates outdated information. It just accumulates. Over time, the store fills with multiple versions of the same idea, conflicting preferences, and abandoned half-thoughts. Retrieval gets noisier, irrelevant context starts crowding the prompt, token usage climbs, and accuracy drops.

This is the reason so many agents feel stuck at the same level no matter how many sessions you put through them.

The Missing Piece: A Learning Loop

The gap is a learning step between execution and storage.

Most loops look like this:

input → plan → execute → store → end

A real long-term-memory loop should look like this:

input → plan → execute → learn → update memory → next run

That learning step is where transformation happens. Instead of saving raw logs, the system pulls out structured insights and writes those. If a user says they prefer Postgres over MySQL, that is a stable preference, not a line buried in a chat log. If an agent tried three approaches and only one worked, the successful path is a reusable strategy, not noise mixed in with two failures.

Without this step, the agent keeps rediscovering the same things on every run, and you pay for it in tokens, latency, and user trust.

The Three Types of Memory Inside an Agent

It helps to split memory into layers, the same way cognitive science does. Most current systems collapse all three into one bucket, which is exactly why they get confused.

Episodic memory: events. Tool calls, inputs, outputs, failures, timestamps. Useful for traceability and debugging, but rarely the right thing to inject back into a prompt.
Semantic memory: distilled knowledge. Preferences, facts, constraints, decisions. This is what the agent should actually carry across sessions.
Procedural memory: how to do things. Sequences of steps that worked before. This is where agents start becoming efficient, because they can reuse solutions instead of recomputing them.

A good memory system treats these differently. Episodes get logged and mostly left alone. Semantic facts get reconciled and updated in place. Procedures get versioned, scored, and promoted when they keep working.

What a Real Memory System Needs

A working memory layer for agents needs three core operations:

Extraction: take raw input and decide what is worth remembering. Most of what an agent sees is noise. Extraction is the filter that separates a durable fact ("user is on macOS Sonoma, prefers pnpm") from disposable chatter.
Reconciliation: compare new information with what already exists. Update when the facts have changed. Resolve when they conflict. Merge when they are redundant. This is the step that keeps memory clean instead of letting it sprawl.
Retrieval: when the agent runs again, hand it the relevant pieces, not the whole archive. The goal is precision, not volume. A 200-token answer with the right three facts beats a 4,000-token dump every time.

This pipeline is what turns memory into something the agent can rely on instead of something it has to sift through every turn.

How This Changes Agent Behavior

Once a memory layer like this is in place, the agent's behavior changes in ways the user actually notices:

It stops asking the same clarifying questions because it already has the answers.
It avoids paths it has already tried and failed on.
It adapts to the user because preferences are stored and continuously updated.
It gets faster because it reuses successful strategies instead of recomputing them.

At this point the agent stops being a pure execution engine and starts being something closer to an accumulating knowledge system. That is the line between "impressive demo" and "tool I actually use every day."

Engram: A Memory System for Agents

This brings us to Engram, an open-source memory layer designed to sit alongside your agent rather than inside it. The project bills itself as "persistent cognitive memory for AI agents" and is built around exactly the extract → reconcile → retrieve pipeline above.

Here is what makes Engram worth a look:

Memory pipeline, not a bucket: incoming data flows through an extraction step that classifies items as facts, preferences, events, or decisions and assigns an importance score.
Reconciliation built in: new memories are checked against existing ones. Duplicates are merged, conflicts are resolved, and stale entries get pruned instead of piling up.
Dream Cycle: a background consolidation job that runs on a schedule (the docs describe a nightly cadence). It refreshes scores, dedupes, extracts patterns across memories, and prunes things that have gone stale. The biological analogy is not a coincidence.
Ensemble retrieval: multiple embedding models are queried in parallel and combined with Reciprocal Rank Fusion. Recency is weighted so fresh context wins ties.
Memory pools: shared memory spaces with access control, so multiple agents can read and write into the same knowledge base without trampling each other.
Open and self-hostable: Apache 2.0 licensed, runs locally on Apple Silicon or CUDA, with an optional hybrid mode that mixes in cloud embeddings.

Engram exposes itself through a TypeScript SDK, a REST API, and an MCP server, which means it slots into Claude Desktop, Cursor, Windsurf, and anything else that speaks the Model Context Protocol.

Installing Engram

The Python core is a single pip install:

pip install engram-core

Optional extras cover the server, the MCP integration, embedding backends, or the full bundle. For the TypeScript SDK, install the client package alongside whatever agent framework you are already using.

The self-hosted version of openengram.ai ships a setup wizard that walks you through account creation and model configuration, and all features unlock locally at no cost. If you want to start with the cloud-hosted control plane, you grab an API key (ek_...) and point the SDK at it.

A Minimal Code Walkthrough

Here is the smallest end-to-end example using the Python SDK:

from engram import Memory

mem = Memory()

mem.store("User prefers Python", type="preference", importance=8)
mem.store("Project uses Postgres, not MySQL", type="fact", importance=9)

results = mem.search("programming language")
context = mem.recall(limit=10)

store is the extraction entry point. You tag each memory with a type and an importance score so the consolidation pass can reason about it later. search runs full-text and semantic retrieval. recall pulls the top-N most relevant memories for prompt injection.

The TypeScript flavor is just as light:

import { Engram } from '@engram/client';

const engram = new Engram({ apiKey: 'ek_...' });

await engram.remember("User prefers dark mode");
const memories = await engram.recall("UI preferences");

Both SDKs share the same mental model: write through remember / store, read through recall / search, and let the consolidation pipeline keep the underlying store clean in the background.

You can also link memories explicitly to build a small knowledge graph the agent can walk:

bug_id = mem.store("Login fails on Safari", type="error_fix", importance=9)
fix_id = mem.store("Added WebKit prefix to CSS", type="error_fix")

mem.link(bug_id, fix_id, "caused_by")
graph = mem.graph(bug_id, max_depth=2)

That link call is what turns a flat collection of facts into procedural memory the agent can actually follow.

Project 1: Give a Developer Agent a Real Long-Term Memory

Let us put this together with a concrete scenario. You are building a developer agent that helps scaffold and maintain a project. Without memory, every new session restarts the same conversation about your stack.

Bootstrap a tiny project:

mkdir agent-with-memory && cd agent-with-memory
python -m venv .venv && source .venv/bin/activate
pip install engram-core openai

Wire memory into a basic loop:

from engram import Memory
from openai import OpenAI

mem = Memory()
client = OpenAI()

def chat(user_input: str) -> str:
    context = mem.context(user_input, max_tokens=500)

    messages = [
        {"role": "system", "content": f"Known about the user:\n{context}"},
        {"role": "user", "content": user_input},
    ]
    reply = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages,
    ).choices[0].message.content

    mem.store(user_input, type="event", importance=4)
    mem.store(reply, type="event", importance=3)
    return reply

print(chat("Set up a new Node service. I prefer Postgres and pnpm."))
print(chat("Add a users table to the project."))

On the first call, the agent has nothing to recall, so it answers from scratch and writes two events to memory. On the second call, mem.context() returns the relevant prior decisions (Postgres, pnpm) and injects them into the system prompt. The agent never has to ask "what package manager do you use" again, and you never have to repeat yourself.

If you then say "actually, switch this project to Bun," Engram's reconciliation step updates the existing preference rather than appending a contradicting one. That is the difference between a memory system and a log.

Project 2: Wire Engram Into Your Coding Agent Over MCP

The second project shows how to plug Engram into an existing coding agent without writing client code at all. Most modern coding agents (Claude Desktop, Cursor, Windsurf, the Antigravity CLI, and others) speak MCP, and Engram ships an MCP server out of the box.

Start the MCP server:

pip install "engram-core[mcp]"
engram mcp serve

Then add it to your agent's MCP config. For Claude Desktop, edit claude_desktop_config.json:

{
  "mcpServers": {
    "engram": {
      "command": "engram",
      "args": ["mcp", "serve"]
    }
  }
}

Restart the agent. From inside any session you can now ask things like:

Remember that this project uses Drizzle ORM, not Prisma.

What have I told you about my testing setup?

The agent calls Engram's MCP tools to write and read memories, and the consolidation loop keeps the store tidy in the background. The same memory pool is now visible to every MCP-aware agent you use, which is the part most people underestimate the first time they try it.

How to Think About Memory While Building Agents

When you sit down to design an agent, the first question is usually "which model?" or "which tools?" That is the wrong starting point. The first question should be:

What does this agent need to remember, and how should that memory evolve?

Decide what qualifies as durable knowledge for your domain. Decide what should never be stored (raw PII, transient state, things that age out fast). Decide how updates and conflicts are resolved. Then design your loop so that every execution contributes back to that memory, not just consumes from it.

A few practical heuristics:

Store conclusions, not transcripts. A summarized decision is worth ten chat logs.
Score importance at write time. Future-you needs a signal for what to keep when the store gets crowded.
Reconcile, do not append. When the same fact shows up twice, the system should update, not duplicate.
Retrieve narrowly. A small, precise context wins over a giant relevant-ish blob.

That is what turns a collection of tools into a system that actually improves over time.

Honest Assessment: Strengths and Limitations

Engram is one of the most thoughtful entries in the agent-memory space right now, but it is worth going in with calibrated expectations.

Where it shines:

The extract → reconcile → retrieve pipeline matches the way memory should work, not just the way it is easiest to ship.
The Dream Cycle is the right idea. Background consolidation is what keeps memory stores from rotting over weeks of use.
Ensemble retrieval with RRF is a meaningful step up from single-model vector search. Recall stays high even when the query phrasing drifts from how the memory was originally written.
MCP support means it works with the agent you are already using today, not just a bespoke SDK.
Apache 2.0 and self-hostable. Your memories live where you want them to live.

Where to be careful:

Extraction is LLM-driven, which means it can occasionally classify the wrong thing as a durable fact. Importance scoring helps, but you should still spot-check what is being written.
"Memory" is only as good as your write discipline. If you treat it as a dump-everything store, you will recreate the noisy-vector-DB problem inside a nicer wrapper.
The ecosystem around agent memory is moving fast, and Engram is one of several real implementations (some Go, some Rust, some Python). Pick the one whose architecture and license match your deployment, and expect interfaces to keep evolving for the next year.
Hybrid cloud mode is convenient but read the data-handling policy if you are working with sensitive content. Self-hosting is the safer default for regulated workloads.

What to Learn Next

Once you have a memory layer wired in, there are a few directions worth exploring:

Memory pools: share a single store across multiple agents (a researcher, a writer, a reviewer) and watch them coordinate without you writing any glue.
Procedural memory: start storing successful tool-call sequences as reusable strategies, not just facts.
Eval your memory: write tests that check whether your agent remembers the right things across sessions. Memory regressions are real and they are easy to miss without a harness.
MCP everywhere: once memory is exposed as MCP, every agent you use can read and write into the same brain. That is when things actually get interesting.

The Engram documentation at engram.to and openengram.ai is the best place to go deeper, and the GitHub organizations behind the various implementations are active and worth tracking.

Final Thoughts

Most agents today feel powerful in the moment and forget everything afterward. That is the ceiling on what they can become.

Memory raises that ceiling. It lets agents accumulate knowledge, refine behavior, and adapt with use instead of resetting every session. Engram is one good implementation of this idea, but the larger shift is architectural. Agents are not just reasoning systems anymore. They are learning systems, and memory is the layer that makes the learning stick.

If you are building agents right now, focus less on making them smarter inside a single run. Focus on making them better across many runs.

That is where the real leverage is. Give it a try in your next project and see how quickly the dynamic changes.

[Boost]

Arindam Majumder — Mon, 25 May 2026 19:28:42 +0000

Arindam Majumder

May 21

Antigravity CLI: A Hands-On Guide to Google's Terminal Coding Agent

#antigravity #ai #python #webdev

8 min read