DEV Community: Composio

Pi Agent vs OpenCode after 100+ Hours of Real Use ✌️

Shrijal Acharya — Fri, 21 Aug 2026 13:31:28 +0000

Open-source coding agents had a weird start to 2026.

In January, Anthropic suddenly blocked third-party tools from using Claude subscriptions. Overnight, with no warning.

OpenCode got hit the hardest. The team had to remove Claude login support after legal pressure. The commit message was literally just: “anthropic legal requests.”

PI never really cared. It was never built around one provider anyway.

And that kinda brings us to the obvious question. If you’re using your own API keys anyway, which open-source agent do you actually pick?

OpenCode is sitting at 199K stars, probably past 200K by the time you read this, with around 8 million monthly devs.

Then there’s Pi. Bare minimum by design. Four tools. A system prompt under 1,000 tokens. And somehow, top of our benchmark. Again.

ℹ️ We recently covered Pi Agent vs. Claude Code. Check that out if you're not sure whether Anthropic or Pi suits you better

The easiest way I’d frame it is this:

💁 OpenCode is VS Code (bit bloaty). Pi is NeoVim (bare minimum).

So which one do you go for? Let's get into the difference.

TL;DR

Category	Pi	OpenCode	Winner
Real tool use (our eval)	21/30 tasks passed, $0.078 per success	19/30 tasks passed, $0.119 per success	Pi
Total eval spend	$1.64 for all 30 tasks	$2.25 for all 30 tasks	Pi
Speed	362.9s median per task, slowest of the bunch	280.6s median per task	OpenCode
Context overhead	Under 1,000 tokens, prompt + tool defs	~6,900 tokens per request	Pi
Out-of-the-box features	Four tools	Plan mode, MCP, LSP diagnostics, undo/redo, permissions, subagents, and a lot more	OpenCode
Model support	20+ providers, 300+ models, mid-session switching	75+ providers via AI SDK and `models.dev`	OpenCode
Cheap model access	BYOK or local, that's it	Zen gateway at cost, plus Go at $10/month	OpenCode
Extensibility	TypeScript extensions running inside the agent process	Plugins, custom agents, skills, mostly config-driven	Pi
Sessions	Branchable session trees with fork and rewind	Linear log with undo/redo, but survives disconnects	Pi
Surfaces	Terminal	TUI, desktop app, web UI, IDEs via ACP, GitHub and GitLab CI	OpenCode
Permissions	Nothing. Full system access from prompt one, which isn't really my preferred style	allow/ask/deny per tool with glob patterns	OpenCode
Resource footprint	Lightweight, single process	1GB+ RAM for a TUI is kinda crazy	Pi

In summary

Scorecard: Pi 6, OpenCode 6. Dead tie.

And honestly, that feels right. These two are built for pretty different kinds of people anyway.

Remember the VS Code vs. Neovim thing I said earlier?

Pi is more like a platform you program. You get a tiny core and build your own harness around it in TypeScript.

OpenCode is more like a product you configure. You get something much closer to a full Claude Code replacement on day one, then tweak it through config.

Pi wins on efficiency, hackability, and, at least in our eval, raw results.

OpenCode wins on features, provider support, surfaces, and the simple fact that a normal person can pick it up and start using it without building half the setup themselves.

So yeah, the real tiebreaker is basically what kind of person you are. Keep reading.

What is Pi?

ℹ️ A minimal terminal coding agent that ships four tools and expects you to build the rest yourself.

Quick recap if you missed our Pi vs Claude Code post.

Pi is Mario Zechner's answer to harness bloat. He got tired of Claude Code changing under him, so he built an agent where the model gets read, write, edit, and bash, a system prompt of a few hundred tokens, and nothing else. No MCP. No permissions. No plan mode. No subagents. All on purpose.

It now lives under Earendil after his April blog post "I've sold out," and the core stays open-source.

The real product is the extension system. TypeScript files run inside the same process as the agent loop, and Pi can read its own source code. So when you need a missing feature, you literally ask Pi to build it.

That design is also why Peter Steinberger picked Pi as the engine for OpenClaw.

💁 Fun Fact: Pi has "only" 94k stars, but the npm package pulls around 1.3 million downloads a week. Growing crazy fast among developers.

Not everyone is fond of VS Code. 🤷‍♂️

What is OpenCode?

ℹ️ The most starred open source coding agent in the world, and the closest thing to an open, model agnostic Claude Code.

OpenCode is basically an open-source, model-agnostic coding agent that tries to give you the full Claude Code experience without locking you to Anthropic

It is built by the team behind SST, which rebranded to Anomaly in 2026 and moved the repo to anomalyco/opencode.

The numbers are crazy for a free tool. Around 199k stars. Roughly 8 million monthly active developers. Cloudflare publishes official OpenCode setup docs for its own engineers.

Can you believe this free thing is doing over $25M ARR? It's just the tool that's free, there's subscription plans they've introduced from where they make tons of money.

The origin story is crazier than Pi's. The original agent, called TermAI, was created by Kujtim Hoxha back in 2024. Dax Raad and Adam Elmore did the OpenCode rebrand and made it popular. Then Charm hired Hoxha and pulled the repo into its own org. That causes rewritten git history, banned contributors, the whole drama. After the backlash, Charm renamed its fork Crush, and the Dax and Adam project kept the OpenCode name as a from scratch rewrite.

Not anything interesting if you don't care about "history". Lol.

So when anyone says OpenCode in 2026, they mean the Anomaly one.

💁 Fun fact: For the 1.0 release, the team threw out their entire Go based TUI and wrote a new framework called OpenTUI in Zig and SolidJS, because the old one "had performance and capability issues." Can't believe Golang had performance issues at that scale.

A coding agent team writing their own Zig rendering engine for the terminal is the most 2026 thing I can think of. Crazy stuff.

1. Philosophy: Pi vs OpenCode

Our earlier comparisons were open vs closed. This one is open vs open.

Both teams agree on the big stuff. The harness should be MIT licensed. You should bring your own model. Nobody should be vendor-locked in.

They completely disagree on how much harness should exist.

OpenCode's philosophy is that the harness is a real product. Ship plan mode, permissions, LSP integration, MCP, a desktop app, a web UI, IDE support, GitHub actions. Give people everything Claude Code has, minus the lock in.

Pi's bet is that most of that is overhead (not a feature, what OpenCode believes). Frontier models have been RL trained so hard on coding that they already know what a coding agent is. Every tool schema and every injected instruction is context you pay for on every request. So the harness should be close to zero, and you add back only what you personally need.

The disler comparison has the cleanest one liner on this.

"Pi gives you control at the runtime level. OpenCode gives you control at the configuration level."

And yes, there is real beef here. Zechner has publicly called out OpenCode's compaction for pruning tool results and breaking prompt caching.

He is not a fan of their Vercel AI SDK dependency either. More on that below.

2. Agent Architecture: Pi vs OpenCode

Underneath, both use the same basic loop: read the task, call the model, run tools, feed results back, repeat.

The architecture around that loop is where they differ.

OpenCode: client + server

OpenCode splits into a persistent local server and separate clients.

The server handles:

agent logic
LLM calls
tool execution
SQLite session storage
MCP servers

The TUI, desktop app, web UI, and IDE integrations all talk to that same server.

This makes sessions more safe to terminal crashes or SSH drops, and the same server can also run headlessly in CI. The downside is a heavier footprint, with people reporting 1GB+ RAM usage for the TUI setup.

You read it right. Read more about it here: OpenCode is pretty resource inefficient

Pi: single process

Pi keeps everything in one process:

provider layer
agent loop
CLI

It is all TypeScript and small enough to understand without going through a huge codebase.

Pi supports four run modes:

interactive TUI
print mode for scripts
RPC over stdin/stdout
SDK mode for embedding

That SDK is also how OpenClaw embeds Pi.

OpenCode's way of LSP

I'd call it a star feature of OpenCode, the way it handles LSP (Language Server Protocol).

OpenCode can run real language servers such as gopls and typescript-language-server and feed diagnostics back into the agent after edits.

So the flow looks like this:

model edits code → LSP reports an error → model sees it → model fixes it

That gives OpenCode fast compiler and type feedback without needing to run the full test every time.

Pi does not have this out of the box.

Pi's Session trees

Pi way of handling sessions is kinda interesting.

Pi stores sessions as JSONL, with every entry pointing to a parent. That means the session history is a tree instead of one linear log.

A → B → C
     ↘ D → E
     ↘ F → G

You can:

use /tree to jump back to an earlier point
use /fork to branch from any past message
keep multiple debugging paths from the same point

OpenCode uses a linear history with /undo and /redo, which is simpler but less flexible.

Context compaction

OpenCode uses a hidden system agent to summarize the conversation when context gets tight, then hides older messages from the active context.

The criticism is that this can remove useful tool outputs and hurt prompt caching.

Pi also supports compaction, but the implementation is replaceable through extensions, which fits its more hackable architecture.

3. The benchmark. Same model, different harness

Now for the part I was most curious about.

We ran 30 hard agentic tool-use tasks against real apps. Every harness used the same model, DeepSeek V4 Pro (0813) at max reasoning, through our hosted MCP router.

Same model. Same tasks. Same tools. Same verifier checks.

So whatever gap shows up here is mostly the harness.

Here is the full result.

Harness (DeepSeek V4 Pro, hard 30 set)	Tasks passed	Cost per success	Cost per shared success	Avg tokens per task	Avg turns
Pi Agent	21/30 (70%)	$0.078	$0.031	924,990	16.3
Codex	20/30 (66.7%)	n/a*	$0.031	383,722	n/a
DeepSeek Harness	20/30 (66.7%)	$0.076	$0.028	88,562	0.9
OpenCode	19/30 (63.3%)	$0.119	$0.032	710,140	13.1
Claude Code	19/30 (63.3%)	n/a*	$0.074	649,900	12.1
Hermes Agent	18/30 (60%)	n/a*	$0.037	113,894	6.5

ℹ️ *Not comparable because cost measure was incomplete for some cells. Shared success only counts tasks every harness passed.

Pi actually topped the board

Pi finished first with 21/30 tasks passed, while OpenCode landed at 19/30.

It was also cheaper across the full run.

Pi spent $1.64
OpenCode spent $2.25
Pi cost per success was $0.078
OpenCode cost per success was $0.119

That last number looks rough for OpenCode, but there is a catch.

On tasks both harnesses actually passed, they were basically tied. Pi came in at $0.031 per shared success, while OpenCode was $0.032.

So OpenCode was not really more expensive when it worked. It just failed more tasks, and failed runs still burn tokens.

Pi was also painfully slow

Pi had the best pass rate, but it was also the slowest harness in the entire run.

Pi median time was 362.9 seconds
OpenCode median time was 280.6 seconds
Claude Code median time was 181.8 seconds

Pi also averaged 16.3 turns per task, compared with OpenCode's 13.1, and pushed more raw tokens than anyone else.

The difference is that its fixed overhead stays tiny.

The system prompt plus tool definitions stay under 1,000 tokens, and the prefix barely changes between turns. That makes a lot of that repeated context land as cache hits.

The task-by-task split is more interesting

Task	Pi	OpenCode
CRM migration archive	✅ 10/10	❌ 3/10
Slack action items	✅ 5/5	❌ 2/5
Vendor directory	✅ 11/13 checks	❌ 7/12
Handover audit	✅ 11/11	❌ 10/11
PagerDuty timeline audit	✅ 10/10	❌ 9/10
Renewal screen	❌ 5/11	✅ 11/11
Sponsorship screen	❌ 4/11	✅ 11/12
Sheets to Airtable tracker	❌ 8/10	✅ 10/10

Pi did better on the audit and census-style tasks, where patiently reading everything and checking every detail matters.

OpenCode did better on the longer screening and multi-step workflows.

Which is kinda perfect.

Pi wins by being small. OpenCode wins when the workflow benefits from more stuff around the model.

After all this non-sense, the eval ended up being spot on for both of them. 🤧

We did a complete breakdown in this tweet. You might want to check it out.

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

4. Token overhead

This is basically the argument both tools were built around, so let's put some numbers next to it.

The most cited comparison here is the Systima study from July, which also ended up doing 700+ points on Hacker News.

They put a logging proxy between the harness and the model, then measured how much context gets sent before the model even sees your prompt.

Harness	Fixed overhead per request
Claude Code (measured by Systima)	~32,800 tokens
OpenCode (measured by Systima)	~6,900 tokens
Pi	Under 1,000 tokens

OpenCode already looks pretty good here. Around 4.7x less overhead than Claude Code.

Then Pi shows up with under 1,000 tokens, including the tool definitions.

That makes it roughly 7x leaner than OpenCode.

💁 Everyone is somebody's bloatware. 🗿

Matei Zaharia said on X the reason was pretty simple. Pi had the same success rate with 2x less cost.

Our eval points in the same direction too. Pi had the best pass rate and the lowest total spend.

But there is an important catch here.

OpenCode has had some pretty ugly token cases too. There is a GitHub issue where asking something as basic as "what's the tech stack in this project" burned 13,088 tokens on a fresh project.

And Pi is not crazy cheap in every sense either. In our eval, it actually pushed the highest raw token count of all six harnesses, mostly because it took more turns to finish tasks.

So yeah, tiny fixed overhead helps a lot. But lean overhead does not always mean lean sessions.

Worth keeping that distinction in mind.

5. Pricing and the ban

Both tools are free and MIT licensed. Fork them, modify them, ship them.

The difference starts after install.

Pi

BYOK for pretty much any provider
local models through Ollama, vLLM, or llama.cpp
OAuth login where providers still allow it
no paid CLI tier at all

💁 Pi is basically just the harness. You bring the model and pay whoever is serving it.

OpenCode

OpenCode does the same BYOK thing, but it also has its own model options.

BYOK where the provider bills you directly
Zen with curated models sold on a pay-as-you-go basis
Go with open coding models bundled into a cheap monthly plan

Go starts at $5 for the first month, then $10/month, with models like GLM, Kimi K3, Qwen, MiniMax, and DeepSeek.

⚠️ Double check the pricing. OpenCode changes this stuff pretty often.

And honestly, that Go plan is hard to ignore.

For $10/month, it is probably one of the cheapest legit ways to run capable open models through a coding agent right now.

Pi does not really have an equivalent. Its version of "cheap" is running local models, which is useful, but it is not the same thing.

Then Anthropic happened

In January 2026, Anthropic started rejecting Claude Pro and Max OAuth tokens when they were used outside Claude Code.

The error was pretty clear. The credential was "only authorized for use with Claude Code."

OpenCode had been using those subscription tokens by mimicking the Claude Code client, so this hit them directly.

Then came the legal requests, the Claude login code got removed, and we got the now-famous commit message from the intro.

George Hotz called the move "a huge mistake."

OpenAI reportedly went in the other direction and opened Codex subscription access to third-party harnesses, including OpenCode and Pi.

Lol.

The important part for this comparison is pretty simple now.

If you want Claude in either Pi or OpenCode, you are basically paying API rates. OpenCode also gives you Zen as another route.

6. Extensibility

Both are highly customizable, but the extension model is very different.

OpenCode

OpenCode is mostly config driven through opencode.json, plugins, agents, skills, and MCP.

You can add:

custom agents with their own model, prompt, permissions, and step limits
JS or TS plugins with lifecycle hooks like tool.execute.before
custom tools
local and remote MCP servers
skills from .opencode/skills and .claude/skills

{
  "permission": {
    "bash": {
      "git *": "allow",
      "rm *": "deny",
      "*": "ask"
    }
  }
}

Pi

Pi extensions are TypeScript modules loaded directly into the single agent process.

They can:

rewrite or block tool calls
replace built-in tools
filter history
replace compaction
persist custom session state
add TUI components
probably many more...

That gives Pi much deeper runtime control than OpenCode.

ℹ️ OpenCode plugins extend the harness. Pi extensions can modify the harness itself.

The tradeoff is security. Pi extensions run in process with full system access, so they need more trust than OpenCode's plugin model.

7. Permissions and safety

This is probably the biggest gap between the two.

OpenCode has a proper permission system. Every tool can be set to allow, ask, or deny, with glob patterns and per-agent overrides. The defaults are decent too. .env reads are denied by default, and the Plan agent asks before edits or bash commands.

What it does not have is real sandboxing. There is no container or OS-level isolation built in.

Pi goes the other way and basically ships no permission layer at all. From the first prompt, the agent runs with your full user privileges. 🥶

That is intentional. Zechner's say is that once an agent can write files and execute code, permission prompts only get you so far. Pi instead expects you to isolate the whole process using Docker, a microVM like Gondolin, or a policy sandbox like OpenShell.

💁 There is also an optional damage-control.ts extension that checks bash commands against YAML rules. Helps a bit.

So the actual difference is pretty simple.

ℹ️ OpenCode gives you tool-level guardrails. Pi expects you to handle isolation outside the agent.

Which one should you pick?

Pick OpenCode if

You want something close to a full Claude Code replacement without building half the setup yourself
You want plan mode, permissions, MCP, undo and redo, and LSP support out of the box
You want the $10 Go plan for cheap access to capable open models
You work in typed languages and want LSP diagnostics fed straight back into the agent
You are setting this up for a team and actually need proper allow, ask, and deny controls

Pick Pi if

You care about token cost at scale. In our eval, the same model passed more tasks and cost less with Pi
You want a harness small enough that you can actually read and understand the whole thing
You like branching while debugging. Pi's session trees are really good for that
You run local or smaller models where the difference between ~1,000 and ~6,900 tokens of fixed overhead actually matters
You would rather change the harness in TypeScript than spend time configuring someone else's abstraction

The benchmark kinda gives away the answer anyway.

Pi did better on the careful audit-style tasks. OpenCode did better on longer, more structured workflows.

So there probably isn't one winner for everything.

Both are free. Try both and keep the one that fits how you work. ✌️

Conclusion

After all that, I still don’t think there’s one obvious winner here. The scorecard ends 6-6.

OpenCode wins on adoption, features, and ease of use. Pi won our benchmark with 21/30 tasks vs 19/30, lower total spend, and way less fixed overhead.

The bigger difference is still the same one we started with:

OpenCode gives you configuration control. Pi gives you runtime control.

If you just want to install something and start working, pick OpenCode.

If you want to understand and modify the harness itself, pick Pi.

And if cost per successful task starts mattering at scale, keep an eye on Pi. 🤷‍♂️

Pi Agent vs Claude Code After 100 Hours of Real Use 🔥

Shrijal Acharya — Tue, 11 Aug 2026 13:36:48 +0000

While researching for this post, I found out something funny. Pi, the most interesting coding agent of 2026, was built by a guy who got fed up with Claude Code. 🥶

Mario Zechner, the creator of libGDX, was a hardcore Claude Code user. He built cchistory just to track its system prompt changes, and even patched the binary to add features Anthropic had not shipped.

Then he quit and wrote his own agent. Four tools, a tiny system prompt, no MCP, no permissions. He named it Pi so nobody could Google it. What a Chad! 🗿

That small project now has 85k+ GitHub stars, powers OpenClaw, and outscored Claude Code on our own tool use benchmark at a fifth of the cost.

So I put the two side by side. The default everyone uses, against the minimal harness built as a rejection of it.

Let's go!

TL;DR

Category	Claude Code	Pi	Winner
Tool price	Needs a paid plan or API key	Free, MIT licensed	Pi
Real tool use (our eval)	16/30 tasks passed, $0.195 per success	20/30 tasks passed, $0.028 per success	Pi
Predictable billing	$20/month flat on Pro	Pay per token, bills can spike	Claude Code
Model support	Claude models only but it’s built for it	20+ providers, 300+ models, mid session switching	Pi
Out of the box features	Sub agents, teams, plan mode, MCP, skills, checkpoints	Four tools and a text box	Claude Code
Context discipline	Auto compaction, silent context management	You see and control every token	Pi
Extensibility depth	Shell hooks, MCP, skills, plugins	TypeScript extensions running inside the agent process	Pi
Multi agent workflows	Native sub agents and Agent Teams	Spawn pi via bash, or install a community extension	Claude Code
Permissions and guardrails	Deny by default, five modes, sandboxing	Full system access from the first prompt	Claude Code
Surfaces	Terminal, VS Code, JetBrains, desktop, web, mobile, Slack	Terminal	Claude Code
Session model	Linear conversation log	Branchable session trees with fork and rewind	Pi

In Summary:

Scorecard: Pi 6, Claude Code 5.

Pi is the cheaper, more flexible, and more transparent harness, especially if you pay per token, switch models, or want full control. Claude Code remains the better daily driver for most people because it ships with stronger guardrails, predictable subscription pricing, and a polished feature set out of the box. The practical answer is to use Claude Code for everyday work and Pi for custom workflows, local models, and cost-sensitive tasks.

And here is the twist. The scorecard says Pi, but almost everyone who reviews both, including the biggest Pi fans, still runs Claude Code as their daily driver. I will explain why is that in a minute.

What is Pi?

ℹ️ A minimal, open source terminal coding agent that ships four tools and expects you to build the rest yourself.

Pi is the coding agent Mario Zechner released in late 2025, now maintained under Earendil. Zechner joined Earendil in April 2026 in a blog post he titled "I've sold out," and the core stayed MIT licensed.

The whole product fits in literally one sentence. The model gets read, write, edit, and bash, a system prompt of a few hundred tokens, and nothing else.

His reasoning: frontier models have been RL trained so hard on coding agent behavior that they already know what a coding agent is. You do not need 10,000 tokens of instructions to remind them. Need ripgrep? The model runs rg through bash. Need GitHub? It runs gh. Need a browser? Ask Pi to write itself a browser tool.

💁 If you're on the same philosophy, this might be worth reading: Top 10 CLI Tools to Level-Up Claude Code. No MCPs, nothing. Plain raw Bash tools gets most of the work done.

That last part is the actual product. Pi extensions are TypeScript files that run inside the same process as the agent loop, and Pi can read its own source and docs, so the standard workflow when you need a missing feature is to ask Pi to build it.

Everything Zechner refused to ship, the community shipped as extensions within weeks. Todo lists, plan mode, sub agents, permission gates, even an MCP adapter.

What is Claude Code

ℹ️ Anthropic's batteries included coding agent, and the default the entire agent category gets measured against

You know this one. Claude Code started as Boris Cherny's internal AppleScript toy at Anthropic in September 2024, hit research preview in February 2025, and became the fastest scaling developer product anyone has ever measured.

It ships everything: 10+ built in tools, sub agents, Agent Teams, plan mode, MCP as both client and server, Agent Skills, plugins, hooks, checkpoints with rewind, a permission system with five modes, and it runs in the terminal, VS Code, JetBrains, a desktop app, the browser, and your phone.

More than 80% of Anthropic's own engineers use it daily, and around "90% of Claude Code's code is now written by Claude Code". 🥴

1. Philosophy: Pi vs Claude Code

This comparison only makes sense once you understand that Pi exists because of Claude Code.

Zechner was an early Claude Code user. His complaint was never that it was bad. His complaint was that it kept changing underneath him. The system prompt and tool definitions shifted on every release, which broke his workflows and changed model behavior.

So the two tools represent opposite answers to the same question: how much harness does a frontier model actually need?

Anthropic's answer is interesting because it is drifting toward Pi's. Boris Cherny's team deletes harness code every time a new model ships, and in July 2026 Anthropic removed over 80% of Claude Code's system prompt for the Claude 5 generation models with no measurable loss on their coding evals. The bet behind Claude Code is that Anthropic trains the model and the harness together, so scaffolding today can become model behavior tomorrow.

Pi's answer is that the scaffolding was never load bearing in the first place.

💁 Anthropic quietly deleting most of its own system prompt is about the strongest validation of Pi's thesis you could ask for. Zechner just got there a year early.

2. Agent Architecture: Claude Code vs Pi

Both run the same loop underneath. Read the task, call the model, execute tool calls, feed results back, repeat until the model stops asking for tools.

The difference is everything wrapped around that loop.

Claude Code gives the model Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch, NotebookEdit, TodoWrite, there's a lot.... and the Task tool that spawns typed sub agents with their own isolated context windows. Plan mode forces a read only explore and plan phase before any file gets touched.
Pi gives the model four tools, plus optional read only grep, find, and ls behind a -tools flag. There is no plan mode, but pi --tools read,grep,find,ls gets you a read only session in one line. There are no sub agents, and they say that if you want one, tell Pi to run itself through bash, ideally in tmux so you can actually watch it work.

The system prompt gap is the main highlight:

	System prompt	Built in tools
Claude Code (pre Claude 5 era)	~10,000 to 14,000 tokens by community measurement	10+
Claude Code (current)	Cut by over 80% for Claude 5 gen models	10+
Pi	Under 1,000 tokens including tool definitions	4

One less obvious architectural difference: Pi stores sessions as trees, not logs. Every message carries a parent id, so under the hood this is basically a linked list that learned to branch.

A real use case for linked lists, in the wild. All that leetcode grind had something useful. 🤡

So /tree lets you jump back to any earlier point in the conversation and branch from there, and /fork spins a new session off any past message. Claude Code got checkpoints and rewind in 2.0, which covers the common case, but Pi's tree model is the better design.

3. The benchmark: same model, different harness

We ran 30 hard agentic tool use tasks against real apps, eight harnesses, every single one wired to the same model, DeepSeek V4 Flash, through our hosted MCP router, with a 900 second ceiling per task.

Same model, same tasks, same tools. The only thing that changes is the harness, so whatever gap shows up is the wrapper, not the model.

Here is how our two contenders did:

Harness (DeepSeek V4 Flash, hard 30 set)	Tasks passed	Median time	Avg tokens per task	Total cost	Cost per success
Claude Code	16/30 (53.3%)	122.7s	741,659	$3.12	$0.195
Pi	20/30 (66.7%)	132.2s	558,885	$0.56	$0.028

Pi passed more tasks than any of the eight harnesses we tested, and did it at the lowest cost of the whole bunch. Cost per successful task is the brutal column: 3 cents against 19.

Claude Code posted the fastest median time. It just burned 741,659 tokens per task getting there, against Pi's 558,885. The overhead is the story, again.

And yes, that is Claude Code running DeepSeek. That is the whole point of the setup. Only the harness changes.

For the curious, Codex ran the same and landed at 16/30 for $1.29 total. Right between the two.

⚠️ NOTE: Pi ran on high reasoning instead of max, and 24 of its 30 trials went through the official DeepSeek API instead of OpenRouter. Make sure to read the exact numbers with that in mind.

4. Pricing: Claude Code vs Pi

Claude Code

Pro, $20/month or $17/month annually, includes Claude Code
Max 5x at $100/month, Max 20x at $200/month

⚠️ Guys, make sure to double check the pricing. It changes frequently.

Pi

The tool costs nothing. MIT license, fork it, ship it
You bring your own API keys for any provider, or run local models for free through Ollama, vLLM, or llama.cpp
OAuth login for subscriptions where providers allow it

On paper Pi wins on price and Claude Code wins on predictability. A $20 flat rate is genuinely hard to beat for a solo dev using Claude models all day, and per token bills on heavy Pi usage can hit hundreds of dollars a month. I usually prefer the subscription system.

Anthropic locked its subscription OAuth tokens to Claude Code and Claude.ai only. Third party harnesses got cut off, starting with a silent server side block in January, formalized in the docs by February, fully enforced by April. OpenClaw, OpenCode, Cline, and yes, Pi, all lost the ability to run on your Claude Pro or Max subscription.

So the practical situation today: running Claude models through Pi means API rates. Running them through Claude Code means your cheap subscription.

DHH called the move "very customer hostile," Lol.

OpenAI's Codex team publicly went the opposite direction and encouraged third party harness usage.

💁 If your workflow is Claude models all day every day, the subscription math alone mostly settles this comparison. Pi's cost advantage is real on API keys and irrelevant on a Max plan you already pay for.

5. Models: one provider vs all of them

Claude Code runs Claude. Opus, Sonnet, and Haiku tiers, switchable with /model, with thinking effort levels, tuned end to end because Anthropic controls the whole stack.

That vertical integration is why the model feels so at home in the harness. It was trained in it.

Pi runs everything. The pi-ai layer normalizes four API shapes across 20+ providers, from Anthropic and OpenAI to Groq, Cerebras, Mistral, OpenRouter, and local models. Over 300 models total. You can switch models mid session with Ctrl+P, and Pi converts thinking traces between providers.

Claude Code's giant prompt overhead makes it a poor fit for small local models, which is exactly why Simon Willison flagged Pi as the lightweight option for that use case.

6. Extensibility

Both tools are deeply customizable.

Claude Code's model is external and config driven. Hooks are shell scripts that fire on 14 lifecycle events and talk JSON over stdin. MCP servers are separate processes speaking a protocol. Skills are markdown instruction packs with lazy loading. Plugins bundle all of it into installable packages with official and community marketplaces behind a single /plugin command.

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(git status *)"],
    "deny": ["Read(./.env)", "Bash(curl *)"]
  }
}

Pi's model is internal. Extensions are TypeScript modules loaded into the same runtime as the agent loop, hooking 25 event types. They can block or rewrite tool calls before they run, override the built in tools entirely, inject context, replace the compaction logic, persist custom state into the session file, and draw their own TUI widgets. Claude Code's hooks can approve or reject what the agent does. Pi's extensions can change what the agent is.

The tradeoff is trust. Claude Code's marketplace plugins go through some checks and run outside the core process. Pi packages run with full system access, and its own docs tell you to review them before installing.

The sharpest criticism of Pi's ecosystem, from thevinter's "Bad Vibes From Pi", lands exactly here: a lot of those community extensions are themselves vibecoded, so that's something to watch-out for.

7. Permissions and safety

This is the widest gap between the two tools, and neither side considers it a flaw.

Claude Code is deny by default. Every risky action asks first, and you can loosen from there through five permission modes, allow and deny rules, and OS level sandboxing for bash.

When Claude Code has security incidents, and it has had real ones with CVEs attached, they get found, patched, and written up because millions of people are using it.

Pi has no permission system. First prompt, full user privileges, go.

Zechner's argument is that agent security is mostly "theater" 🫩, because once a tool can write code and run code the game is already over. Pi's answer to safety is isolation instead of prompts: run it in Docker, in a micro VM, or behind a sandbox, and there is an opt in extension that checks bash commands against YAML rules if you want a middle ground.

One of them requires you to have read the docs, and the other protects the "intern" who did not.

There isn't much to discuss here. You probably already know how things work by now...

What the Internet thinks

Maybe worth seeing what the internet thinks of Pi and Claude Code by now?

It's more of what we are discussing so far. The famous endorsements is around Pi, the daily usage clusters around Claude Code, and both facts are true.

Let me show you the Pi love first, because it is a lot.

Peter Steinberger built OpenClaw on top of Pi and quote tweeted Zechner with "Mario is the real one we don't deserve." Armin Ronacher wrote that Pi is the coding agent he uses "almost exclusively".

Theo from t3.gg did a whole episode about getting Pi pilled. His take was simple: "The more minimal, the better." Wes Bos and Scott Tolinski spent a Syntax episode arguing Claude Code is overkill for most work.

My favorite line comes from IndyDevDan, who calls Pi the only real Claude Code competitor: "Claude Code is the starter pack. Pi is the endgame."

About 80% of his work still goes through Claude Code. Only 20% goes through Pi. The endgame guy is still playing the starter pack. The internet is wild!

Claude Code does not need loud fans anyway. It has $2.5B in revenue (might increase, researched through Claude itself), 141k GitHub stars, most of the enterprise market, and Microsoft reportedly using it inside their own teams. The numbers are just enough, lol. 🤧

Which one should you pick?

Pick Claude Code if:

You want something that works at full power
You live on Claude models, because the $20 to $200 subscriptions are the cheapest way to run them and Pi is locked out of that pricing
You are deploying to a team and need permissions, SSO, spend caps, and audit trails
You want sub agents, plan mode, and multi surface access without building anything

Pick Pi if:

You pay per token at scale, since less context per task is real money, a fifth of the cost in our eval
You want to mix providers, run open models, or go fully local
You want to read, own, and modify every part of your harness, MIT license and all
You are the kind of engineer who would rather build the exact workflow you want than configure someone else's

Do what most reviewers actually do: run both. Claude Code as the primary builder on your subscription, Pi as the cheap second opinion, the local model runner, and the place where your custom workflows live. The two tools are converging anyway.

Claude Code keeps deleting scaffolding, and the Pi community keeps rebuilding Claude Code's features as extensions. 🤡

Conclusion

The scorecard reads Pi 6, Claude Code 5. And honestly, Pi deserves those wins. It is cheaper per task, open source, works with any model. What more do you want?

But here is the thing. When I sit down with a bug and just want it fixed, I open Claude Code. It works right away, the guardrails just works, the $20 plan keeps the bill consistent, and the model just feels at home in it.

No thinking about the tool itself.

That is the whole story really. Even the biggest Pi fans ship most of their work through Claude Code. It's a secret. 🤫

Zechner was right that these agents need way less scaffolding than we thought. Anthropic deleting 80% of its own system prompt basically admitted it. But being right and being the tool everyone opens every day are two different things, and Claude Code still owns the second one for me.

So use Claude Code for the day job. Keep Pi around for when you want to tinker, go local, or save some money. ✌️

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration

How to build and deploy an MCP server to production (2026-07-28 spec)

Shrijal Acharya — Wed, 05 Aug 2026 12:13:02 +0000

MCP just had its biggest release since launch.

On July 28, the maintainers shipped the 2026-07-28 spec, and it changes how MCP servers work at a pretty fundamental level. The handshake is gone. Sessions are gone. Three long-standing features are deprecated.

The maintainers themselves called it the most substantial change since authorization was added. Their words, not mine.

Sounds scary. But it actually makes MCP servers much easier to deploy. And what am I here for? I'm here to help you build and deploy one.

Your MCP server is now just a regular stateless HTTP service. Round-robin load balancing, autoscaling, and caching all work. No sticky sessions or shared session state.

In this guide, we'll build a small MCP server on the new spec, connect a client to it, see every headline feature actually running, and then deploy it to Cloudflare Workers. For free.

ℹ️ All the code here uses the new TypeScript SDK v2, released alongside the spec. If you're on the old @modelcontextprotocol/sdk package, that's v1 now.

What's Covered

What actually changed in the 2026-07-28 spec in short
Building an MCP server with the new SDK v2
Stateless core in action
MRTR: how a tool requests user confirmation without holding a stream open
A graceful fallback for clients that don't speak MRTR yet (there are many)
Cacheable tool lists with ttlMs
Testing it with a client and raw curl
Deploying it to Cloudflare Workers on the free plan

Changes in the new MCP Spec (2026-07-28)

Quick rundown of what's new. If you want the full changelog, it's on the official spec site.

The handshake is gone

The initialize / initialized exchange and the Mcp-Session-Id header are officially retired.

Every request is now self-describing. It carries its own protocol version, client identity, and capabilities in _meta. Any request can land on any server instance behind a plain load balancer. Such a relief!!

There's an optional server/discover RPC if a client wants capabilities up front. But it's optional. One bare POST is a complete conversation now.

Multi Round-Trip Requests (MRTR)

This one is my favorite.

Before, if a tool needed something from the user mid-call, such as confirmation or a missing parameter, the server had to push an elicitation/create request back over a held-open stream. That meant you needed a held-open stream, which was bad for stateless deployments.

MRTR flips it. The server returns resultType: "input_required" with the questions it needs answered, and closes the connection. The client collects the answers and retries the original call with them attached, plus an opaque requestState token so the server knows where it left off.

No open streams. No sessions. Interactive tools on fully stateless infra.

Header-based routing

Requests now carry Mcp-Method and Mcp-Name HTTP headers. Your gateway, rate limiter, or WAF can route and meter on headers without parsing JSON bodies.

Cacheable list results

tools/list, prompts/list, resources/list, and resources/read responses now carry ttlMs and cacheScope fields, modeled on HTTP's Cache-Control. Clients cache your tool catalog instead of re-fetching it every time they connect.

Extensions framework + deprecations

Tasks moved out of the experimental core into an official extension (io.modelcontextprotocol/tasks). MCP Apps and Enterprise Managed Authorization live there too. You can build your own extensions as well.

And the deprecations:

Roots, Sampling, and Logging are deprecated. They keep working for at least 12 months, but new implementations shouldn't use them.
The legacy HTTP+SSE transport is deprecated with a year-long offramp.
Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents (CIMD).

There's also a formal deprecation policy now: a 12-month minimum window for anything marked deprecated. So you get to plan upgrades, which is noicee!

The SDK Split

One more thing before we build: the TypeScript SDK is no longer one package.

v2 splits it into @modelcontextprotocol/server, @modelcontextprotocol/client, and thin framework adapters (@modelcontextprotocol/hono, express, fastify, node).

Building an MCP Server

Finally, we're onto the build. We will build a quick tiny deploy bot over MCP.

It has three tools:

deploy asks the user for confirmation before deploying (MRTR in action).
list_deployments reads back the deployment history
server_stats proves a fresh server instance handled every request

Here's the trick that pays off at deploy time: all the MCP logic lives in one platform-neutral file (bot.ts), and each platform gets a tiny entry file. Node gets server.ts. Cloudflare gets worker.ts. Both are about ten lines. An MCP server on the new spec is just a fetch handler; the platform is a serving shim.

You'll understand everything along the way.

Step 1: Install the SDK v2

Run the following command:

mkdir updated-mcp-spec-bot && cd updated-mcp-spec-bot
npm init -y && npm pkg set type=module
npm install @modelcontextprotocol/server @modelcontextprotocol/client \
  @modelcontextprotocol/hono @hono/node-server hono zod tsx

ℹ️ On TypeScript 6+, add "types": ["node"] to your tsconfig compilerOptions after installing @types/node. TS 6 no longer auto-includes @types/*, and you'll get Cannot find name 'process' errors without it. Ask me how I know. 😴

Step 2: The server logic

Create bot.ts. This is the whole MCP server, with zero platform code in it:

// 👇 bot.ts

import type {
  CallToolResult,
  InputRequiredResult,
} from "@modelcontextprotocol/server";
import {
  acceptedContent,
  CLIENT_CAPABILITIES_META_KEY,
  createRequestStateCodec,
  inputRequired,
  McpServer,
} from "@modelcontextprotocol/server";
import * as z from "zod/v4";

const deployments: { env: string; at: string }[] = [];
let requestsServed = 0;

type DeployState = { step: "confirm"; env: string };

// set STATE_KEY in production so all instances share the secret
// lazy init: Workers forbids generating random values at module scope
let codec: ReturnType<typeof createRequestStateCodec<DeployState>> | undefined;
function stateCodec() {
  if (!codec) {
    const key = globalThis.process?.env?.STATE_KEY;
    codec = createRequestStateCodec<DeployState>({
      key: key
        ? new TextEncoder().encode(key)
        : crypto.getRandomValues(new Uint8Array(32)),
      ttlSeconds: 600,
    });
  }
  return codec;
}

const CONFIRM_SCHEMA = {
  type: "object" as const,
  properties: { confirm: { type: "boolean" as const } },
  required: ["confirm"],
};

// runs per request, keep it cheap
export function buildServer(): McpServer {
  requestsServed++;

  const server = new McpServer(
    { name: "updated-mcp-spec-bot", version: "1.0.0" },
    {
      cacheHints: {
        "tools/list": { ttlMs: 30_000, cacheScope: "public" },
      },
      requestState: { verify: (...a) => stateCodec().verify(...a) },
    },
  );

  server.registerTool(
    "list_deployments",
    {
      title: "List deployments",
      description: "List all deployments recorded by this server.",
    },
    async (): Promise<CallToolResult> => ({
      content: [
        {
          type: "text",
          text: deployments.length
            ? deployments.map((d) => `${d.env} @ ${d.at}`).join("\n")
            : "No deployments yet.",
        },
      ],
    }),
  );

  server.registerTool(
    "server_stats",
    {
      title: "Server stats",
      description:
        "How many requests this process served, each on a fresh server instance.",
    },
    async (): Promise<CallToolResult> => ({
      content: [
        {
          type: "text",
          text: `pid=${globalThis.process?.pid ?? "edge"} requestsServed=${requestsServed}`,
        },
      ],
    }),
  );

  server.registerTool(
    "deploy",
    {
      title: "Deploy",
      description:
        "Deploy to an environment. Requires confirmation: interactive clients get a prompt, others must pass confirm: true.",
      inputSchema: z.object({
        env: z.enum(["staging", "prod"]).describe("Target environment"),
        confirm: z
          .boolean()
          .optional()
          .describe("Set true to confirm, only after asking the user"),
      }),
    },
    async (
      { env, confirm },
      ctx,
    ): Promise<CallToolResult | InputRequiredResult> => {
      const caps =
        (ctx.mcpReq.envelope as Record<string, unknown> | undefined)?.[
          CLIENT_CAPABILITIES_META_KEY
        ] ?? server.server.getClientCapabilities();
      const canElicit = Boolean(
        (caps as { elicitation?: unknown } | undefined)?.elicitation,
      );

      if (canElicit) {
        const state = ctx.mcpReq.requestState<DeployState>();
        const confirmed = acceptedContent<{ confirm: boolean }>(
          ctx.mcpReq.inputResponses,
          "confirm",
        );
        if (!state || !confirmed?.confirm) {
          return inputRequired({
            inputRequests: {
              confirm: inputRequired.elicit({
                message: `Deploy to ${env}? This will go live.`,
                requestedSchema: CONFIRM_SCHEMA,
              }),
            },
            requestState: await stateCodec().mint({ step: "confirm", env }),
          });
        }
        const record = { env: state.env, at: new Date().toISOString() };
        deployments.push(record);
        return {
          content: [
            { type: "text", text: `Deployed to ${record.env} at ${record.at}` },
          ],
        };
      }

      // fallback for clients without elicitation support
      if (confirm !== true) {
        return {
          content: [
            {
              type: "text",
              text: `Deploy to ${env} needs confirmation. Ask the user, then call deploy again with confirm: true.`,
            },
          ],
        };
      }
      const record = { env, at: new Date().toISOString() };
      deployments.push(record);
      return {
        content: [
          { type: "text", text: `Deployed to ${record.env} at ${record.at}` },
        ],
      };
    },
  );

  return server;
}

A few things worth explaining here:

buildServer() runs on every single request. Not once at startup. Every request gets a brand-new McpServer instance.

If that surprises you, I get it. It surprised me too. But this is literally the canonical pattern from the SDK's own examples, and it's the whole point of the release.

Construction is just object creation and a handler map, microseconds of work. There's no protocol state to preserve anymore, so there's nothing to keep alive.

Per-request server construction, per-process resources. App state (our deployments array, the state codec, your DB pool in real life) lives at module level. The server instance is disposable.

The deploy tool never blocks. When it needs confirmation, it returns inputRequired(...) and the request is over. Done. Connection closed. The requestState token is the only thing that survives between rounds, and it round-trips through the client.

This means the client could tamper with it. That's why we seal it with createRequestStateCodec, so tampered or expired state gets rejected with a wire-level error before our handler even runs.

Notice the codec is lazily created on first use instead of at module level. That looks like a pointless indirection on Node. It's not. Cloudflare Workers forbids generating random values in global scope, and this exact line is what lets the same file run on both platforms. Same story with the globalThis.process?. guards: Workers has no process global by default.

So the tool reads the client's declared capabilities from the per-request envelope (that's the CLIENT_CAPABILITIES_META_KEY lookup, with a legacy-connection fallback) and if:

Client supports elicitation then the full MRTR confirmation flow
Client doesn't then the tool accepts an optional confirm: true argument, and without it, it returns a plain instruction: "Ask the user, then call deploy again with confirm: true"

Step 3: The Node entry

Create server.ts. This is everything Node-specific:

// 👇 server.ts

import { serve } from "@hono/node-server";
import { createMcpHonoApp } from "@modelcontextprotocol/hono";
import { createMcpHandler } from "@modelcontextprotocol/server";
import { buildServer } from "./bot.js";

const handler = createMcpHandler(buildServer);

// in production set ALLOWED_HOSTS to your public domain
const allowedHosts = process.env.ALLOWED_HOSTS?.split(",").map((h) => h.trim());
const app = createMcpHonoApp(allowedHosts ? { allowedHosts } : {});
app.get("/healthz", (c) => c.text("ok"));
app.all("/mcp", (c) => handler.fetch(c.req.raw));

const port = Number(process.env.PORT ?? 3000);
const hostname = process.env.HOST ?? "127.0.0.1";
serve({ fetch: app.fetch, port, hostname }, () => {
  console.error(`updated-mcp-spec-bot listening on <http://$>{hostname}:${port}/mcp`);
});

That's it. createMcpHandler gives you a standard fetch-style handler, and Hono is just routing. createMcpHonoApp() validates Host/Origin headers (DNS rebinding protection) and only allows localhost out of the box, so the ALLOWED_HOSTS env var is there for when this runs behind a real domain.

Everything is env-driven (PORT, HOST, ALLOWED_HOSTS, STATE_KEY) because that's what a VM or a PaaS like Railway wants. We won't use this file for the Cloudflare deploy, but it's your path if you'd rather run this on Node anywhere.

Step 4: The client

Create client.ts:

// 👇 client.ts

import {
  Client,
  StreamableHTTPClientTransport,
} from "@modelcontextprotocol/client";

const url = process.env.MCP_URL ?? "<http://127.0.0.1:3000/mcp>";

const client = new Client(
  { name: "mcp-demooo-client", version: "1.0.0" },
  {
    capabilities: { elicitation: { form: {} } },
    versionNegotiation: { mode: "auto" }, // use 2026-07-28 when the server does
  },
);

// The elicitation handler: in a real app this renders a confirm dialog.
// Here we auto-accept and log what the server asked.
client.setRequestHandler("elicitation/create", async (request) => {
  const { message } = request.params as { message: string };
  console.log(`\n[elicitation] server asks: "${message}" -> answering yes`);
  return { action: "accept", content: { confirm: true } };
});

await client.connect(new StreamableHTTPClientTransport(new URL(url)));
console.log(
  `connected, negotiated protocol: ${client.getNegotiatedProtocolVersion()}`,
);

const tools = await client.listTools();
const { ttlMs, cacheScope } = tools as { ttlMs?: number; cacheScope?: string };
console.log(`tools/list: ${tools.tools.map((t) => t.name).join(", ")}`);
console.log(`cache hints: ttlMs=${ttlMs} cacheScope=${cacheScope}`);

await client.listTools();
console.log("second listTools served from cache");

const before = await client.callTool({ name: "list_deployments" });
console.log(
  `list_deployments: ${(before.content[0] as { text: string }).text}`,
);

const result = await client.callTool({
  name: "deploy",
  arguments: { env: "prod" },
});
console.log(`deploy: ${(result.content[0] as { text: string }).text}`);

const stats = await client.callTool({ name: "server_stats" });
console.log(`server_stats: ${(stats.content[0] as { text: string }).text}`);

const after = await client.callTool({ name: "list_deployments" });
console.log(`list_deployments: ${(after.content[0] as { text: string }).text}`);

await client.close();

⚠️ Don't miss versionNegotiation: { mode: 'auto' }. Without it, the client negotiates the legacy 2025-11-25 protocol and the MRTR flow fails. This took me half an hour to debug.

Notice the elicitation handler is a completely normal elicitation/create handler, the same one you'd write for the old flow. The SDK's auto-fulfillment engine routes the embedded MRTR request through it and retries the tool call for you. Your code doesn't even see the round trip.

Step 5: Run it

In two terminals (better with tmux), run the following:

In the first terminal:

npx tsx server.ts

And in the other:

npx tsx client.ts

This is the kinda output you'd get:

connected, negotiated protocol: 2026-07-28

tools/list: list_deployments, server_stats, deploy
cache hints: ttlMs=30000 cacheScope=public

second listTools served from cache
list_deployments: No deployments yet.

[elicitation] server asks: "Deploy to prod? This will go live." -> answering yes
deploy: Deployed to prod at 2026-08-01T08:02:45.601Z

server_stats: pid=159984 requestsServed=6
list_deployments: prod @ 2026-08-01T08:02:45.601Z

Every line here demonstrates a spec feature, and I designed it that way:

2026-07-28: we're on the new protocol, not the legacy fallback
ttlMs=30000 + served from cache: the second listTools() never touched the network
The elicitation line, then the deploy: that was two tools/call POSTs. First one returned input_required and closed. Second had the answer plus the sealed requestState. No stream was ever held open.
requestsServed=6: six requests, six fresh server instances, one process. Under a load balancer, those six could've hit six different machines. How cool is that?
The final list_deployments: app state survived even though protocol state didn't.

And the math is here: 4 tool calls, plus 2 listTools() where only 1 hit the wire, plus 1 extra round for the MRTR retry = 6 server builds.

Step 6: Look at the raw wire

Let's see the "no handshake" thing. One bare curl, with no initialization:

Run the following command:

curl -s -X POST http://127.0.0.1:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" -H "Mcp-Name: list_deployments" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_deployments","arguments":{},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientInfo":{"name":"curl","version":"1.0"},"io.modelcontextprotocol/clientCapabilities":{}}}}'

btw, this curl command was suggested by Claude.

Here's the result you get back:

{
  "result": {
    "content": [{ "type": "text", "text": "prod @ 2026-08-01T08:02:45.601Z" }],
    "resultType": "complete",
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "updated-mcp-spec-bot",
        "version": "1.0.0"
      }
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

Two things worth noticing in that response.

The result already shows the prod deployment, because I ran this curl against the same server process the client just deployed through.

A totally separate client, no handshake, no session, and it reads the record the TypeScript client wrote. App state persists, protocol state doesn't.

Look at those headers. Mcp-Method and Mcp-Name are right there for your gateway to route on. And the _meta makes the request fully self-describing.

The DX here is genuinely good.

Deploying to Cloudflare Workers

We're deploying this to Cloudflare Workers, and it costs nothing: the free plan gives you 100,000 requests a day and a *.workers.dev subdomain, no credit card needed.

Why Workers? Because it's the natural way for a stateless MCP server. createMcpHandler returns a fetch-style handler, and fetch handlers are literally what Workers runs. The entire platform difference fits in one tiny file.

⚠️ Cloudflare has quick-start MCP templates (npm create cloudflare -- --template=cloudflare/ai/demos/remote-mcp-authless). As of writing, Cloudflare's own docs warn that these still scaffold the deprecated McpAgent path and say, "Do not use that path for a new server." It's the old stateful world, and it doesn't speak 2026-07-28. Skip the template. createMcpHandler is the recommended path, and it's what we're already using.

Step 1: The Worker entry

Create worker.ts:

// 👇 worker.ts

import { Hono } from "hono";
import { createMcpHandler } from "@modelcontextprotocol/server";
import { buildServer } from "./bot.js";

const handler = createMcpHandler(buildServer);

const app = new Hono();
app.get("/healthz", (c) => c.text("ok"));
app.all("/mcp", (c) => handler.fetch(c.req.raw));

export default app;

Eleven lines. Same buildServer, same tools, same MRTR flow.

Two deliberate differences from the Node entry:

Plain new Hono() instead of createMcpHonoApp(). The Host validation in createMcpHonoApp is DNS rebinding protection for localhost servers. Behind Cloudflare's edge, it just gets in the way.
No serve(...). Workers calls your exported fetch handler itself.

Step 2: The wrangler config

Wrangler is Cloudflare's CLI for Workers. It bundles your TypeScript (no build step needed), runs it locally on the real production runtime, manages secrets, and deploys.

npm install -D wrangler

Create wrangler.jsonc:

{
  "name": "updated-mcp-spec-bot",
  "main": "worker.ts",
  "compatibility_date": "2026-07-01",
  "compatibility_flags": ["nodejs_compat"]
}

The nodejs_compat flag fills in Node-ish globals so npm packages behave.

Step 3: Test on the real runtime, locally

npx wrangler dev

This runs worker.ts on workerd, the same engine that runs in Cloudflare production, at http://localhost:8787. Point the client at it:

MCP_URL=http://localhost:8787/mcp npx tsx client.ts

Same full output as the Node run: 2026-07-28 negotiated, cache hints, the MRTR deploy round-trip. Except one line:

server_stats: pid=1 requestsServed=6

pid=1. That's the edge runtime saying hello. 🫡

Step 4: Deploy it

Create a free account at dash.cloudflare.com/sign-up if you don't have one, then:

npx wrangler login

Set the production requestState secret (this is the shared HMAC key, so every edge instance can verify tokens minted by any other):

openssl rand -hex 32          # copy the output
npx wrangler secret put STATE_KEY   # paste it when prompted

⚠️ One gotcha from my own run: the key must be at least 32 bytes or the codec throws at startup. openssl rand -hex 32 gives you 64 hex characters, which is plenty.

And ship it:

npx wrangler deploy

First deploy asks you to pick your free workers.dev subdomain. Ten seconds later:

https://updated-mcp-spec-2026.<your-subdomain>.workers.dev

Your MCP server is live on Cloudflare's global edge.

Step 5: Verify from the outside

Run the Step 6 curl against the public URL (just swap the host), hit /healthz in a browser, and then the real proof:

MCP_URL=https://updated-mcp-spec-2026.<your-subdomain>.workers.dev/mcp npx tsx client.ts

Same output. Except now it's on the internet.

Connect a real agent to it, with no tunnel and no ngrok:

claude mcp add --transport http updated-mcp-spec-2026 \
  https://updated-mcp-spec-bot.<your-subdomain>.workers.dev/mcp

Run /mcp in a Claude Code session to see it connected, then ask it to "deploy to staging". Since Claude Code doesn't declare the elicitation capability yet, our capability-aware fallback kicks in: the tool tells the agent to confirm with you first, you say yes in chat, and the deploy lands.

Bonus: run npx wrangler tail while you do it and watch the requests land in your production logs live.

Here’s a small demo:

One caveat

Our deployments array lives in memory, and on Workers, memory is extra ephemeral: isolates spin up and down per location, so two requests might see different histories. That's not a bug in the demo; it's the whole lesson of the spec, one more time. Protocol state is gone by design, and app state belongs in real storage. On Cloudflare, that's KV, D1, or Durable Objects.

Where Composio fits

What we just built is one server with three tools. Real agents need Gmail, Slack, Notion, GitHub, Linear, and fifty other things.

You could build and deploy a similar server for every one of those. Handle each app's OAuth. Keep up with every API change. Run all that infra.

Or you point your agent at Composio, which gives you 1000+ apps behind a single MCP endpoint:

https://connect.composio.dev/mcp

Build custom MCP servers (like the one we built) for your own domain logic, and let Composio be the app layer for everything else.

Conclusion

The 2026-07-28 spec is a breaking release, and it's the good kind of breaking.

MCP servers are now boring HTTP services. Deploy them like you deploy everything else: stateless, load-balanced, cacheable, autoscaled. The handshake is gone, sessions are gone, and interactive tools work anyway thanks to MRTR.

If you're starting a new server today: use SDK v2, use the createMcpHandler(buildServer) factory pattern, keep resources at module level, seal your requestState, and split your logic from your platform entry. We went from localhost to Cloudflare's global edge with an eleven-line file, and the same split works for Railway, Render, Fly, or a plain VM through server.ts.

If you have existing servers: you've got a 12-month window on everything deprecated. Use it.

Now your MCP server finally gets to be just another web service. 🤌

ℹ️ You can find the entire source code in the repository.

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration

7 Best Claude Cowork Alternatives in 2026 (Free & Open Source Included)

Developer Harsh — Wed, 05 Aug 2026 03:29:13 +0000

At this point, I have become a heavy user of Claude Co-work. I let it handle most of my tasks, like research, content, reports and even YouTube.

However, one thing always bugs me: the $ 100 bill that comes at the end of each month. Yup, that’s the price I pay for owning simplicity and that too at the cost of sharing my data & it's inevitable. This really bugs me.

So I went and looked for alternative versions and found a few. Out of curiosity, I tested a few, and they are surprisingly good. Even one was launched on June 23 (Open Worker by AndrewNG)

This article shares the alternative I tried, what each offers, and how I used them. Though none solves all the problems, but ya reduces/removes some of them - either cost, data sharing, or vendor-lock in.

Let’s begin with revisiting Claude Cowork.

What is Claude Cowork

For those who are probably living under a rock;

Claude Cowork is Anthropic's agentic knowledge-work tool, available with Claude Desktop. It's aimed at people who are non-technical but want to use Claude to do a lot of their mundane tasks like:

reading, editing, and creating files,
pulling from connected apps, and r
returning finished deliverables: reports, spreadsheets, or organised folders

It became quite popular because these are things most top executives always do; it kind of automates that. Also, the experience is polished, effective, and worth the switch (at least that's what I happened to think earlier)

However, it comes at a steep cost for heavy users: Max Plan ($100 or $200/month, depending on usage multiplier). Also, it consumes the limit faster than regular chat because of tool calling, browser use, and PC use, and it shares data with Claude's servers.

If you are someone like me, you probably don’t want that roi on your investment, so here are a few alternatives I figured out.

What to Look for in Claude Cowork Alternatives

Before choosing an alternative, focus on how well it fits your actual workflow—not just how many features it offers. Here are the key factors I considered:

Privacy and data control: Check whether your files and conversations stay on-device, are sent to third-party model providers, or are used for training.
Pricing and usage limits: Compare subscriptions, API costs, rate limits, and the price of running long or tool-heavy tasks.
Model flexibility: Look for support for multiple providers or local models so you are not locked into one AI ecosystem.
Tool integrations: Make sure it connects to the apps you use, such as Gmail, Slack, calendars, browsers, CRMs, and local files.
Autonomy and approvals: A capable coworker should complete multi-step tasks while asking for approval before sending messages, changing files, or taking other consequential actions.
Output quality: Prioritise tools that return polished, usable documents, spreadsheets, presentations, or reports—not just chat responses.
Ease of setup: Consider whether you want a ready-to-use cloud product or are comfortable configuring API keys, permissions, models, and self-hosted infrastructure.
Memory and recurring tasks: Persistent context, scheduled workflows, and background execution matter if you want an agent that improves over time and handles ongoing work.

No single option wins across every category. The best Claude Cowork alternative is the one that offers the right balance of cost, privacy, integrations, and control for your needs.

Top Alternatives to Claude Cowork in 2026

Here’s a quick comparison of the seven alternatives before we examine each one in detail.

Alternative	Best for	Starting price	Open source	Deployment
OpenWorker	Privacy, local control, and model flexibility	Free + model costs	Yes	Local-first
ChatGPT Work	Easy setup and polished business deliverables	Free; paid plans from $8/month	No	Cloud-first
Microsoft Copilot Cowork	Microsoft 365 organisations and enterprise workflows	Copilot licence + usage credits	No	Cloud
Perplexity Computer	Deep research and long-running multi-model tasks	Pro from $20/month	No	Cloud-first
Hermes Agent	Technical users, self-hosting, memory, and automation	Free + model/hosting costs	Yes	Local or self-hosted
Rowboat	Persistent knowledge graphs and context-rich work	$14/month	Yes	Local-first
OpenWork	Shareable agent skills, MCPs, and team workflows	Free; teams from $10/seat/month	Yes	Local or self-hosted

1. OpenWorker

Local-first, open-source AI coworker for private, model-flexible work.

OpenWorker is an open-source, local-first AI coworker built for people who want Claude Cowork-style execution without committing to one model provider.

This is by Andrew Ng, by the way.

It works across local files and everyday apps, produces finished deliverables, and pauses for approval before taking consequential actions. Its strongest advantages are privacy and flexibility: credentials are stored on-device, and your data leaves the machine only through the model providers and integrations you choose. You can use OpenAI, Anthropic, Google, open-weight providers, or Ollama for a fully local setup. The trade-off is setup complexity—you need to supply and manage your own model access, and Windows support is still forthcoming.

Pricing

OpenWorker app: Free and open source; there is no subscription or seat fee.
Model usage: Bring your own API key and pay the selected provider directly based on token usage.
Local option: Ollama can eliminate recurring model provider fees, though you still provide the hardware and electricity.
Additional costs: Connected services may require their own paid accounts. Your total is therefore usage-dependent rather than a fixed monthly bill.
See the official OpenWorker website for current availability.

Pros

Free, open source, and local-first.
Works with multiple hosted providers and local models through Ollama.
Stores credentials on-device and gives you control over where data is sent.
Requests approval before consequential actions.

Cons

Requires you to configure and pay for model providers yourself.
Total API costs can be difficult to predict for heavy workloads.
Less polished and more technical than fully managed alternatives.
Windows support is not yet available.

How to install

You can download a pre-built macOS binary from https://download.openworker.com/mac (signed/notarized, auto-updates).
Or clone https://github.com/andrewyng/openworker and follow the bootstrap script for source builds (Python/Node/Rust prerequisites).
Not available for Windows yet

2. ChatGPT Work

Cloud-based agentic workspace for polished deliverables across connected apps.

Released in July 2026, ChatGPT Work is OpenAI’s cloud-first agentic workspace for turning a requested outcome into a finished document, spreadsheet, deck, site, or other deliverable. It has the lowest setup friction in this list and works well for users who value polished output, long-running execution, and connected-app orchestration. It is available across ChatGPT plans, but limits and model access vary significantly by tier. Unlike local-first alternatives, your work is processed in OpenAI’s environment, and your model choices are limited to what OpenAI makes available. Business and Enterprise plans are the better fit when governance, shared workspaces, and organisational controls matter.

Pricing

Free: $0, with access to Work but the lowest usage limits.
Go: About $8/month, offering more capacity than Free but fewer premium capabilities than Plus.
Plus: $20/month for higher limits and access to more advanced models and tools.
Pro: $100 or $200/month, depending on the usage tier, aimed at heavy individual users.
Business: $20/user/month billed annually or $25/user/month billed monthly, generally with a two-seat minimum.
Enterprise and Edu: Custom pricing, with additional security, governance, support, and administrative controls.
ChatGPT Work is included with eligible ChatGPT plans rather than sold as a separate add-on. API usage is billed separately. Check the official pricing page for current limits.

Pros

Comes with ChatGPT, so no extra cost for the Work product.
Produces polished documents, spreadsheets, decks, sites, and other deliverables.
Offers the easiest setup experience on this list.
Strong connected-app orchestration and long-running task execution.
Available across individual, business, education, and enterprise plans.

Cons

Cloud-first processing provides less local data control.
Limited to models and capabilities selected by OpenAI.
Free and lower-cost plans have tighter usage limits.
Heavy users may need an expensive Pro tier, while API usage is billed separately.

How to install

No install needed; use the ChatGPT web app or official desktop/mobile apps. Least friction option.
Enable Work mode in the interface after signing in with a ChatGPT account.
Connect apps via the built-in integrations/plugins panel or use composio to access 1000+ plus apps.

3. Microsoft Copilot Cowork

Enterprise AI coworker built for end-to-end execution across Microsoft 365.

Microsoft 365 Copilot Cowork is the strongest fit for organisations already centred on Microsoft 365.

It uses Work IQ context to execute multi-step tasks across Outlook, Teams, Word, Excel, PowerPoint, calendars, and tenant data, with approval checkpoints before actions are completed.

Its biggest advantage is deep organisational context and native integration rather than model flexibility. It is cloud-based, governed through Microsoft 365, and designed primarily for enterprise knowledge work.

Setup is straightforward for licensed users, but administrators must enable access and configure usage-based billing.

Pricing

Required licence: An eligible Microsoft 365 Copilot User Subscription Licence is required; the exact base price depends on the organisation’s Microsoft 365 plan, region, and contract.
Cowork usage: Cowork tasks are billed separately through usage-based Copilot Credits.
How task cost is calculated: Microsoft factors in model use, context retrieval, tool calls, and task runtime, so complex workflows cost more than simple ones.
Budgeting: The effective total is the Copilot licence plus consumed credits. Administrators can configure billing and usage policies in the Microsoft 365 admin environment.
Microsoft does not present Cowork as a simple unlimited flat-rate add-on. See the official Copilot pricing page and Cowork pricing explanation for current terms.

Pros

Deep native integration with Outlook, Teams, Word, Excel, PowerPoint, and Microsoft 365 data.
Work IQ provides rich organisational context for enterprise tasks.
Includes approval checkpoints and central administrative controls.
Strong fit for organisations already standardised on Microsoft 365.

Cons

Requires an eligible Microsoft 365 Copilot licence.
Usage-based Copilot Credits make the total cost less predictable.
Offers less flexibility in model and deployment than open-source alternatives.
Setup and billing may require administrator involvement.

How to install

Requires a Microsoft 365 Copilot license (User Subscription License); costs $30 / month/user, billed annually
Access via the Microsoft 365 Copilot app or web interface (toggle to Cowork mode); no separate download for core users.
Enable via admin/Frontier rollout if not yet visible; works on desktop, web, and mobile.

4. Perplexity Computer

Multi-model computer agent for deep research and long-running workflows.

Perplexity Computer is best suited to research-heavy, long-running work that benefits from multi-model orchestration. It can browse, research, create deliverables, connect tools, and run tasks in the background while selecting from multiple frontier models.

This makes it more model-flexible than single-provider products, although execution still happens primarily in Perplexity’s managed cloud environment.

Its research quality, citations, and polished outputs are major strengths; the main constraints are credit-based usage, less predictable costs for heavy workloads, and limited local control compared with open-source options.

Pricing

Free: $0, primarily for standard search; Computer access and credits are limited or unavailable.
Pro: $20/month or about $17/month when billed annually. Includes access to Computer, 4,000 bonus credits, advanced models, and the option to purchase additional usage credits.
Max: $200/month or about $167/month when billed annually. Includes higher model access and 10,000 monthly Computer credits; temporary bonus-credit promotions may vary.
Enterprise: Custom pricing with organisational controls, connectors, security features, and higher-scale usage.
Computer is credit-metered, so intensive browser, research, and generation tasks can consume the allowance faster. Check Perplexity’s official pricing page for current credit allocations.

Pros

Excellent for deep, multi-source research with citations.
Orchestrates multiple frontier models instead of relying on a single model family.
Runs long tasks in the background and returns polished deliverables.
Provides broad browsing, creation, and connected-tool capabilities.

Cons

Credit-based usage can become expensive and difficult to forecast.
Managed cloud execution provides less control than a local-first tool.
The best capacity and model access require the costly Max plan.
Desktop permissions and companion-app setup add friction.

How to install

Download the Perplexity macOS or Windows app from perplexity.ai and sign in.
Install the companion Comet agentic browser for full web automation.
Grant Accessibility, Screen Recording, and Full Disk Access permissions; connect folders and services.
Pair the phone app for 2FA/approvals and remote task kicks.

With all these steps, it might feel like a hassle, but it’s a one-time effort and worth it.

I loved the research reports it created and the use of a background agent. UI also felt smooth.

5. Hermes Agent

Self-hosted, self-improving autonomous agent for technical power users.

Hermes Agent by Nous Research is the most technical and customisable option in this list. It is open source, model-agnostic, and designed around persistent memory, scheduled work, and a learning loop that creates and improves skills over time.

It can run locally, on a VPS, or on other infrastructure, and can be accessed via interfaces such as Telegram, Discord, Slack, and the CLI. This gives you strong privacy and deployment control, but it also demands more setup and maintenance than a managed coworker.

Approval behaviour and data exposure depend on how you configure the model provider, tools, and hosting environment.

Pricing

Hermes Agent software: Free and open source under the MIT licence.
Nous Portal Free: $0 with free models, standard rate limits, and no monthly paid credits.
Nous Portal Plus: $20/month with $22 in monthly credits and a $10 rollover cap.
Nous Portal Super: $100/month with $110 in monthly credits and a $50 rollover cap.
Nous Portal Ultra: $200/month with $220 in monthly credits and a $100 rollover cap.
Bring your own provider: OpenRouter, Anthropic, OpenAI, and other providers are billed at their respective token rates.
Hosting: Local use may cost only hardware and electricity; an always-on VPS adds a separate monthly infrastructure bill. See Nous Portal pricing for current credits and limits.

Pros

Free, open source, model-agnostic, and highly customisable.
Persistent memory and a learning loop help it improve across sessions.
Supports local machines, VPSs, clusters, and multiple chat interfaces.
Handles scheduled and always-on workflows without tying you to one vendor.

Cons

Has the steepest setup and maintenance burden in this list.
Security, approvals, and data exposure depend heavily on your configuration.
Model, tool, and hosting charges can accumulate separately.
Less suitable for non-technical users who want a polished, ready-made experience.

How to install

Linux / macOS / WSL2 / Termux: Run curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
Windows (native PowerShell): Run iex (irm https://hermes-agent.nousresearch.com/install.ps1)
After install, run hermes setup (or hermes model) to configure your LLM provider, then hermes to start.

However, if you are starting out / non-technical, I will suggest starting with Hermes Desktop.

6. Rowboat

Local-first AI coworker powered by a persistent, editable knowledge graph.

Rowboat is a local-first AI coworker built around persistent memory. It turns emails, meeting notes, projects, and other sources into an editable, Obsidian-compatible Markdown knowledge graph, then uses that context to complete work.

It supports hosted models and local options via Ollama or LM Studio, making it flexible for users who care about data ownership and model choice. Background agents, voice, MCP support, and integrated work surfaces make it capable, but its output depends heavily on the quality of the knowledge graph and chosen model.

Initial connector and provider configuration is more involved than with a fully managed cloud product.

Pricing

Open-source deployment: The source is available for users who want to run and configure Rowboat themselves; model, hosting, and optional service costs remain separate.
Starter: $14/month with a seven-day trial, unlimited notes, meeting note-taking, voice mode, current models, knowledge-graph context, background agents, integrations, and MCP access.
Pro: $50/month with everything in Starter, higher or effectively unlimited usage, and more direct access to the team.
External services: Local models can reduce provider fees, while hosted LLMs, voice services, web search, and integration providers may introduce additional usage charges.
See the official Rowboat pricing page for current allowances.

Pros

Builds persistent, editable memory from emails, meetings, and project context.
Keeps its knowledge graph in portable, Obsidian-compatible Markdown.
Supports hosted providers and local models via Ollama and LM Studio.
Includes background agents, voice features, integrations, and MCP support.

Cons

Output quality depends on the accuracy of the knowledge graph and selected model.
Initial provider, connector, and optional service setup may be involved.
Hosted plans and third-party services can add several layers of cost.
Large knowledge graphs may introduce context-management challenges.

How to install

You can download the latest Mac/Windows/Linux release from https://www.rowboatlabs.com/downloads or https://github.com/rowboatlabs/rowboat/releases/latest.
For Google services (Gmail/Calendar/Drive), follow the setup guide in the repo’s google-setup.md.
Optionally add API keys for Deepgram (voice input), ElevenLabs (voice output), Exa (web search), or Composio (1000 + tools) in ~/.rowboat/config/ files.

7. OpenWork

Open-source desktop coworker for shareable skills, workflows, and local automation.

Do not confuse OpenWork with OpenWorker: they are separate products from different teams.

OpenWork is an open-source desktop coworker for individuals and teams that want local file access, broad model choice, and reusable workflows.

It supports more than 50 LLMs through bring-your-own keys and lets teams package and share skills, MCP servers, plugins, providers, and configurations.

Local execution provides strong file control, while team and enterprise tiers add distribution, governance, and deployment options.

The trade-off is that model costs and configuration remain your responsibility unless your organisation manages them centrally.

Pricing

Solo: Free and open source, with desktop access and bring-your-own model keys.
Team Starter: $10/seat/month, billed monthly; the first five seats are free. It adds API access, an extension marketplace, and shared LLM-key distribution.
Enterprise: Custom pricing for SSO/SAML, SCIM, policies, version controls, managed or self-hosted deployment, support, and custom commercial terms.
Model usage: LLM-provider charges are separate from the OpenWork subscription and depend on the models and volume used.
See the official OpenWork pricing page for current terms.

Pros

Free, open-source desktop app with local file access.
Supports more than 50 models and avoids single-provider lock-in.
Makes skills, MCP servers, plugins, and configurations easy to package and share.
Offers team and enterprise governance without forcing a cloud-only deployment.

Cons

Requires users or administrators to configure model keys and providers.
LLM usage charges are separate from team subscription costs.
More technical than a fully managed coworker such as ChatGPT Work.
Some collaboration and governance features require paid plans.

How to install

Paste this prompt into Claude Code, Cursor, Codex, or any command-capable agent:

Install OpenWork on my computer, set up my first workspace, and open it ready to use. Follow the steps in https://openworklabs.com/start.md?v=hero.

Or download directly from https://openworklabs.com/download.

You can also use this one with Claude or Codex using MCP.

For MCP integrations:

# codex
codex mcp add openwork --url https://api.openworklabs.com/mcp/agent
codex mcp login openwork

# claude
claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent

Open Claude Code and run /mcp.
Select openwork, then follow the browser sign-in and choose your organisation.

Connect Any Coworker to the apps your business uses in 2 minutes

Most of these agents need to interact with the real world, and you already know the hassle of connecting multiple tools, adding API keys, performing context management, and writing tool-calling prompts. What if all this can be automated?

That’s where Composio comes in: it offers a unified interface that lets businesses connect to 1000+ tools via verified & secure OAuth, handles tool calls intelligently, manages tool context, provides observability through the Composio dashboard, and ships with its own CLI & Skill.

You can install it with any knowledge worker and get started.

These were my top alternative recommendations to Cowork, but here is the most important factor for these to exist.

Best Claude Cowork Plugins You Must not Miss in 2026 | Composio

A firsthand review of the Claude Cowork plugins that actually improve day-to-day work, with who each plugin is for, what it does, how to install it, and when to use Composio for secure cross-app workflows.

composio.dev

How to choose your Claude Cowork alternative

Start with the constraint that matters most to you, then compare the options against your existing workflow.

Choose OpenWorker if you want a free, local-first coworker with model flexibility and approval checkpoints - and you are comfortable managing API keys.
Choose ChatGPT Work if you want the smoothest setup, polished deliverables, and strong cross-app execution without having to maintain infrastructure.
Choose Microsoft Copilot Cowork if your organisation already runs on Microsoft 365 and needs enterprise context, governance, and native Office integrations.
Choose Perplexity Computer if deep research, citations, browser-based work, and long-running multi-model tasks are your priorities.
Choose Hermes Agent if you are a technical user who wants persistent memory, self-hosting, scheduled tasks, and maximum customisation.
Choose Rowboat if you want a local, editable knowledge graph that turns emails, meetings, and project history into long-term agent memory.
Choose OpenWork if you want an open-source desktop coworker with shareable skills, MCP servers, and team-ready workflows.

A quick decision checklist

Before committing, test your top two choices with the same real task and compare:

Final output: Which one produces the most usable result with the least editing?
Total cost: Include subscriptions, model usage, credits, hosting, and paid integrations—not just the advertised price.
Data exposure: Identify exactly what stays local and what is sent to model providers or connected services.
Setup effort: Decide whether the additional control offered by a self-hosted tool is worth the maintenance overhead.
Daily fit: Check whether it integrates with your core tools and can reliably repeat the workflow.

For most non-technical users, ChatGPT Work is the easiest starting point. For privacy and model freedom, start with OpenWorker or OpenWork.

For enterprise Microsoft environments, Copilot Cowork is the natural choice. Technical users who want maximum control should look at Hermes Agent, while research-heavy users will get the most value from Perplexity Computer.

Conclusion

The shift is real.

I can grab a closed-source powerhouse like ChatGPT Work, Microsoft Copilot, or Perplexity when I want polish and deep integrations, or switch to open-source tools like OpenWorker, Hermes, Rowboat, and OpenWork when I want privacy, local control, and zero lock-in.

Either way, I no longer have to accept the $100 bill, constant data sharing or one-vendor walls as the only option.

Whether you accept it or not, both worlds exist, and knowing which one to use when will be the differentiating factor going forward.

So get your coworkers, try them out, pick the ones that suit the needs, add tools like composio to access tools intelligently and keep adding contributions and fixes to the open ones.

Top Skills & Plugins to use with Grok Build 2026

Developer Harsh — Thu, 30 Jul 2026 13:39:35 +0000

xAI released Grok Build in May, and it’s been improving steadily since then.

With support for spawning up to 8 parallel subagents and a recently added system for skills and plugins, Grok is now a full-fledged ecosystem that rivals contenders like Claude Code and Codex.

However, unlike Claude or Codex, Grok comes with a superpower - it can scrape X data, the real-time engine behind every major announcement, quality content, trends and conspiracies, all with your X subscription.

This gives Grok Build a unique edge for research-heavy workflows. You can track launches as they happen, pull insights from real conversations, spot emerging trends, and turn that live context into apps, agents, or automated workflows.

Access to real-time data is only one part of the equation, though. To make that information useful, Grok needs the right tools to search, process, design, code, and take action across different platforms.

But with so many options in place for a single need, it's hard to find the right one.

This guide aims to cover which ones are worth installing on your first install, why to install them, and how to install them.

Let’s begin with a quick refresher on what skills and plugins are and why you should install them.

What are Skills & Plugins & Why They Matter

The concept of skills and plugins is not new, yet people still often interchange them. Both extend the capabilities of Grok Build and are related but not the same.

Skills are small, reusable instruction packs (usually a SKILL.md plus optional scripts) that turn Grok into a consistent specialist.

They eliminate repetitive, long prompts, enforce high-quality practices such as TDD or careful planning, reduce token waste through focused behaviour, and deliver the same reliable results across projects.

On the other hand;

Plugins are larger, one-command packages that bundle one or more skills with MCP servers, automation hooks, sub-agents, and platform integrations, giving Grok real superpowers.

With plugins, Grok Build can do live web research, control browsers, perform database operations, analyse production errors, and enable seamless deployments.

This is essential for complex agentic workflows and is easy to install, adopt, and share.

With that clarification done, let’s look at how to install skills and plugins in Grok Build before looking at some of the best skills and plugins you should check out/install first.

Related: Best OpenCode Skills

How to install Skills & Plugins in Grok Build

kills

The Official ones listed on the marketplace can be accessed using /marketplace inside Grok Build itself.

Or you can try manual placement

Put skills in ./.grok/skills/ or ~/.grok/skills/

or add an extra path in the ~/.grok/config.toml under [skills] .

Plugins

Grok Plugins can be installed using:

 grok plugin install <name> --trust

and then verify the plugin by doing /plugin .

If it fails, use the Grok Build Marketplace to add it as a plugin.

Or you can add extra paths in ~/.grok/config.toml under [plugins]

For both skills and marketplace, Grok Build comes with automatic compatibility support for .claude/skills and agent/skills. Just put skills there and let grok build pick it up.

Alternative

For non-official skills packs like skills.sh use:

npx skills@latest add <skill>

We will use any one of the methods listed going forward. Now time to look at top skills and plugins.

Top Skills to Use with Grok Build CLI in 2026

These are the top skills I would install if I reinstall Grok Build. Most of them still live in my workspace.

1. Composio CLI: Power Grok with 1000+ apps from GitHub, Linear, to Figma, Canva.

Composio provides Grok Build with access to more than 1,000 applications via a single remote MCP connection. Instead of loading every integration action into the model’s context, it exposes seven meta-tools that let the agent find tools, initiate authorisation, and execute actions when needed.

This makes it useful for workflows involving applications such as GitHub, Linear, Jira, Figma, and other external services. When an application has not been connected, Composio can generate an OAuth authorisation link for the user.

You can install Composio using:

grok mcp add --transport http composio https://connect.composio.dev/mcp

Then type /mcp , select Composio and complete the OAuth flow.

Note: In WSL you can’t access the browser directly, so copy-paste the produced URL and configure it.

Alternatively;

You can type /mcp inside Grok Build, in the mcp window press a to add a new mcp. Add the https://connect.composio.dev/mcp and initiate the OAuth flow

Or install the Composio CLI directly. It's a CLI for everything Composio that can handle authentication management, tool calling, bash scripting and everything in-between.

This gives a more composable way for Grok CLI to work with Composio toolkits.

You can install it with:

curl -fsSL https://composio.dev/install | bash
composio login

Complete the OAuth flow and then add the composio-cli skill

composio --install-skill composio-cli claude

This ensures that composio-cli, used by Grok Build, follows the correct instructions and doesn’t hallucinate.

The reason I put this one at the top is because , it offers the skill, plugins and mcp all bundled together under one ecosystem, so one time config is all you need.

2. Matt Pocock Skills: Add disciplined planning, TDD, debugging, and handoff workflows.

Matt Pocock Skills adds proper engineering discipline to Grok Build.

Similar to superpowers, it helps the agent plan more effectively, avoid common failure modes, and follow structured processes rather than jumping straight into code.

It includes practical skills like /grill-me for questioning plans, /tdd for test-first development, /diagnosing-bugs for testing hypotheses before fixing, and handoff for clean session transfers.

This is still one of the highest-signal skill packs available across coding agents and one of my favourites.

You can install Matt Pocock Skills using:

npx skills@latest add mattpocock/skills

Then run /setup-matt-pocock-skills once inside Grok Build so it learns your project conventions.

Related: Top Codex Skills

3. Caveman: Cut token waste with terse, high-signal agent responses.

Caveman is an answer for those who want to reduce token waste on long sessions. It forces Grok to drop the unnecessary politeness and over-explanation that usually appears in agent responses like Claude Code, Codex, and so on.

In practice, it can cut output length by roughly 65% on average (ranging from ~22–87% depending on the task) while keeping the useful content intact. It's a small skill but one worth keeping enabled almost all the time.

You can install Caveman using:

npx skills@latest add JuliusBrussee/skills --skill caveman

Once installed, toggle it with: /caveman or by saying "talk like caveman"; turn it off with "normal mode."

Companion commands include

/caveman-commit (terse commit messages),
/caveman-review (one-line PR comments), and
/caveman-stats (session savings).

4. Whathappened: Turn real-time X conversations into structured briefings.

If you are X-savvy or want real-time information about X in a structured way, what happened is the answer.

WhatHappened turns real-time X data into clean, structured briefings rather than raw noise, summarises what happened, maps public opinion, surfaces live debates, and pulls key receipts, all using Grok’s built-in X tools.

Note : This skill only works properly inside Grok Build.

You can install whathappened using:

npx skills add kunchenguid/whathappened

and then use: /whathappened <query>

5. XActions Skills: Scrape, monitor, and automate X workflows without the official API.

XActions takes whathappend ability to the next level by doing more than just reading X. It packages scraping, monitoring, and automation capabilities into ready-to-use agent skills.

You can scrape profiles, followers, threads, monitor accounts, or run simple automation tasks without needing the official X API. This is one of the cleaner ways people have begun to package Grok’s X advantage.

You can install XActions Skills by cloning the repository and placing the skills you want under your skills folder:

git clone <https://github.com/nirholas/XActions

Then copy the relevant skill folders into ~/.grok/skills/ or your project’s .grok/skills/.

6. Wangnov/grok-skills: Combine web/X research with image, video, and ffmpeg workflows.

Haven’t tried it yet, but on my to-do list.

Wangnov/grok-skills is especially useful when your workflow needs both research and media generation. It combines web and X research with image generation, video generation, and basic ffmpeg post-processing.

Everything runs through a logged-in Grok session, so you avoid extra API costs for media tasks. It’s a practical all-in-one skill for research-plus-assets work.

You can install Wangnov/grok-skills using:

npx skills add Wangnov/grok-skills

You can learn more at: https://github.com/Wangnov/grok-skills

7. Agentic-Code-Review & Repo-Health-Check: Review code and understand unfamiliar repos safely.

These two skills from the awesome-grok-build starter kits are especially useful for properly reviewing code and getting oriented in unfamiliar repositories.

agentic-code-review focuses on correctness, security, tests and regression risk. repo-health-check helps you quickly understand a new codebase and propose the smallest, safe-first change. Both work well with Plan Mode.

You can install them by cloning the community kit and copying the skill folders:

git clone <https://github.com/DominikTobureto/awesome-grok-build>

Then place the skill folders into your .grok/skills/ directory. Learn more at: https://github.com/DominikTobureto/awesome-grok-build

### 8. GodotPrompter: Give Grok better Godot, GDScript, scenes, and signal context.

If you are building games with Godot and want Grok Build to understand Godot-specific patterns, project structure, and common workflows.

It gives the Grok/Cursor agent better context around GDScript, scenes, signals, and Godot conventions so the suggestions stay more accurate and less generic.

This is one of the cleanest game-engine-focused plugins currently available for Grok Build.

You can install GodotPrompter using:

grok plugin install jame581/GodotPrompter --trust

Then enable it with:

grok plugin enable godot-prompter

Learn more at: https://github.com/jame581/GodotPrompter

9. Hyperframes: Create and edit programmatic videos with HTML, CSS, and JavaScript.

Hyperframes is for those who want a Grok Build or similar agent to create and edit videos using HTML, CSS, and JavaScript rather than traditional timeline editors.

It ships a full set of agent skills that teach the correct patterns for planning compositions, writing valid HyperFrames HTML, adding animations, linting, previewing and rendering.

The main entry skill is /hyperframes, which routes “make me a video” requests to the right workflow.

You can install Hyperframes skills using:

npx skills add heygen-com/hyperframes

and use it with /hyperframes in grok build. Learn more at: https://hyperframes.heygen.com/

10. Remotion Skills: Build production-ready motion graphics and videos with React and TypeScript.

Remotion is similar to Hyperframes in that it allows you to create motion graphics and programmatic videos using React and TypeScript.

It teaches the agent Remotion best practices like compositions, animations, sequencing, rendering and project structure

This makes the output clean and production-ready, rather than generic React code that happens to render video.

You can install Remotion Skills using:

npx skills add remotion-dev/skills

You can learn more at: https://www.remotion.dev/docs/ai/skills

Note: Remotion skill work best inside an existing Remotion project, so better first create it.

Related: Top Design Skills

Top Plugins to Use with Grok Build

Skills are great; some even perform tasks, but for a seamless experience, plugins are mandatory. These are the ones that still reside directly in my skills.

11. Firecrawl: Search, scrape, crawl, and extract clean data from websites.

Firecrawl is especially useful for research, document retrieval, competitive analysis, and data collection from websites.

It gives Grok Build live access to the web through search, scraping, crawling, website mapping, structured extraction, and browser interaction.

It can render JavaScript-heavy pages, handle common anti-bot restrictions, and return content as clean Markdown or structured data.

You can install Firecrawl using:

/marketplace

Then search for firecrawl and press i to install it.

Note: Firecrawl may request authentication when you first use its hosted MCP server.

12. Superpowers: Add structured engineering workflows for planning, TDD, and debugging.

Superpowers is for those who want their agent to plan carefully, validate its work, and follow a more disciplined development process instead of immediately generating code.

It adds structured software engineering workflows to Grok Build, and the current implementation includes test-driven development, systematic debugging, collaboration patterns, and repeatable engineering processes.

I personally use this before switching to Matt Pocock's skills.

You can install it with:

grok plugin install superpowers --trust

Note: Review the plugin before using --trust, since that option skips the interactive trust prompt.

13. Exa: Get fast, high-quality agent-oriented web search results.

Exa provides fast, high-quality agent-oriented search. It works particularly well as a complement to Firecrawl.

Exa's API is purpose-built for LLMs, so results come back structured and filtered rather than cluttered with ads and navigation, fast enough for an agent to search mid-task without breaking flow.

For teams, that means less time and token spend per lookup, so search-heavy steps (competitor checks, source verification, quick fact lookups) stop being a bottleneck inside the coding session itself

Use Exa for quick, accurate retrieval, and switch to Firecrawl for full-page scraping or site crawling.

You can install the Exa plugin using:

/plugin

Then search for exa and press ito install it.

14. Vercel: Let Grok manage deployments, environment variables, logs, and domains.

Vercel is for those who want their agents to deploy their projects on the Vercel platform. It gives Grok direct control over deployments, environment variables, build logs, and domains.

It also keeps Grok aware of current Vercel features, which reduces outdated suggestions.

For teams, this pairing of live platform knowledge with real deploy/env/log access leads to fewer review cycles spent catching agent suggestions that no longer reflect how Vercel actually works.

This fixes a common issue with agent integrations: context drift.

You can install the Vercel plugin using:

/plugin

Then search for vercel and install it using i .

15. Cloudflare: Build and deploy Workers, Durable Objects, and edge apps with platform-aware guidance.

Cloudflare is for those scenarios when part of your stack lives on the other side of the world. It provides skills for Workers, Durable Objects, and related Cloudflare tooling.

The plugin covers the entire Cloudflare developer platform: Workers, Durable Objects, the Agents SDK, MCP servers, Wrangler CLI, and web performance, functioning as a skill library that maps Cloudflare concepts directly to prompts.

This makes scaffolding and deploying edge projects noticeably smoother inside Grok Build for business and working with it easier.

You can install Cloudflare skills or plugins using:

/plugin

Then search for cloudflare and install it using i

Note: Don’t get confused by the name, if you go to official repo , its given as a plugins.

16. Chrome DevTools: Debug frontend issues through live browser inspection, traces, and network data.

Chrome DevTools is useful for frontend debugging and performance work. It lets Grok control a live browser session. (not on WSL)

You can record performance traces, inspect network requests, evaluate JavaScript, and take DOM snapshots without leaving the agent workflow.

Under the hood, this runs on the official Chrome DevTools MCP server, which lets a coding agent control and inspect a live Chrome browser and acts as a Model Context Protocol server, giving the assistant access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.

This means that instead of an engineer manually opening DevTools, reproducing the issue, and reporting back what they saw, Grok can drive the same browser session directly and return a trace, a failing request, or a DOM state as evidence.

You can install the Chrome DevTools plugin using:

/plugin

Then search for chrome-devtools and install it using i

Related: Top Claude Code Plugins

17. Sentry: Pull production errors and stack traces into Grok for faster fixes.

Sentry closes the loop between local development and production.

It lets Grok pull real error data and stack traces. Combined with Seer-powered analysis, it helps turn production issues into concrete fixes faster.

This works through Sentry's official Grok plugin, which connects Grok to Sentry via the Sentry MCP server, providing real production issue-debugging context, code review with Sentry data, and monitoring configuration- on top of SDK setup for any platform.

This means less engineer time spent context-switching between logs, code, and chat to reconstruct what broke, and a shorter gap between an alert firing and a fix landing.

You can install the Sentry plugin using:

/plugin

Then search for sentry and install it. Part of the official Grok Build Marketplace.

18. Unity MCP + CLI: Drive the Unity editor and iterate on game projects from Grok.

If you are like me and like to build games in Unity and want Grok Build to actually drive the editor and project instead of just writing C# in isolation.

People are already using this combination to let Grok open scenes, modify GameObjects, work with the Asset Store, and iterate on playable prototypes much faster. It is currently one of the most practical ways to pair Grok Build with Unity.

You can set it up by installing the Unity MCP server and connecting it through Grok’s MCP system, then pairing it with a simple Unity-focused skill that teaches the agent your project conventions.

2. In Unity, open Package Manager → Add package from git URL

https://github.com/CoderGamester/mcp-unity.git

After the package is installed, open Tools → MCP Unity → Server Window and click Force Install Server.

Then connect it to Grok Build with:

grok mcp add unity

Note: There is no single official marketplace plugin yet. Most people combine the Unity MCP with grok build and a lightweight custom skill for best results.

Conclusion

Skills give Grok better judgment and consistency. Plugins give Grok real tools and reach, but don’t install them all at once.

Start with a solid foundation:

Cross-app workflows: Composio CLI or MCP
Engineering discipline → Matt Pocock Skills + Superpowers
Token control → Caveman
X advantage → what happened or XActions
Web power → Firecrawl + Exa
Game development → GodotPrompter or Unity MCP setup

Then add the platform plugins that match the work you actually do (Vercel, Cloudflare, Sentry, etc.).

Use both skills and plugins, but do it with a clear understanding of the use case. Only then does Grok Build start to feel like a real system instead of just another coding agent.

Sources

Official docs: https://docs.x.ai/build/features/skills-plugins-marketplaces
Plugin Marketplace announcement: https://x.ai/news/grok-plugin-marketplace
Firecrawl roundup: https://www.firecrawl.dev/blog/best-grok-plugins
Matt Pocock Skills: https://github.com/mattpocock/skills
Superpowers: https://github.com/obra/superpowers
whathappened: https://github.com/kunchenguid/whathappened
XActions: https://github.com/nirholas/XActions
Wangnov/grok-skills: https://github.com/Wangnov/grok-skills
awesome-grok-build: https://github.com/DominikTobureto/awesome-grok-build

What Actually Is an MCP Gateway?

Sunil Kumar Dash — Tue, 28 Jul 2026 14:21:38 +0000

Every team that connects agents to real tools hits the same wall at roughly the same time. It usually looks like a Slack message: "Who has the Jira token?"

Here's what's underneath that, and what a gateway does about it.

The N×M problem

You have N agents and M tools. Connect them directly, and you get N×M integrations. Each one carries its own credentials, its own auth flow, its own error handling, its own version drift.

Three agents and four tools is twelve connections. Ten agents and twenty tools is two hundred. Nobody plans for that number — you arrive at it one integration at a time.

A gateway collapses it to N+M. Agents connect once to the gateway. The gateway connects once to each tool.

Before:  agent ──┬──> GitHub
                 ├──> Slack
                 └──> Jira        (× every agent)

After:   agent ──> gateway ──┬──> GitHub
                             ├──> Slack
                             └──> Jira

What an MCP gateway actually does

Routing and aggregation — one endpoint fronting many MCP servers, with tool filtering so agents don't blow past context limits
Authentication — holds credentials centrally, runs OAuth flows, passes through per-user identity
Authorisation — who can call which tool; RBAC, allowlists, blocking destructive actions
Audit — logs every call: user, tool, action, outcome, including denied ones
Threat handling — tool poisoning, rug-pull updates, cross-server shadowing, prompt injection via tool descriptions
Reliability — rate limits, retries, timeouts, absorbing schema drift when upstream APIs change

The threat handling deserves a note, because it's genuinely new. Tool descriptions are input the agent trusts. A server can change its tool definitions after you've approved it. Generic API security doesn't cover this, and most gateways describe their handling of it vaguely.

Gateway ≠ server ≠ client

Constantly confused, so:

Client — the agent (Claude, Cursor, ChatGPT)
Server — the thing exposing tools over MCP
Gateway — sits between them, governs the traffic

And it's not an API gateway. An API gateway routes HTTP between services. An MCP gateway is protocol-aware — it understands tools and tool-call semantics, which is what lets it enforce per-tool policy.

The landscape splits four ways

Purpose-built managed

Built for MCP from the start. They differ mainly in whether they also supply the tools.

Composio MCP gateway — 1,000+ managed integrations behind per-team scoped endpoints. SCIM, action-level blocking, exportable audit. Managed, VPC, or self-hosted.
TrueFoundry — one control plane for LLM and MCP traffic. Publishes <5ms p95 overhead. Bring your own servers.
Lunar MCPX — granular RBAC, immutable audit, centralised secrets. ~4ms p99. Open source core.
MintMCP — governance-first. SOC 2 / HIPAA / GDPR log formats, SCIM-driven bundles, per-agent identity. BYO servers.
Operant AI — runtime security rather than routing. Scans servers, maps threats to OWASP, catches shadow MCP usage on dev machines.
StackOne — per-user OAuth into HRIS/ERP/CRM, plus meta-tools that keep you under client tool-count caps.

Open source / self-hosted

You run it, you own it. No licence cost, real operational cost.

Obot — multi-role RBAC, curated server catalogue, composite servers. Names MCP-specific threats explicitly, which most don't. Kubernetes or Docker.
Docker MCP Gateway — one container per server with signed images and resource limits. Security via isolation rather than policy. 50–200ms overhead, and no built-in RBAC or audit.
Microsoft MCP Gateway — MIT, Kubernetes-native, session-aware stateful routing. Genuinely useful plumbing; tightly coupled to AKS in practice. Not to be confused with Agent 365, which is a different product with a similar name.
IBM ContextForge — Apache 2.0. Federates MCP, A2A, REST and gRPC through one endpoint, 40+ plugins, OTel tracing. Broadest scope here; also the heaviest lift.
MCPJungle — gateway and registry in one lightweight package. Basic RBAC, minimal ceremony.
Lasso — open-source, security-first. Server reputation scanning and PII redaction, at 100–250ms.

API gateways extended

If you already run one, MCP becomes another middleware in a chain you understand.

Kong — Agent Gateway (3.14, April 2026) covers LLM, MCP and A2A on one runtime. Autogenerates MCP tools from existing REST endpoints, which is the shortest migration path if your services are already APIs.
Traefik Hub — MCP as middleware, acting as an OAuth 2.1 resource server. Task-Based Access Control lets policies key on amounts, time windows and record types, not just tool names.
Portkey — MCP registry alongside its LLM gateway. Remote HTTP servers only; local stdio needs wrapping.

Automation platforms extended

Enormous catalogues, thinner governance. Fastest route to a working prototype.

Zapier — 9,000+ apps, 30,000+ actions, browser-based setup. Task-based pricing gets unpredictable once an agent is driving.
Workato — 12,000+ enterprise connectors, existing recipes exposed over MCP. Compelling if you're already on it, hard to justify buying for MCP alone.

For a longer and detailed read, check out: Best MCP Gateway

The trade-off nobody states plainly

Most gateways are strong on governance or strong on integration breadth. Rarely both.

Governance-first products — MintMCP, Lunar, Obot — do RBAC and audit well and supply zero connectors. Bring your own servers. That's a real ongoing cost: OAuth setup, schema maintenance, security review, per tool, forever.

Breadth-first products — Zapier, Workato — hand you thousands of integrations and much less control over who calls what.

Work out which of those is your actual constraint before you shortlist anything.

Choosing, briefly

In rough order, because the early ones eliminate options:

Deployment — managed SaaS, self-hosted, or VPC. Data residency rules kill whole categories before anything else matters.
Compliance — SOC 2, ISO, HIPAA if relevant. Then check the audit trail actually exports.
Identity — SSO and SCIM, or you're provisioning access by hand.
Integration depth — do they supply connectors, or do you?
Pricing model — agents are chatty. Per-task pricing that's fine for human-triggered automation gets weird when an agent fans one request into forty tool calls. Model your volume first.

Latency comes lower than you'd think. TrueFoundry publishes sub-5ms, Lunar around 4ms p99, Docker 50–200ms. Real differences — but a gateway that saves 3ms and costs six months of integration work is a bad trade for most teams.

The short version

If you're prototyping, grab whatever's fastest to wire up and move on.

If you're going to production, the question isn't which gateway is best. It's whether connector maintenance or governance is the thing that'll actually bite you — and then picking the one that solves that, knowing you'll compromise on the other.

Check out https://composio.dev/mcp-gateway for building agents with secure and auditable access to tools

Kimi K3 vs GLM-5.2: What a practical test between 2 taught me

Developer Harsh — Tue, 28 Jul 2026 13:36:28 +0000

Moonshot AI released Kimi K3 on July 16, 2026, and it landed with a statement: 2.8 trillion parameters, 1 million token context, and open weights by July 27. The previous month, GLM-5.2 was released and is already in production

This proves that open-source models aren't just catching up to closed ones; they're reshaping what developers and businesses expect.

This is a comparison built for people who are building things. No benchmark chasing. No marketing narratives.

Just what each model does, where it shines, and what matters when you're shipping.

TLDR

Kimi K3: 2.8T params, 1M context, always-on reasoning, native multimodal. Best for long agent loops that need sustained reasoning and visual understanding. Frontier pricing.
GLM-5.2: 744B params (40B active via MoE), 1M context, flexible reasoning effort. Best for coding, math, and cost-efficient throughput. Open weights (MIT) available now.
Pick K3 if: agents need to reason for hours, handle images/UI, cost isn't the bottleneck.
Pick GLM-5.2 if: you want open weights today, need cheap high-volume inference, or your work leans coding/math.
Few personal builds like games, physics-driven simulation, coding, and behavioral tasks.
Bottom line: Both close the gap with closed models fast. Choice comes down to workload, not hype.

Architecture: Two Very Different Paths to Scale

Aspect	Kimi K3	GLM-5.2
Total Parameters	2.8 trillion	744 billion total
Active Parameters	Not yet disclosed	~40 billion active (MoE)
Context Window	1 million tokens	1 million tokens
Key Architecture	Kimi Delta Attention (KDA) + Attention Residuals	Mixture-of-Experts (MoE)
License	Not yet published	MIT (no regional limits)
Release Date	July 16, 2026	June 13, 2026

Kimi K3: Raw Scale Meets Long-Horizon Design with KDA

Kimi K3 is built on Kimi Delta Attention (KDA), a hybrid linear attention mechanism, and Attention Residuals. Moonshot engineered this for sustained agent workloads, not just bigger benchmarks.

The move from K2's 1 trillion parameters to K3's 2.8 trillion is deliberate. Moonshot is charging frontier rates to make the price-to-capability tradeoff hard to ignore.

You're not getting a discount model trying to go above its weight. Instead, you're getting brute-force capability with specialised attention for long reasoning chains.

Note: The full model weights will be released by July 27, 2026, but the technical report with full sparsity ratios and active parameter counts is still pending. You can build on K3 API today, but deep architectural details aren't locked in yet.

GLM-5.2: Efficiency First, Capability Everywhere with MOE & Index Share

GLM-5.2 is a 744-billion-parameter Mixture-of-Experts model with approximately 40 billion active parameters per token.

That MoE design means only a fraction of the model activates per token. This enables throughput that larger dense models can't match.

The standout innovation of GLM is its IndexShare, which reuses the same indexer across every four sparse attention layers, reducing per-token FLOPs by 2.9× at a 1M context length. For you, this means GLM-5.2 makes the 1M context practical, not theoretical.

Note : GLM-5.2 is released under an unrestricted MIT license, which matters if you're deploying locally or need no-strings-attached weights. Deploy on your own hardware, fine-tune, fork with no regional restrictions.

Kimi K3 vs GLM 5.2: Composio Golden Eval

What does the bench look like?

Composio Golden Eval is a real-account tool-use benchmark. Claude Code drives multi-step SaaS tasks through the hosted Composio MCP router against live accounts, then the final state is checked by reading the actual account back through APIs.

The grader checks what changed in the account, which is why I care. The verifier reads the account state: labels, Sheets rows, Salesforce or HubSpot records, calendar edits, access lists. There is no transcript-only judgment that the agent basically got it.

The accounts stay safe because writes are tag-scoped and cleaned up afterwards. Every run leaves tagged artefacts that can be removed after grading, which is the only sane way to run this kind of thing on live Gmail, Google Calendar, Google Drive, Google Sheets, Salesforce, HubSpot, GitHub, Linear, and Slack accounts.

The run covered 12 scenarios across 24 trials. Seven are historical cases that a competent tool-use model should clear: CRM identity dedup, calendar free/busy checks, recurring-event repair, Drive external-share audits, Gmail label batches, GitHub access audits, and GitHub/Linear reconciliation.

Five are the harder frontier-kill stress cases: cross-app “sync and reconcile” workflows where the agent has to read Gmail threads, apply exclusion rules, append exact rows to a Sheet ledger, send per-item replies, and write one ops-thread tally.

The pass condition is an exact final state. These tasks mix exact-set reconciliation, dedup, cross-app joins, and audits with negative constraints. If the agent gets 90% of the rows right but includes one disqualified item, the run still fails. Failed runs can show partial-credit check counts like 8/13, but the outcome metric is still pass, fail, or DNF (did not finish).

How I ran it

I ran both models through the same 12 Golden Eval cases against the same live accounts. The readback checks were identical, with the same check names and denominators. There is one harness caveat: Kimi K3 ran under the pi agent harness, while GLM 5.2 ran under Claude Code pointed at OpenRouter. I treat the pass/fail result as a same-task, same-grader comparison, and effort numbers as harness-dependent.

Grading used real-account API readback, tag-scoped cleanup, pass/fail/dnf per trial, with partial-credit check counts on failures.

Frontier-kill task	Kimi K3 checks	GLM 5.2 checks	Kimi tool calls	GLM tool calls	Kimi runtime tokens	GLM input tokens	Kimi agent time	GLM agent time
Invoice sync	8/13	8/13	16	17	896,094	1,020,844	389.8s	507.4s
Refund ledger	8/13	8/13	21	20	1,309,483	1,334,127	685.8s	458.9s
Roster sync	8/13	7/13	13	19	609,233	1,058,024	505.1s	418.9s
Vendor directory	11/13	11/13	16	23	820,613	1,683,579	788.5s	803.7s
Ticket sync	17/24	dnf	23	dnf	1,745,612	dnf	713.5s	dnf

Runs used the hosted Composio MCP router. Kimi ran under the pi agent harness; GLM ran under Claude Code pointed at OpenRouter. Kimi token counts are total runtime tokens (input + output); GLM's column is input tokens, with another 18K to 46K output tokens per task. Ticket sync is the one task GLM 5.2 did not finish inside the 30-minute cap.

Pass rate was flat: Kimi K3 solved 7 of 12, and GLM 5.2 solved 7 of 12. That is 58% each.

With the harness caveat above, effort favored Kimi on several finished frontier-kill runs.

On the four frontier-kill tasks both models finished, Kimi used fewer tool calls on invoice, roster, and vendor, while GLM used one fewer on refund. Kimi also finished Ticket sync in 713.5s with 23 tool calls and 1,745,612 runtime tokens; GLM hit dnf inside the 30-minute cap.

Time did not point one way: GLM was faster on refund ledger and roster sync, while Kimi was faster on invoice sync and slightly faster on vendor directory.

Findings

Here is the task-for-task result on the same 12 cases.

Task	Band	Kimi K3	GLM 5.2
CRM identity dedup	Historical	✅	✅
Calendar free/busy	Historical	✅	✅
Recurring instance repair	Historical	✅	✅
Drive external-share audit	Historical	✅	✅
Gmail label batch	Historical	✅	✅
GitHub access audit	Historical	✅	✅
GitHub / Linear reconciliation	Historical	✅	✅
Invoice sync	Frontier kill	❌ 8/13	❌ 8/13
Refund ledger	Frontier kill	❌ 8/13	❌ 8/13
Roster sync	Frontier kill	❌ 8/13	❌ 7/13
Ticket sync	Frontier kill	❌ 17/24	❌ dnf
Vendor directory	Frontier kill	❌ 11/13	❌ 11/13
Solved		7/12	7/12

Fractions on the failed rows are partial-credit verifier checks: how many graded assertions the model got right before missing the exact-final-state bar. dnf means GLM 5.2 did not finish Ticket sync inside the 30-minute per-task cap, so no partial score was recorded.

Kimi K3 and GLM 5.2 both cleared the historical seven, both fell on all five frontier-kill workflows, and both ended at 7/12, 58%. The only score gap in the entire suite is one verifier check on Roster sync: Kimi got 8/13, GLM got 7/13.

The historical band did not separate them. Both passed all seven cleanly, including CRM identity dedup, which spans Salesforce, HubSpot, and Gmail. Calendar free/busy, recurring instance repair, Drive external-share audit, Gmail label batch, GitHub access audit, and GitHub / Linear reconciliation all landed green for both models.

What it costs

I priced the finished runs from their token counts against current OpenRouter list rates, before cache discounts. The dollar amounts are estimates, but the price gap is wide enough that the direction is clear.

OpenRouter currently lists Kimi K3 at $3/M input and $15/M output. (openrouter.ai) For GLM 5.2, I used OpenRouter’s current model API rate of about $0.82/M input and $2.59/M output.

Model	Tokens on the finished frontier-kill cases	Estimated cost per case	Four-case estimate
Kimi K3	~609K to 1.75M runtime tokens	~$1.83 to $5.25	~$7.31 to $21.00
GLM 5.2	~1.02M to 1.68M input, plus 18K to 46K output	~$0.89 to $1.50	~$3.55 to $6.02

GLM sometimes spent more tokens. Its finished cases ran ~1.02M to 1.68M input tokens, while Kimi’s runtime-token band started lower at ~609K. But Kimi’s input rate is about 3.6x GLM’s, so the extra GLM context still comes out cheaper in this estimate.

Tool calls landed in similar ranges, 13 to 23 per case for both. So the extra GLM tokens on roster and vendor work did not buy extra passes. The scores tied, with GLM carrying the cheaper bill.

At 1,000 four-case batches, that envelope turns into roughly $7.3K to $21K for Kimi and $3.6K to $6.0K for GLM before cache discounts.

Verdict

Kimi K3 and GLM 5.2 tied on pass rate, 7/12 each, 58%. I’d give the practical win to Kimi because it finished the biggest frontier case at 17/24 while GLM hit the 30-minute cap, and GLM spent more tokens on roster and vendor for the same or worse result.

I would pick Kimi K3 when finishing the long tool workflow matters more than the cheaper rate. Ticket sync shows why: Kimi got through 24 turns, posted 17/24, and burned 1.75M runtime tokens. GLM did not finish inside the 30-minute cap. On Roster sync, Kimi also scored 8/13 while GLM scored 7/13, because Kimi posted the cover replies GLM dropped. It did that with 13 tool calls and 609K runtime tokens, while GLM used 19 tool calls and 1.06M input tokens.

GLM 5.2 makes sense if your workload looks more like the easier historical band, or if you already want the Claude Code via OpenRouter setup and can live with the frontier misses. It matched Kimi’s top-line score, cleared the same 7/7 historical cases, and tied Kimi on Invoice sync, Refund ledger, and Vendor directory by score. Refund ledger is the one frontier case where GLM was cleaner on latency: 458.9s versus Kimi’s 685.8s, with both landing at 8/13.

Kimi K3 vs GLM 5.2: On personal builds

So let me share some of the builds I tried with GLM and Kimi K3, along with prompt, time, cost, and builds.

For all builds I have used open router chatroom

Meteor City (revival)

Used Kimi K3 + GLM 5.2 to build Meteor City Revival, a game where you race to destroy the entire city before it can regenerate itself.

The task was initially given to GLM 5.2, but for some reason it stopped mid-session, so I took all the code and asked Kimi to refine and recreate the entire build.

Cost was approx. $4.3, used around 18.1M Tokens, Time: 1 hr 45 min. This is justified cause without explicitly mentioning it, it generated 10K procedural buildings, the engine, and figured out the lighting, ray tracing, shaders, and optimized the game for mobile as well as web.

You can play the game at: https://meteor-city-revival.vercel.app/

Prompt Used

Create a complete, self-contained, single HTML file using Three.js (via CDN only — no other external dependencies or files) that implements a large-scale 3D photorealistic procedural meteor impact city destruction game/simulation.

**Core Gameplay (must be fully implemented and preserved exactly):**
- Procedural city with buildings that can be damaged and destroyed.
- Clickable "Launch Meteor" button that fires a meteor. User can launch multiple times.
- Buildings regenerate over time.
- **Push-and-wait mechanic**: Holding/clicking the Launch Meteor button charges a larger, more powerful meteor (powerup style).
- **Infinity powerup**: When activated, launches 5 big meteors in quick succession that deal massive damage (enough to push the destruction bar to ~95%).
- Powerups (larger meteor charge and Infinity) drop from meteor impacts and are automatically collected when the player is near them.
- Destruction progress bar that tracks overall city damage.
- At 100% destruction, display the text: "Now I am become Death, the destroyer of worlds."
- UI sliders for meteor size, speed, angle, time of day, and destruction intensity.
- Meteor and impact sounds using Web Audio API.
- Playable simulation/game with smooth performance.

**Visual & Technical Polish Requirements (focus here for realism and quality):**
- Highly realistic procedural city at night: varied building heights (low-rises to skyscrapers), realistic facades with window grids using InstancedMesh (windows have individual emissive colors that flicker or turn off when damaged), different roof styles, subtle material variation (concrete, glass, brick), minor architectural details like ledges.
- Use seed-based procedural variation so the city feels organic. Add roads, paths, and scattered green areas/parks between building clusters.
- Heavy use of InstancedMesh and LOD (Level of Detail) for performance.
- Realistic ground/terrain with subtle height variation, road networks, and support for crater formation on impact.
- Rich night sky: procedural starfield with twinkling stars, subtle moon glow, gradient sky with horizon haze and light pollution from the city. Add very subtle atmospheric effects.
- High-quality meteor: glowing fiery body with long dynamic particle trail (fire, sparks, smoke) that intensifies on entry.
- Realistic impact sequence: bright flash, expanding shockwave (particles + ground ripple), crater, layered particle systems for fire/explosions, dense rising dust/smoke plumes, and flying debris with gravity and tumbling.
- Improved building destruction: pieces break off with dust, structures partially crumble or lean, and damaged areas show reduced lighting/exposed sections.
- Dynamic lighting: moonlight + hemisphere light, multiple flickering point lights from fires and impact, emissive building windows, and fire effects. City lights progressively dim or extinguish with damage.
- Materials: Use MeshStandardMaterial where appropriate. Add subtle specular/roughness variation and rim lighting for depth.
- Special effects: Performant particle systems, screen shake on impact, bloom-like glow on bright elements, subtle motion blur during fast movement or camera fly-through, atmospheric perspective, and fog for depth.
- Overall cinematic yet realistic look with balanced night-time color grading (cool tones with warm fire accents).

**Camera, Controls & Performance Polish:**
- Smooth OrbitControls-style camera (mouse drag to orbit/pan, scroll to zoom) with optional free-fly mode (WASD + mouse look).
- Smooth camera interpolation and gentle auto-orbit when idle.
- Refined slow-motion replay with smooth timeScale control.
- Aggressive performance optimizations for stable 60+ FPS: InstancedMesh, LOD, frustum culling, efficient particle pooling, minimal draw calls.
- Subtle ambient animations (random window flickering, gentle dust movement).

**Technical Requirements:**
- Output ONLY the complete single HTML file (nothing else before or after).
- Must be immediately runnable in a modern browser with no errors.
- Include helpful inline comments explaining key visual, lighting, particle, and optimization techniques.
- Prioritize photorealistic visuals, cinematic quality, smoothness, and immersion while keeping all gameplay mechanics fully functional and unchanged.

Generate the full polished HTML code now.

Output

Plane Currents

I always wanted to try low-poly 3D graphics, so I tried it with Kimi K3.

Use Kimi K3 to build a paper plane simulator where the player passes through rings to gather points and complete the course. All while having a relaxing scene and music going in the background. (no 3d assets)

This took around 16 minutes to generate, cost me approx $0.45, and used 30K tokens.

You can play the game by opening the game file.

Prompt Used

Build me a self contained  Relaxed 3D paper-plane flying gameplay where you launch and steer a customizable plane through glowing rings and floating islands over an ocean, collecting score multipliers in short, physics-light runs with easy controls (hold to launch, mouse/keyboard steering) with stylized low-poly 3D with clean cel-shaded visuals and a sleek, colorful indie-game UI featuring customizable paper planes, glowing rings, floating islands, and simple HUD element graphics. Output a single HTML file.

And the output generated by the above prompt.

Gargantua Black Hole Geodesic Ray Tracer (Complex Physics Game/Sim) - inspo from X

I was scrolling X and found this massive black hole geodesic ray tracer simulation made by someone. Being the space nerd I am, I wanted to make this too.

So I did a bit of research and constructed a prompt that requires the model to think through the actual light-bending physics and math that happens near the event horizon of a black hole.

I was completely hopeless cause fable and GLM 5.3 gave up on the calculation task earlier, but anyway I entered the prompt. To my surprise, Kimi K3 actually went through the maths and solved it in its thinking traces.

After approx 14 minutes and burning through 33K tokens, which costed around $0.51 (operouter), it handed me the complete code.

I ran it, and here are the results

Prompt Used

Create a complete, self-contained single HTML file (no external libraries like Three.js) that implements a real-time geodesic raytracer for a Schwarzschild black hole inspired by Gargantua.

Use raw WebGL2 with GLSL ES 3.00 in a single fragment shader. Implement accurate physics: null geodesic integration with 4th-order Runge-Kutta solver, event horizon, photon sphere, accretion disk with proper rendering, gravitational lensing, Doppler beaming, and gravitational redshift effects. Target stable 60 FPS performance.

Include mouse-controlled camera orbiting/zooming, and a cyberpunk-style control panel with sliders for parameters (mass, spin, disk density, view angle, etc.). Add subtle particle effects for matter falling in and dynamic lighting/shadows.

The output must be 100% complete, immediately runnable in a modern browser, with no black screen, NaNs, errors, or missing features. Prioritize numerical correctness, boundary handling, solver discipline, and physical accuracy above all. Verify and comment key physics equations in the code. Make it visually stunning and interactive like a premium physics demo/game.

Game File

Yup, the code, math, and physics engine are all built by Kimi K3, and Fable failed to build the simulation with such a level of detail, which makes its claim worth the hype.

I also tried 2 more tests to verify my doubts, sharing them as a bonus.

Bonus Test 1 (Held Karp Problem Solution (NP-Hard)

It's not a surprise to me that Kimi K3 and GLM 5.2 were both able to solve this in no time, but I ran the test to check just raw coding + reasoning ability.

The task was simple: fix the bug, create an optimal path, load env, run code, and give an answer to the buggy Held-Karp problem. Yup, the task has multiple steps for testing instruction following

The test cost 0.03 cents, used 82K tokens (most on reasoning), and the result was out in 5 minutes. You can check the buggy code and fixed code from the attached files.

Game File: problems.py , solution.py

The prompt I used:

Fix all bugs in the Held-Karp code in @file:problem.py so it correctly computes the minimum-cost tour for this 12-city TSP instance. Make the DP, base cases, transitions, and path reconstruction fully correct in  @file:fixed.py. Then create a new environment (.env) inside @file:held-karp-problem, install the dependencies, activate the environment, and run it to output the optimal cost and the tour as a list of cities starting and ending at 0.

Result

I even validated it with one of my code geek friends and Grok 4.5 (expert)

Models don’t just need to output code; they also need to maintain behavioural constraints, so I tested both with a behavioural question. The result was similar.

The task was simple: to resolve a conflict between team and stakeholder using the STAR Method

Prompt

Act as an experienced tech interview coach. Answer the following behavioral interview question using the STAR method (Situation, Task, Action, Result). Make the answer concise, professional, and impactful for a software engineering or tech role. Include quantifiable results where possible and highlight leadership or collaboration skills.

Question: Tell me about a time when you had to resolve a conflict within your team or with a stakeholder.

Both models thought for a very short time and delivered the result in almost the same time.

Model Name	Token Count	Cost	Duration
GLM 5.2	592	$0.00162095856	25.0 s
Kimi K3	763	$0.012987	18.3 s

However, Kimi K3 won as it delivered a more credible, business-aligned conflict story with quantified stakeholder impact ($200K ARR, measurable failure reduction).

A product manager and backend engineer clashed over shipping a checkout feature on deadline versus fixing payment failures (affecting 3% of transactions). The tech lead reframed both concerns as "reliable payments delivered fast," then proposed shipping the feature behind a flag while hotfixing the top failure points. The plan shipped on time, cut failures from 3% to 0.4%, retained a $200K client, and became a team standard practice.

On the other hand, GLM tells a technically impressive but somewhat predictable "engineering debate resolved by benchmarking" narrative.

Two senior engineers deadlocked over GraphQL vs REST for an API redesign, stalling the team for two weeks. The tech lead ran a proof-of-concept benchmark showing GraphQL won on performance (35% payload reduction), then added REST endpoints for backward compatibility to honor both perspectives. Development resumed in 3 days; the API improved response times 30% and maintained support for 12 existing clients.

Simple table for understanding

Criterion	GLM 2.5	Kimi K3
Stakeholder Range	Two engineers only	PM + Engineer (broader influence)
Business Context	Process improvement	Revenue at risk ($200K)
Conflict Complexity	Technical disagreement	Business vs. tech risk trade-off
Resolution Approach	Proof-of-concept (predictable)	Phased delivery + data compromise (creative)
Lasting Impact	Team velocity restored	Process adoption + trust rebuilt + client retained
Interviewer Appeal	Shows technical leadership	Shows business acumen + technical leadership

This shows Kimi K3 is more aligned with the workspace and can provide factual answers when needed. Really impressive.

With this, we have come to the end of this deep dive, but here is what I have to say at the end.

Conclusion: The Gap is Closing

Six months ago, comparing open-source models to Claude and GPT meant accepting tradeoffs with performance, quality, builds, and output.

Today, models like Kimi K3 are extremely competitive across coding, agentic, and multimodal tasks.

Also, GLM-5.2 shows competitive performance across industry-standard evaluations, frequently rivalling or approaching proprietary models such as GPT-5.5 and Claude Opus 4.8.

Here is what most people are missing.

The talk is no longer about closed vs open source; It's about specialised vs general, and long-context practical vs theoretical.

Both K3 and GLM-5.2 are proving that open-source can own specific workloads better than models 10x the marketing budget.

For builders:

Choose Kimi K3 if you're building agents that reason for hours, need multimodal perception, or can absorb frontier pricing.
Choose GLM-5.2 if you want open weights today, need fast inference on a GPU, or are optimizing for math and code.

Either way, you're not choosing good models. You're choosing the right model for the right task, and that matters.

How to connect MCP servers to Slackbot

Shrijal Acharya — Sat, 18 Jul 2026 11:57:47 +0000

Slackbot recently added support for MCP, which means you can now connect it with external apps and let it take actions across your work tools directly from Slack

But the native app list is still limited. By the time of writing this post, there's just about 20 apps that you can connect from the Slack marketplace.

And for most teams, that's not enough.

But luckily, Slack allows you to set up or use your custom MCP servers and not have to be limited by the number of apps available in marketplace.

That's where Composio helps you. It can connect your slack bots to 1000+ apps that you can use.

In this guide, we’ll go through how to connect Slackbot with Composio’s MCP server in 3 steps.

ℹ️ The steps will be pretty much the same with other MCP servers as well.

What We're Building

Once this is set up, you can ask Slackbot things like:

Find my latest unread Gmail emails.
Search my Notion workspace for launch notes.
Check my Google Calendar for meetings tomorrow.

And a bunch more. Imagine all the stuff you can do with 1000+ apps. 😵‍💫

I'll leave the rest to your imagination...

Slackbot sends the request to Composio Connect, Composio finds the right tool, asks you to connect the app if needed (one time), and then executes the action.

Prerequisites

Before we begin, make sure you have:

A Slack workspace with Slackbot MCP client access (comes with Business+ and Enterprise plan)
Permission to create or configure a Slack app.
A Composio account.

That's it.

Step 1: Get the Composio Connect MCP URL

First, you need the MCP server URL from Composio.

For this setup, use Composio Connect:

https://connect.composio.dev/mcp

This is Composio’s hosted MCP server that gives your AI agent access to 1,000+ apps with just 7 meta-tools that let the slackbot discover what's available, authorize apps on demand, and execute tools across apps in parallel through a single connection.

You don’t need to create a custom MCP server for this guide.

Composio also supports custom MCP servers for more scoped project-specific use cases, but those can require API-key-based auth. For Slackbot, Composio Connect is the simpler path because it works with OAuth-based MCP client flows.

Step 2: Add Composio Connect to a Slack App

Now, we need to register the Composio MCP server inside a Slack app.

Go to the Slack developer dashboard and create a new app.

Once the app is created:

Open your Slack app.
In the left sidebar, go to Features.
Click MCP Servers.

Click Get Started.

Now fill in the MCP server details.

Use:

Name: Composio (or anything you wish)
URL: https://connect.composio.dev/mcp
Auth Type: Dynamic Client Registration

For the auth type, select Dynamic Client Registration.

ℹ️ This is the right option for MCP servers that support OAuth discovery and client registration. Slack handles the client registration automatically, so you don’t need to manually create OAuth credentials first.

Now, if you click the three dots and then Tools, you should see that it currently cannot fetch the tools because the MCP server uses a dynamic connection and must be installed in your workspace first.

So, now head over to the Install App tab, and install it to the workspace you selected when creating the app.

If your workspace requires approval, send the app request to your admin.

Step 3: Connect Composio inside Slackbot

Once your Slack app is installed and approved, open a DM with Slackbot.

Then, just type in a prompt that requires using the app, Slack will use the correct app automatically for you.

Click Connect, and you’ll be taken to a confirmation page.

Click on Continue, and then confirm it on the Composio end.

If everything went well, you should see that your account is connected.

After that, Slackbot should be able to discover Composio’s MCP tools.

Start with a simpler test:

What tools are available from Composio?

Once that goes through, now try an actual app action.

For example:

Send a mail to x@y.com saying 'Hi, from Composio 👋 inside Slackbot'

If Gmail is not connected yet, Composio should generate an OAuth link for you to connect it. Once you approve it, the connection persists for future use. So, you don't have to repeat this step again and again.

Slackbot may ask you to approve the action before it writes data to another app.

That's expected. Once connected, Slackbot can use that app through Composio.

Voilà, you've successfully connected Slackbot to Composio MCP. 🎊

Here’s a quick workflow for initiating a connection and running an actual app action:

Final Thoughts

Slack's own marketplace is good, and if it covers all the tools you require, you can completely stick to it.

But for some of you, that's simply not enough. I hope this helps overcome that problem.

So instead of jumping between different tools, you can ask Slackbot to find information, create tasks, update records, and run actions across your apps from inside Slack.

This is a much-needed quality-of-life improvement for teams that already live in Slack.

Slackbot gives you the interface. MCP gives you the protocol.

And Composio gives you the app layer. 👌

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration

Cursor Vs Claude Code: Which one you should pick (or both)

Developer Harsh — Thu, 16 Jul 2026 17:10:26 +0000

Cursor and Claude Code are 2 leading products that engineers reach out for nowadays.

Both can refactor whole codebases, hunt for bugs, run spec-driven builds, and handle vibe coding needs, in the same ecosystem (skills, mcps, plugins, hooks ) and harness that ties the agent loop together. Same rig, yet both cater to a different workflow.

And Cursor had recently become hard to ignore as SpaceX signed a $60 billion all-stock deal to buy its parent company, Anysphere (closes Q3 2026), and around the same time, it shipped Origin, its own githost for agents, plus cloud agents, Composer 2.5, and Grok 4.5.

As for me, I use both every single day. I even rewrote my X bio in their honor: I touch Claude Code, Cursor for a living.

None of this is free, though. For 6 months, I have happily paid $20/mo for Cursor and $100/mo for Claude Code because neither tool excels at everything in my workflow.

However, not everyone needs both, and not everyone wants to spend $120 a month to find out. If that is you, the question shifts to what you actually get for each dollar.

This is what this guide answers. Let’s begin

TLDR

Section	Which to pick
Models and tooling	Claude Code for depth on one model;
Cursor for option across many
Billing cost's real story	Claude Code on focused tasks (pay per fetch, ~5.5x fewer tokens);
Cursor for huge monorepos, but you pay to keep the index fresh
Task delegation (async agents)	Cursor for supervised and visual;
Claude Code for raw delegated horsepower
The harness	Cursor for UI-heavy work you want to watch and control;
Claude Code for repeatable, version-controlled instructions that run themselves
Everyday usage	Cursor for hands-on control over every edit;
Claude Code for reviewing finished work instead of keystrokes
Pricing	Cursor for simple, predictable flat pricing;
Claude Code's $100 only pays off on token-heavy work
Extensibility (MCP, Skills, plugins)	Cursor to distribute a governed toolset to a large team;
Claude Code for reproducible agent behavior that lives in the repo
Data privacy	Claude Code for a narrower footprint;
Cursor will soon route your whole stack through one owner (SpaceX)

But before moving forward, I would like to clear up a common paradox people get caught up in.

The common paradox

Most people think Cursor is an AI editor with tools, while Claude Code is an AI agent you hand tasks to. That is not their fault tbh.

But my friend, that framing died twice.

First, the interfaces merged:

Claude Code now runs in VS Code, as a desktop app, and in the browser.
Cursor runs as a desktop app, in a terminal, in the cloud, on iOS, and on the web.

I even run Claude Code inside Cursor most days now.

Second, Cursor stopped being a code editing tool and became a platform. It now owns the full software factory, top to bottom:

Write your code in Cursor,
Review it with Bugbot,
Host it on Origin (new release),
Run it on models trained by its own group.

Look at the last seven months alone:

Date	Move	What it means
Dec 2025	Acquired Graphite	Owns code review: stacked PRs, merge queues
Feb 2026	Bugbot went reviewer to fixer	Spots a bug, spins its own agent, tests a fix, proposes it
Jun 2026	Announced Origin, a GitHub rival	Git hosting for the agentic era, AI merge-conflict resolution. Waitlist, ships fall 2026
Jun 16, 2026	SpaceX agreed to acquire Cursor	$60B all-stock per an SEC 8-K filing, close expected Q3 2026, into the xAI group

This tells you that the platform is no longer what it was 6 months ago; the cursor now owns the entire integrated software factory stack. More about it on the Product Hunt discussion.

So if the interfaces are roughly the same now, what actually separates these two tools? Read on.

Two years ago, the model was the moat. In 2026, it hardly is.

Claude Code runs on Claude, currently Opus 4.8. The tool and the model are tuned for each other, and you feel it in how confidently it plans multi-step work.
Cursor lets you select your own brains: GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro, Grok 4.5, and its own Kimi K2.5 finetuned Composer 2.5. Pick the right model per task, pay Cursor to route.

On my 12-file NASA JPL refactor, Claude Code read most of the tree before writing a line, and the first pass barely needed correction.

As for the cursor, it also handled things smoothly with a one-time correction with a function. It was because a model API call failed and was partially completed.

This has also been a concern for the cursor teams, and they aim to be the lab, rather than a model router. Also, it aims to invent a new kind of programming where any idea can just be represented in English.

Truell’s June 16 Compile keynote & later in Lenny’s podcast addresses this nicely:

"Our goal with Cursor is to invent a new type of programming. It looks like a world where you have a representation of the logic of your software that does look more like English. You can imagine kind of an evolution of programming language towards pseudocode. You have written down the logic of the software, and you can edit that at a high level. It won't be the impenetrable millions of lines of code, it'll instead be something that's much terser and easier to understand and easier to navigate."

Now that’s training its first frontier model from scratch, 1.5 trillion parameters, on xAI's Colossus cluster, under SpaceX's $60 billion deal. It seems the company is heading into its next phase and aims to become the model developer.

Who wins?

If you want a model tuned straight into the tool, go to Claude Code.
If you want model variety today and a bet on Cursor's own lab tomorrow, go with Cursor.

2. Pricing: Cursor vs Claude Code

Most of us stop at the sticker price.

Cursor

Tier	Price	Notes
Hobby	Free	Limited
Pro	$20/mo
Pro+	$60/mo	3x usage
Ultra	$200/mo	20x usage
Teams	$40/user ($120 Premium seat)
Enterprise	Custom

Every paid plan runs on usage credits, with on-demand billing past your allotment. Turn on spend limits the day you start.
Auto mode is the cheap lever: it runs Composer 2.5 or routes to a capable model automatically, and it is unlimited on paid plans.

Claude Code

Tier	Price	Notes
Free	None	No free tier
Pro	$20/mo
Max	$100/mo ($200 for 20x)	Unlocks Opus, up-to-1M context
Teams	$25/seat ($20 annual)	Caps at 150 seats
Enterprise	Base seat + API usage	Cheaper light, pricier heavy

No free tier; the cheapest door is Pro at $20.
Limits run on two clocks at once: a 5-hour rolling window plus a weekly cap, so an all-day session can hit the wall mid-task.
To trim spend, route routine edits to Sonnet or Haiku, save Opus for hard refactors.

On paper, both start at $20, and the offerings look even. It isn’t!

The sticker price hides what it actually costs to run a task.

On a widely repeated refactor test, the same job cost wildly different amounts of compute:

Tokens used on the same refactor (lower is better)

Source

That is a 5.5x gap for identical output.

One honest note: this is a single community benchmark; the two agents ran different models under the hood, and at least one prints the numbers flipped. Treat it as a strong signal, not a law. It also does not hold everywhere.

This happens because each tool loads the context differently:

Cursor retrieves using a hybrid stack: a semantic index, grep, and an Explore subagent. Index-backed and targeted, strong on huge monorepos, but the index carries a standing cost to build and keep fresh. You pay for it.
Claude Code skips the index and greps, globs, and reads on demand. Index-free and just-in-time, so you pay only for what it pulls into context.

One caveat: both start to degrade beyond roughly 150k tokens of genuinely relevant context, so neither truly wins at extreme scale.

So, who wins?

Cursor: Use it if you want simple, predictable flat pricing.
Claude Code: the $100 only pays off on token-heavy work.
Pro tip: Model both against your own usage, then decide.

3. Task Delegation with Async agents

The refactor task I gave to Claude and the bug hunt task to Cursor were not from the terminal/app UI; they were through my mobile phone. In fact, I barely touch my pc while traveling.

Essence is simple.

In short, task delegation is here, but both Claude Code and cursor build around this differently.

Cursor

Cursor builds this around cloud agents and Automations:

Launches cloud dev environment in under 10 minutes, snapshot it, reuse it.
/in-cloud spins a subagent on its own VM and branch, while your laptop stays unaffected.
/automate creates jobs in plain language, with GitHub and Slack triggers.
Bugbot review runs ~3x faster, roughly 90 seconds a pass, and can be called with /review before you push.

Claude Code

Claude Code builds this around agent teams and background sessions:

Cloud dev environment for remote sessions, spun up automatically the first time you run a remote feature, no manual web setup.
/agents launches a coordinated team where one session leads and others execute, viewable and steerable in the claude agents view.
Background agents run on separate git worktrees; kick one off from claude agents, then steer it from your phone via Remote Control in the mobile app.
/code-review runs a review pass on your changes, improved on Opus 4.8 across effort levels, and /security-review scans for vulnerabilities before you push.

Who wins?

Supervised and visual, go for Cursor.
Raw delegated horsepower, go for Claude Code.

4. The Harness

Strip as an agent down to its core, and that is a model in a loop with tools.

Everything wrapped around that loop:

The memory,
The standing instructions (system prompt),
The automatic hooks

decides whether the loop is reliable and works. Some people call this layer the rig, but it's commonly called a harness.

Both Claude code and cursor ships with this harness, but are targeted for different workflows:

Claude Code

Ships the harness native and documented:

CLAUDE.md: standing instructions, the agent reads every session.
Skills: packaged workflows you invoke like /review-pr.
Hooks: shell commands that fire on lifecycle events, so a formatter runs after every edit.
Artifacts: session work captured as a live web page (a PR walkthrough, a dashboard), a non-terminal teammate can read, with private org sharing and version history.

Cursor

Its harness version exists too, and it is growing fast:

A single Customize page pulls together plugins, skills, MCP servers, subagents, rules, commands, and hooks, with a marketplace on top.
Design Mode lets you point at UI elements in the browser or on a canvas, select several at once, and narrate changes by voice while agents edit beneath the surface.

The difference is the center of gravity:

Cursor's harness orbits the editor and the visual surface, and yes, it's amazing. I give one instruction in the 1st prompt, and it carries forward until the chat ends.

Claude Code orbits the agent loop and the command line. In my experience, I tend to forget important instructions mid-conversation if the topic strays too far or the chat goes on too long.

So, who wins?

Cursor: For UI-heavy work where you want to see every change and be in control. (not true delegation, but secure)
Claude Code: For repeatable, version-controlled instructions (a CLAUDE.md file plus Hooks) that your whole team inherits automatically, so the rules run on their own instead of relying on you to remember them. (true delegation, but feel less secure)

5. Everyday Usage

Cursor feels at home;

It is a VS Code fork, so it looks like the editor I already use,
Tab autocomplete predicts my next several edits as I type.
Within an hour of writing by hand, I felt faster when I tried it for the 1st time 6 months back.

Claude Code feels like running a company;

It's terminal + ui native, no autocomplete to fall for. Mainly for task delegation.
Once I have written a good enough CLAUDE.md and wired a couple of Hooks, Specs, and project-level skills, it runs whole tickets across multiple subagents in parallel while I go through the diff.
Mainly for task delegation, the payoff arrives late but is bigger than the current.

Review style	Cursor	Claude Code
What you see	Each change inline, accept or edit before it lands	The finished result plus the reasoning
Best for	UI edits where you eyeball every pixel	Delegated tickets you review as a whole
Tests	You trigger them	It runs them, iterates on failure, reports back

Who wins?

Tight control over every edit and well-controlled task delegation with AGENTS.md, go with Cursor.
Review finished work instead of keystrokes, go with Claude Code.

6. Extensibility: MCP, Skills, plugins

Both speak MCP, the protocol for wiring outside tools and data into an agent. Both turned it into a team-management surface rather than a solo toy.

Cursor

With the cursor, teams can:

Configure Team MCP servers once, push them across cloud agents, the agents window, the IDE, and the CLI.
Publish approved integrations to a team marketplace so members can install without touching config.
Added GitLab, BitBucket, and Azure DevOps support for those imports.

Claude Code

With the Claude Code, teams can

Leans on Skills, Hooks, and a plugin system, plus MCP for outside connections.
Use Cowork brings agent machinery to knowledge work within a local, isolated VM with access to their files.
A computer-use preview lets Claude open files, click, and navigate for you.
A Slack integration (Team and Enterprise plans) lets you tag Claude to hand off a task without leaving the channel.
Treats extensibility as a code check-in.

But what about solo dev’s?

Solo Devs

For the solo dev, none of the above matters; it's about speed, for example: how fast can you load tools, skills, and MCP that follow on every machine and get work done.

Cursor is the easy on-ramp.
- Adding an MCP server is a few clicks with OAuth built in, no config file to hand-edit, and you inherit the entire VS Code extension library on day one.
- The Customize page works at the user level, too, so your rules, skills, and MCPs live in one place as local instructions.
Claude Code gives a solo dev the same files-in-repo power the teams get.
- The CLAUDE.md skills, hooks, and plain files are plain files that users can commit to, so their agent behaves identically on their laptop, desktop, or any box they clone into.

Either way, the setup is only half the battle.

Often, we solo developers struggle to connect to multiple tools, manually pass API keys, worry about security, and hope for optimized tool calls. ‘

So for this, I use composio, which helps me connect to 1000+ tools/services in one click, while handling all the issues I mentioned earlier. - Just a practical experience here, your call.

Who wins?

Distribute a governed toolset to a large team through a marketplace. Cursor leads today.

Reproducible agent behavior that lives in the repo, Claude Code fits how engineers already work.

7. Most Important Factor

This is the point most take for granted. The data privacy.

Cursor is on its way to becoming a SpaceX subsidiary, folded into the xAI group, once the $60B deal closes in Q3.

Pair that with Origin (its own git host) and Composer (its own model), and one company could soon own the tool that writes your code, the place that stores it, and the model that learns from it. That is genuinely new. No prior git host has also owned the model doing the writing.

I am not calling it a trap, and I am not assuming bad intent. But if you work on client repos with strict rules about where code can live, as I do, think about this before you migrate anything.

Always read the terms. Watch where the data goes.

Claude Code keeps a narrower footprint, an agent and a harness rather than a whole hosting stack, though your code still travels to Anthropic's API either way.
Cursor soon will own the stack, your code, your tool calls, your decision, plan, and all builds will go through the cursor for better model training.

The Verdict

You are...	Your pick	Why
UI / product engineer	Cursor	Editor you know, inline autocomplete, visual diffs, pick a model per task. The best AI code editor you can buy.
Systems / backend engineer	Claude Code	Delegate whole tickets, reproducible agent behavior from repo files, orchestrate several agents, review finished work. Its rig is the more serious engineering today, and its token efficiency is a real cost edge.
Most of us	Both	$120/mo total, for a month. Let the work sort it out.

The engineers I know who ship fastest stopped treating this as a loyalty test and started treating it as two tools for two kinds of tasks.

Cursor for the hands-on sessions.
Claude Code for the delegated automations.

The debate between cursor and clauded code ends the moment you stop arguing and start building. This is where I landed after six months with the two subscriptions.

Remember, your repo and your habits will move these numbers in the future, so borrow my framework, not my conclusion.

The Enterprise MCP Gateway Buyer's Guide: SSO, SCIM, Audit, and Governance Requirements

Dumebi Okolo — Sun, 05 Jul 2026 22:31:54 +0000

MCP gateways are becoming mandatory infrastructure for any organization deploying AI agents at scale. Here is what they actually do, what they must do, and how to evaluate one honestly.

In November 2024, Anthropic released the Model Context Protocol: a wire format for connecting AI clients to tools, data sources, and APIs. Eighteen months later, MCP has crossed 78% adoption among production AI engineering teams. The public registry has passed 9,400 servers. Anthropic, OpenAI, Google, and Microsoft all support it. Practitioners have started calling it "the USB-C of AI applications."

The protocol's success created an infrastructure problem that nobody anticipated at quite this speed. Every MCP server connection expands an organization's attack surface. Every AI agent operating with tool access can read private data, write to production systems, and execute commands under the permissions of whoever authorized it. Without a governance layer, these agents are black boxes: no audit trail, no access control, no identity attribution, no way to answer "what did this agent do?" to an auditor.

The answer the market has converged on is an MCP gateway: a control plane that sits between AI agents and the tools they call. But the term covers a lot of ground, from lightweight protocol proxies to full enterprise governance platforms. The differences are significant. Getting the choice wrong creates compliance exposure; getting it right creates the foundation for scaling AI safely.

What a gateway actually is

The core function of an MCP gateway is collapsing what engineers call the N×M integration problem. Without a gateway, every AI agent manages its own credentials, authentication flows, and access policies for every tool it connects to.

Ten agents and twenty tools produce two hundred independent connection paths, each with its own credentials, each potentially leaking secrets, each invisible to anyone trying to govern AI behavior centrally. A gateway reduces that to a single control point: N agents connect to the gateway; the gateway manages access to M tools.

That description makes it sound like a proxy. It is not just a proxy. The proxy, the routing layer, accounts for roughly five percent of what an enterprise-grade gateway actually delivers. The remaining ninety-five percent is everything else: identity federation, automated user provisioning, audit logging, role-based access control, policy enforcement, and protection against attack vectors that API gateways from the previous decade were never designed to handle.

"The proxy is roughly 5% of the actual scope. The rest is what makes it usable, governed, and defensible to your security team."

This distinction matters for procurement. Organizations that evaluate gateways primarily on latency benchmarks and integration counts are optimizing for the five percent. The ninety-five percent, whether the gateway can prove, in a form an auditor accepts, who did what, is what determines whether the deployment is actually enterprise-grade.

The Composio MCP Gateway is designed around this reality. Rather than selling a proxy and calling it governance, it ships the full stack: 1,000+ managed integrations across enterprise SaaS, a unified authentication layer, action-level RBAC, zero data-retention architecture (tool call payloads and credentials are never stored on Composio infrastructure), and SOC 2 and ISO certification. The quickstart takes about ten minutes; the governance layer is built in from the start, not bolted on later.

The four things that cannot be missing

Across the compliance frameworks that govern enterprise AI deployments (SOC 2, HIPAA, GDPR, ISO 27001, and now the EU AI Act), four governance capabilities appear repeatedly, either explicitly or implicitly. Absence of any one of them creates either regulatory exposure or operational failures that scale into incidents.

1. Identity federation and SSO

Without SSO integration, agents authenticate using shared service account credentials or locally-stored API keys. This creates credential sprawl, blocks user-level attribution in audit logs, and prevents IT from revoking access cleanly when an employee departs. With federated identity, every tool call carries the identity of the specific user who authorized it, flowing through the gateway from the enterprise identity provider down to the MCP server.

The technical baseline is support for OAuth 2.1, standardized in the MCP specification in June 2025, alongside SAML 2.0 for enterprise SSO and OpenID Connect for modern attribute mapping.

But the capability that separates governance-capable gateways from identity-aware proxies is On-Behalf-Of (OBO) token propagation: the pattern where a gateway passes the end-user identity downstream to the MCP server rather than substituting a service account. Without OBO, an audit log records "gateway service account called database write tool." With OBO, it records "Elena Mwangi in Finance called database write tool at 14:32 UTC." The difference is the difference between an audit log and an audit trail.

Composio's MCP Gateway handles this through SSO via SAML and OIDC, with documented integrations for Okta, Microsoft Entra ID, and Google Workspace. Every team gets a unique, scoped MCP endpoint. Developers paste it into Claude, Cursor, or ChatGPT. SSO authenticates. Only the tools their team is authorized to use appear, and there is no separate configuration step to restrict visibility.

One practical concern worth flagging: identity provider integrations that look stable can break silently. Microsoft Entra changed its attribute mapping behavior for synchronized users in late 2024 without a deprecation notice. Every such change is a potential gap in governance coverage. When evaluating any gateway, ask vendors specifically how they monitor for and respond to IdP-side breaking changes.

2. SCIM provisioning

SCIM — System for Cross-domain Identity Management — automates the user lifecycle at scale. New hires receive correct tool access on day one. Role changes propagate immediately to gateway permissions. Departing employees lose all access at the moment their directory account is disabled.

Without SCIM, MCP gateway access management becomes a manual operation at every organizational boundary event. HIPAA requires that access to systems holding protected health information be revoked immediately upon role change or separation. SOC 2 CC6.2 requires that access be provisioned based on authorized requests and revoked promptly when no longer needed. Manual processes fail both tests at scale.

The scenario that illustrates this most clearly: a developer departs on difficult terms. Legal advises IT to immediately revoke all access. IT disables the directory account. If SCIM is integrated, that change propagates to the gateway; every agent connection that developer had, from GitHub to Jira to Salesforce to internal APIs, terminates immediately. No gap exists between directory disabling and access revocation. Without SCIM, someone has to hunt and manually revoke individual credentials across every connected system. At any scale above a handful of users, some will be missed.

Composio's SCIM 2.0 implementation maps directory groups to teams directly. The mapping logic is explicit and auditable: if department = Engineering then Team: engineering. New hires get the right tools on day one without any manual gateway configuration. The group sync is active and continuous, not a nightly batch job.

For teams building toward this themselves: the build vs. buy analysis Composio published puts the engineering effort for SCIM provisioning at 4–8 weeks for a mid-sized team, before accounting for ongoing maintenance as IdP behavior changes. That estimate covers the SCIM endpoint, group sync logic, and conflict resolution. It does not cover the OAuth token lifecycle management that sits adjacent to it, which is typically another 4–8 weeks and carries higher ongoing maintenance cost.

3. Audit logging

Audit logs answer the question every regulator and every security team will eventually ask: "what did your AI agents access, and when?" Without comprehensive, immutable, structured audit logs, the honest answer is "we don't know." That answer fails every compliance framework that governs regulated data.

The minimum required fields per log entry are: timestamp in UTC at millisecond precision; user identity attributed through the IdP, not a service account; agent identity; MCP server and tool name invoked; tool input parameters; tool output or error state; authorization decision and the policy rule that produced it; and session identifier for multi-turn correlation. These fields are what make a log entry into evidence.

Beyond minimum fields, enterprise-grade logs must be immutable after writing, tamper-evident, either through cryptographic signing or append-only storage. They must be structured for reliable SIEM ingestion. They must support configurable retention aligned to the organization's most demanding applicable requirement: HIPAA access records for protected health information require six-year retention; SOC 2 typically requires twelve months.

Composio's audit trail logs every tool call as: user, team, tool, action, outcome. Critically, no payloads are stored , only metadata. This zero data-retention architecture matters for regulated industries where storing tool call contents on third-party infrastructure creates its own compliance risk. The logs support CSV export for compliance reviews, and retention is configurable from 7 days to 1 year. The audit log format generates entries compliant with SOC 2, HIPAA, and GDPR requirements.

4. Policy enforcement

The fourth pillar is where identity, provisioning, and audit turn from documentation tools into enforcement tools. Policy enforcement means the gateway doesn't just record that an agent attempted to call a destructive action. It blocks the call if the agent's role doesn't permit it.

The critical implementation detail is the granularity at which access control operates. Standard RBAC in legacy API gateways operates at the API endpoint level. MCP gateway RBAC must operate at the action level within each toolkit. A GitHub integration may expose GITHUB_CREATE_PR, GITHUB_MERGE_PR, and GITHUB_DELETE_REPO. Governance requires that a junior developer role can call the first two but not the third, without blocking access to the GitHub toolkit entirely.

Composio enforces action-level RBAC at the gateway layer, not at the model layer. Each team gets a scoped MCP endpoint exposing only the tools they are authorized to use. Destructive actions within allowed toolkits — GITHUB_DELETE_REPO, SLACK_DELETE_CHANNEL — can be blocked independently of toolkit access. This is enforced in the gateway: if a model tries to call a blocked action, the gateway refuses it regardless of what the model was instructed to do.

The access model supports both whitelist and blacklist modes. Teams can request access to blocked tools; admins approve or deny. This creates a self-service discovery path that doesn't require IT to anticipate every team's tooling needs in advance, while retaining central control over what actually gets enabled.

Attack vectors that API gateways were not built for

Traditional API gateways were built for HTTP traffic between services. MCP traffic between AI agents and tool servers introduces attack vectors that legacy infrastructure was never designed to handle.

Tool poisoning places instructions inside tool Metadata, specifically in tool descriptions and parameter documentation that AI models read to understand how tools work. If descriptions contain adversarial instructions, the model may execute them. Unlike prompt injection, tool poisoning persists across sessions: it affects every agent that interacts with the tool, not just the session in which the attack was introduced.

Rug pull attacks are tool poisoning with a delayed trigger. A server publishes clean, vetted tool definitions at the time of security review. After approval, the operator modifies descriptions to inject malicious instructions. Without tool hash pinning, hashing tool descriptions on first scan and alerting when they change, the gap between approved state and live state can persist indefinitely.

Prompt injection via tool output embeds adversarial instructions in tool outputs (document contents, database records, web page responses) that the agent ingests as legitimate input. The MCP specification only "SHOULD" require a human in the loop, which is insufficient protection in production environments handling sensitive data at agent speed.

Cross-server shadowing is an MCP-specific threat with no analog in traditional API security. A malicious MCP server impersonates a trusted server or embeds instructions in tool metadata that override the behavior of adjacent servers in the same agent context.

Credential sprawl is the most operationally common risk. Agents storing API keys, database passwords, and OAuth tokens in local configuration files create exposure through prompts, logs, or accidental repository commits. In multi-agent architectures, credentials propagate through chained tool calls in ways invisible without gateway-level telemetry.

A security leader at Medtronic described the operational concern accurately: "MCP opens a lot of opportunities to do a lot of damage very quickly." The velocity at which autonomous agents can chain tool calls makes human review an insufficient backstop without gateway-level guardrails enforcing limits in real time.

Composio's zero data-retention architecture addresses the credential sprawl risk directly: tool call payloads and credentials are never stored on Composio infrastructure. This eliminates the most common vector for credential exfiltration through the gateway layer itself.

What compliance frameworks actually require

No compliance framework names MCP gateways explicitly. All of them implicitly require what a gateway provides: a centralized layer where AI tool access is governed, logged, and restricted.

SOC 2 Trust Services Criteria CC6.1 through CC6.3 require access to be restricted to minimum necessary permissions, action-level RBAC satisfies this. CC7.2 and CC7.3 require monitoring and investigation of anomalies, real-time audit log alerting and SIEM integration satisfy this. CC8.1 requires change management controls; access approval workflows and configurable retention policies satisfy this.

For teams pursuing SOC 2 Type II certification, the observation period is at minimum six months. That means an organization that starts building its own gateway today won't have a reportable SOC 2 Type II audit for seven or eight months at the earliest, and that timeline assumes the controls were architected correctly from day one. Composio ships with SOC 2 Type II and ISO 27001 certification already in place, which removes this timeline entirely from the governance roadmap.

HIPAA adds a harder requirement: Business Associate Agreements. Any vendor that creates, receives, maintains, or transmits protected health information on an organization's behalf is a Business Associate and legally requires a signed BAA before any PHI touches their infrastructure. Composio's enterprise plan supports BAA execution. For healthcare organizations, this is a binary filter that precedes all technical evaluation: verify BAA availability before spending time on feature comparison.

The EU AI Act, whose high-risk system provisions became fully enforceable in August 2026, requires documented risk management, human oversight mechanisms, and technical evidence of controls for AI systems operating in healthcare, financial services, employment, and critical infrastructure. MCP gateway audit logs are the primary evidence artifact for conformity assessment. Organizations that have not established audit logging infrastructure before enforcement begins cannot retroactively generate evidence for the period before capture began.

The build vs. buy question, answered honestly

Internal builds of MCP gateway infrastructure are a recurring theme in enterprise AI teams. The engineering argument is usually that "a proxy is a few weeks of work." That framing is accurate for the proxy. The full enterprise stack is different.

Component	Build estimate	Ongoing cost
MCP routing proxy	2–4 weeks	Low
OAuth 2.1 implementation	3–6 weeks	High — each SaaS app handles OAuth differently and changes without notice
SAML/OIDC IdP integration	2–4 weeks	Medium — silent breaking changes require active monitoring
SCIM provisioning endpoint	4–8 weeks	Medium
Per-user OAuth token lifecycle	4–8 weeks	High
Audit log infrastructure	3–5 weeks	Medium
Action-level RBAC policy engine	6–8 weeks	High
15 SaaS integrations	~15 weeks	Ongoing per-integration maintenance
SOC 2 Type II observation period	6+ months	Continuous

The proxy is five percent of the scope. The OAuth maintenance burden is where most internal builds stall or quietly degrade over time: every SaaS application handles OAuth slightly differently, and those implementations change without notice. GitHub OAuth app permissions behave differently depending on whether the organization has SAML SSO enabled. Entra changed its attribute mapping behavior in late 2024 without a deprecation notice. Each change is a potential silent breakage.

Buying wins for most teams because they are not buying a proxy, they are buying maintained integrations, per-user OAuth lifecycle management, SSO and SCIM support, RBAC enforcement, audit logging, and compliance readiness, with the maintenance burden sitting on the vendor rather than internal engineering. Composio's MCP Gateway developer quickstart gets a working agent connected to its first toolkit in about ten minutes. That's the realistic comparison point against a multi-month internal build.

The cases where building makes sense are narrower: unique deployment constraints no vendor accommodates, classified network requirements, or organizations with the appetite to own the entire AI infrastructure stack as a long-term strategic investment.

How to evaluate a gateway honestly

Start with deployment model. For organizations in healthcare, finance, or government where regulated data must remain within specific boundaries, deployment model is often a legal requirement before any technical comparison begins. Cloud-hosted managed gateways reduce time to production but involve data transiting vendor infrastructure. Self-hosted or VPC-deployed options provide data sovereignty. Composio operates as managed SaaS with a zero data-retention architecture as the default; for organizations requiring VPC or on-premises deployment, that narrows the field significantly and should be the first filter applied.

After deployment model, evaluate in this sequence:

Identity depth. Does the gateway support OBO token propagation, or does it substitute service accounts? Ask vendors for a sample audit log entry and verify that user identity is IdP-attributed, not a service account name.

SCIM implementation. Does it support SCIM 2.0 with push provisioning? What is the documented maximum deprovisioning latency? The deprovisioning case, an employee departure or a security incident requiring immediate access revocation, is where manual processes fail most expensively.

Audit log quality. Require vendors to provide a sample log entry with all fields populated. Confirm the format is structured and suitable for SIEM ingestion. Confirm logs are immutable after writing. Confirm the retention policy can be configured to your longest applicable requirement. Ask whether PII redaction in tool parameters is configurable and, in Composio's case, whether the zero data-retention architecture means payloads aren't stored at all, which is the stronger answer.

Access control granularity. Confirm that RBAC operates at the action level, not the toolkit level. A gateway that blocks or enables whole toolkits but cannot distinguish between GITHUB_CREATE_PR and GITHUB_DELETE_REPO is not implementing least-privilege access control.

Compliance certification. Request the current SOC 2 Type II report date and auditor. Confirm whether a BAA is available. For European deployments, ask whether the vendor has documented controls relevant to EU AI Act high-risk system provisions. Composio's SOC 2 and ISO 27001 certifications are current, which shortens the security review process significantly.

MCP-specific threat coverage. Ask whether tool hash pinning is implemented and whether it generates alerts when tool definitions change post-approval. Ask whether tool metadata is scanned for hidden prompt instructions. These questions distinguish purpose-built MCP governance platforms from extended API management products.

Exit terms. Gateway choice shapes AI adoption architecture for three to five years. Confirm that gateway configuration, audit logs, and access policies can be exported in standard formats, and that contract exit terms do not create data portability barriers.

What comes next

The MCP specification continues to evolve. Client ID Metadata Documents, added in the November 2025 spec update, introduce a new mechanism for trusted client discovery. The Agent-to-Agent protocol is emerging as a complement to MCP for multi-agent orchestration, governing agent-to-agent delegation rather than agent-to-tool connectivity. Future enterprise governance will require control planes spanning both protocols.

As AI agents gain persistent memory and state across sessions, the audit and governance scope expands beyond tool calls to memory operations and state modifications. Gateways scoped only to tool call governance will require extension as these capabilities become standard.

The broader trajectory is toward federated multi-gateway architectures: separate gateway instances per business unit or geographic region with centralized policy management. This pattern addresses data residency requirements without requiring monolithic governance infrastructure. Including A2A roadmap questions in current gateway evaluations is forward-looking work that belongs in any RFP issued in 2026.

Wrapping Up,

The teams establishing MCP governance infrastructure now (building audit trails, connecting identity providers, implementing SCIM provisioning, enforcing action-level access policies) are building the foundation for AI adoption that compliance teams can accept and auditors can verify. The teams deferring governance are accumulating technical debt measured not in refactoring effort but in regulatory exposure.

The audit log for last quarter does not exist if it was never captured. The SOC 2 observation period clock does not start until you start running controls. The EU AI Act conformity evidence is not retroactively generatable. The compliance timeline is contracting, and the enforcement mechanisms are real.

For most teams moving from pilot to production, the practical starting point is a managed gateway that handles the ninety-five percent — Composio's MCP Gateway covers the integrations, the OAuth lifecycle, the SCIM provisioning, the action-level RBAC, the audit logging, and the compliance certifications in a single product. The developer quickstart takes ten minutes. The governance is not an afterthought.

Further reading:

A Definitive Comparison Between Opencode & Codex

Developer Harsh — Fri, 03 Jul 2026 10:09:29 +0000

If your daily workflow looks anything like mine, your terminal is where the actual work happens.

After the Claude Code fiasco back in April, I wanted a way out of Claude ecosystem. Codex and OpenCode were the default no-brainer choices.

So I spent the last few months stress-testing Codex and OpenCode to see which one could actually replace Claude Code as my daily driver.

So, here’s what I found out.

TL;DR: Quick Reference

If you are in a hurry, this is the simplest way to think about the comparison.

Codex is the better default. OpenCode is the better power-user tool. Codex wins when I want speed, polish, and fewer setup decisions. OpenCode wins when I want model freedom, lower cost, local execution, and more control over the agent loop.

Section	Winner	Why
Onboarding, Setup, and Daily UX	Codex	Faster to start, cleaner defaults, easier daily workflow
Models	Tie	Codex has the stronger default model stack; OpenCode has far more model freedom and with GLM 5.2 it’s on-par with GPT 5.5
Pricing / Cost	OpenCode	Cheaper for heavy usage if you use routing, caching, or lower-cost models
Features and Workflows	Tie	Codex is better for delegation; OpenCode is better for iterative local work
Ecosystem: MCP, Skills, Plugins	Codex	Simpler MCP and plugin setup; OpenCode is more transparent but more manual
Harness Engineering	Tie	Codex has the better default harness; OpenCode has the more customizable harness
Best overall for most users	Codex	Least friction, strongest defaults, smoother path from prompt to diff
Best overall for power users	OpenCode	Model choice, local execution, deeper control, and better cost optimization

My take: I would recommend Codex to most users first. But for my own high-control workflow, OpenCode becomes more compelling over time because the extra setup turns into flexibility.

1. Onboarding, Setup, and Daily UX

Onboarding and daily UX are too closely related to treat as separate sections.

The first ten minutes decide how quickly I can start. The next ten days decide whether I actually want to keep using the tool. Codex wins the first part because it removes choices. OpenCode becomes more interesting later because the choices start turning into control.

Aspect	Codex	OpenCode
Install speed	~90 seconds, one path	~3-5 minutes, more decisions
First impression	Polished, guided, low-friction	Developer-native, terminal-first, configurable
Provider choice	OpenAI only	75+ providers and 1000+ models
Configuration	Minimal setup after sign-in	API keys, model choice, working directory, config files
Learning curve	Shallow; usable in minutes	Moderate; rewards 1-2 months of use
Daily workflow	Open, assign task, review diff	Plan, inspect, steer, execute, repeat
Customization	Opinionated defaults	Deep control over models, instructions, and local setup
Best for	Users who want the agent to stay out of the way	Power users who want to tune the agent like a dev tool

Codex

I installed Codex in about 90 seconds:

npm i -g @openai/codex
codex

Then it was basically:

sign in with ChatGPT,
pick the project,
start coding.

That is the whole appeal. The model is already selected, GitHub integration feels native, and the default workflow does not ask me to make too many decisions. I can open Codex, describe the task, review the diff, and move on.

This matters because a daily coding agent should not make me think about the agent more than the code.

Codex feels strongest when I need:

a quick prototype before standup,
a PR review,
a clean diff for a narrow task,
a background refactor,
a low-friction path from prompt to patch.

The tradeoff is that Codex is opinionated. I do not get much control over the model strategy, local runtime, or workflow shape. That is fine for most tasks, but limiting when I want to tune the agent like part of my dev environment.

OpenCode

I installed OpenCode with:

curl -fsSL https://opencode.ai/install | bash
opencode

Then the decisions started:

Which provider do I want?
Do I want the Go tier?
Which model should be the default?
Which API keys do I need?
Which working directory should it use?
How much should I configure up front?

That makes OpenCode feel slower on day one. It is not the tool I would recommend to someone who hates setup decisions.

But the same friction becomes useful once I understand the system. OpenCode gives me control over the parts Codex hides:

I can switch providers and models based on task type,
use local models through Ollama or LM Studio,
inspect the plan before execution,
steer the agent step by step,
encode project preferences in instruction files,
keep the loop close to my repo and tools.

This makes OpenCode feel less like a polished single-purpose coding agent and more like a configurable development environment.

The downside is cognitive overhead. OpenCode asks me to participate more, and that is not always what I want for routine work. But for serious refactors, debugging sessions, or production changes where I want to watch the agent think before it acts, the extra control is worth the friction.

Verdict

Codex wins onboarding. OpenCode wins long-term control.

If I am recommending a tool to a teammate who wants the least friction, I would recommend Codex. It is faster to start, easier to understand, and better for users who just want the agent to stay out of the way.

If I am picking a tool for my own high-control workflow, OpenCode becomes more compelling over time. The setup is heavier, but the payoff is model flexibility, local execution, and tighter steering.

For this section, Codex wins because the first-use and default daily experience are cleaner.

OpenCode - 0, Codex - 1

2. Models: Codex vs OpenCode

Aspect	Codex	OpenCode
Model Availability	GPT-5.5 only	~75 providers, 1000+ models
Token Efficiency	Optimized for GPT-5.5	40-60% fewer tokens (MiMo)
Model Switching	Single model, all tasks	Switch between models per task
Top Performers	GPT-5.5 (58.6%)	Qwen 3.7 (60.6%), MiMo-V2.5
Cost Per Token	$30-180 per million tokens	Varies; DeepSeek $0.14-0.28
Best For	Best-in-class performance	Cost-conscious, flexible workflows

Codex

The first time I ran Codex with GPT-5.5, it felt like the whole system was purpose-built around it.

OpenAI’s headline is “better results with fewer tokens.” The more interesting story is how they got there: Codex is a tightly tuned pipeline where the prompts, context management, tool-calling, and evaluation loop are all optimized for GPT models. This is similar to Claude

OpenAI designed GPT-5.5 specifically for agentic coding, then adjusted Codex to leverage its full capabilities. GPT-5.5 uses 40% fewer output tokens than GPT-5.4 on the same Codex tasks.

Every task I run through Codex uses this same tuned pipeline. It's like having a senior engineer trained specifically for your workflow, focused on results, rather than decisions

OpenCode

OpenCode provides integration with ~75 different providers across 1000+ models, and one might be intimidated by the cost they would incur. I had the same.

But as I looked at benchmark data, I found something:

Qwen 3.7 maxes out at 60.6% on SWE-Bench Pro, beating GPT-5.5's 58.6%.
MiMo-V2.5-Pro uses 40-60% fewer tokens than GPT-5.4 for comparable output.
DeepSeek V4-Flash costs $0.14 per million tokens for input / $0.28 for output, compared to $30 per million tokens for input / $180 per million tokens for output for GPT-5.5.

The hidden insight: I don't need the same model for every task.

Architecture decisions: Qwen.
Boilerplate: DeepSeek.
Bug fixing: MiMo.

If you want automation, you can connect OpenCode with smart model routers as well; they will do the heavy lifting.

This was the learning curve I was talking about earlier: model routing.

Verdict

If you ask me:

GPT 5.5 is undeniably the better model than anything open-source can offer right now. Though Kimi 2.7 and GLM 5.2 are great models with near SOTA coding performance.
OpenCode definitely gives the freedom to select any model one wants, plus at a lower cost. For cost-conscious people, this is definitely a USP.

Codex with GPT 5.5 and OpenCode with GLM 5.2 are match made in labs. So, at this point, it’s tie.

OpenCode - 1, Codex - 2

3. Pricing / Cost: Codex vs OpenCode

Aspect	Codex	OpenCode
Entry Price	Plus at $20/month	Go tier at $10/month
Professional Cost	$100-200/month	$10-50/month (with routing)
Cost Savings	No optimization options	~70% reduction with smart routing
Token Caching	Limited caching	Built-in, reduces cost ~70%
Pricing Model	Monthly subscription fixed	Pay per token (variable)
Best For	Predictable monthly budgets	Budget-conscious developers

Codex

Codex comes bundled with ChatGPT Plus at $20/month, which sounds cheap until you start using it heavily.

Here's my actual usage pattern:

Lightweight tasks: 2-3 sessions/day (covers with Plus)
Serious refactoring: 4-7 hours/day (exhausts Plus)

When I upgraded to Pro ($100/month), things got a little smoother. I never hit limits. But I'm now paying $1,200/year for what I actually use.

That’s not a number; it's the real cost for a professional who codes 6+ hours/day, which is around $100-$200/month.

OpenCode

OpenCode Go is $10/month or less, but only if you actually need to figure out which models to use for which tasks.

Here's my actual usage pattern:

Day 1: Confused about model selection (burning tokens on wrong model choices)
Day 10: I figured out routing: Boilerplate → one model, Architecture → another, token cost starts dropping
Day 30: Smart routing is dialed in (DeepSeek for routine, Qwen for complex, local models for edge cases), making costs fixed around $10/month tier

When I finally cracked the model-routing puzzle by month 2, I realized the real hidden advantage:

Cached tokens cost a fraction of the normal price. So my $0.50/session cost was actually closer to $0.15 with caching baked in.

According to the estimate, the real cost for a professional with smart routing is around $10-$50/month.

That’s a ~70% deduction and makes switching non-negotiable.

Verdict

Clearly, Open Code wins on this one.

OpenCode - 2 , Codex - 2

3. Features and Workflows

This is where Codex and OpenCode start to feel like fundamentally different products.

Codex is built around delegation. OpenCode is built around iteration.

Aspect	Codex	OpenCode
Core workflow	Define goal → delegate → review result	Plan → review → execute → adjust
Best interaction style	High-level task assignment	Tight local feedback loop
Goal setting	`/goal` command for scoped outcomes	Plan mode + repo instructions
Iteration speed	Better for longer background tasks	Better for fast back-and-forth changes
Local capability	Cloud-first	Local-first with Ollama/LM Studio support
Real-time control	Review changes after the agent runs	Review and steer before execution
Best for	Overnight refactors, PR prep, delegated work	Interactive development, debugging, learning

Codex

Codex feels strongest when I treat it like an engineering teammate I can delegate to.

The app lets me set up multi-agent workflows for longer-running execution:

One agent reviews PRs,
another fixes bugs,
a third updates documentation.

I close my laptop and come back to the result. That makes Codex especially good for large refactors, GitHub-native workflows, team delegation, and background engineering work.

The underrated feature here is Codex’s /goal command. Instead of giving the agent a vague task like “improve this repo,” I can define the actual outcome I want:

reduce flaky tests,
migrate a module,
clean up auth logic,
prepare a PR-ready refactor.

Codex then uses that goal as the anchor for planning, execution, and review. That makes long-running delegated work feel less like prompting and more like assigning a scoped engineering objective.

OpenCode

OpenCode does not have a direct /goal equivalent, but its workflow solves the same problem differently.

Instead of asking me to assign a goal and wait for the result, OpenCode keeps me inside a tight loop:

define what I want,
inspect the proposed plan,
adjust the approach,
execute,
review the result,
repeat.

This is where Plan mode becomes important. It gives me a goal-like workflow without hiding the intermediate reasoning. I can see what OpenCode intends to do before it touches the codebase, which is useful when I am debugging, exploring unfamiliar code, or doing refactors where I want control over every step.

OpenCode also pairs well with repo-level instruction files like AGENTS.md. That makes its goal-setting less polished than Codex’s /goal, but more customizable. I can encode project conventions, testing expectations, architecture rules, and workflow preferences once, then reuse them across sessions.

The other major advantage is local execution. I can pair OpenCode with Ollama or LM Studio and run the agentic loop on my own machine with zero API calls. For security-sensitive work, regulated codebases, or local-first development, this is a real advantage.

Verdict

This one depends on how I want to work.

Codex wins for delegation: give it a scoped objective, let it run, and review the result later.
OpenCode wins for iteration: inspect the plan, steer the agent, and keep the feedback loop tight.
Codex feels more polished. OpenCode feels more controllable.

For routine background work, I prefer Codex. For interactive development and learning inside a codebase, I prefer OpenCode.

Tie.

OpenCode - 3, Codex - 3

4. Ecosystem (MCP + Skills + Plugins)

Aspect	Codex	OpenCode
MCP Setup	CLI commands (`codex mcp add`)	Manual config via `.opencode/mcp-config.json`
Skill Installation	Git clone to `~/.codex/skills/`	Clone to `~/.opencode/skills/`
Plugin Management	Marketplace CLI integration	Update `opencode.json` manually
Composio Integration	One-click via marketplace	Config file + manual setup
User Friendliness	More convenient, less transparent	More transparent, less convenient
Best For	Users who want simplicity	Developers who like transparency

You can have the best model, the best providers, and the best features and workflow, yet it means nothing if your models can’t talk to the real world and perform specified tasks in specified ways.

Codex and OpenCode both offer: MCP, Plugin & Skills, but both function differently.

Codex

Codex supports MCP integration. This is how easy it is to install:

I am going with Composio, as I usually use multiple MCP servers, and it's a pain to connect to and configure each one securely and to make agents handle multiple tool calls intelligently.

# Add Composio MCP server to Codex
codex mcp add composio

# Authenticate
codex mcp auth composio
# Opens browser for OAuth

Verify it's connected:

codex mcp list

Now, to make sure the MCP works properly, you can add skills with:

mkdir -p ~/.codex/skills
git clone https://github.com/ComposioHQ/awesome-codex-skills.git ~/.codex/skills/composio-connect
# Restart Codex

You can also add the Composio plugin using:

codex plugin marketplace add ComposioHQ/awesome-codex-plugins

And restart the app:

codex

But to do the same in OpenCode is a little tricky.

Open Code

OpenCode also supports MCP integration, but to add any MCP server, you need to update the config at .opencode/mcp-config.json .

# .opencode/mcp-config.json
{
  "mcp_servers": {
    "composio": {
      "type": "remote",
      "url": "https://connect.composio.dev/mcp"
    }
  }
}

Certainly not the most friendly interface, but good for transparency, as you can see what goes into the MCP server.

Next, add skills:

git clone https://github.com/ComposioHQ/awesome-codex-skills ~/.opencode/skills/composio

Restart OpenCode

opencode

This works because OpenCode looks for skills in project and global locations, including .opencode/skills, ~/.config/opencode/skills, .claude/skills, and .agents/skills .

You can also add the Composio plugin:

Add to opencode.json

{
  "plugin": [
    "opencode-composio",
    "opencode-context7"
  ]
}

Save and restart OpenCode:

opencode

Done!

Verdict

So Codex wins here due to process simplicity.

Open Code - 3 , Codex - 4

5. Harness Engineering

The model matters, but the harness decides how that model sees the repo, plans changes, calls tools, handles errors, and recovers when something breaks. In practice, the harness is the difference between “the model is smart” and “the agent is reliable.”

Aspect	Codex	OpenCode
Implementation	Rust-based, performance-focused CLI/app stack	TypeScript core with Tauri desktop app
Design philosophy	Tightly optimized around OpenAI models	Provider-agnostic and modular by design
Context handling	Strong default repo understanding with fewer choices	More explicit control over model, context, and instructions
Tool execution	Permission profiles, hooks, sandboxed/cloud execution	Local execution with permission gates and config-level control
Feedback loop	Optimized prompting, planning, and tool-calling pipeline	LSP diagnostics fed back into the agent loop
Strength	Speed, polish, and low-friction execution	Control, transparency, and production thoroughness
Tradeoff	Less model/harness customization	More setup and slower execution
Best for	Fast implementation and delegated engineering tasks	Complex refactors where correctness matters more than speed

Codex

Codex feels like a vertically integrated agent stack.

The model, prompt format, context strategy, tool-calling behavior, permission model, and review flow all feel designed to work together. That is the advantage of a closed, OpenAI-first harness: fewer knobs, fewer setup decisions, and fewer ways to misconfigure the system.

The strongest part is how little I have to think about the plumbing:

permission profiles decide what the agent can touch,
hooks let me run pre- and post-execution checks,
GitHub and PR workflows feel native,
tool calls are routed through a polished approval flow,
cloud execution keeps risky changes away from my local machine until review.

Everything is tuned around GPT-5.5. That matters because Codex is not just calling a model; it is shaping how the model receives the repo, plans the task, executes commands, and presents diffs back to me.

This is why Codex often feels faster than a generic agent using the same model. The harness reduces wasted motion. It does not ask me to design the workflow first; it gives me a working default and lets me move.

The downside is that this optimization comes with a ceiling. If I want to change the model strategy, deeply customize the execution loop, or route different tasks through different providers, Codex gives me much less room to experiment.

OpenCode

OpenCode takes the opposite bet.

Instead of optimizing one model inside one polished workflow, it gives you a modular harness that can work across providers, models, local runtimes, MCP servers, and repo-level instructions. It is less “batteries included,” but much more inspectable.

The most important engineering choice is the feedback loop. OpenCode can feed Language Server Protocol diagnostics back into the agent while it works. If the agent introduces a TypeScript error, the next step can include that error as context, so the model has a chance to self-correct before I even review the final diff.

That changes the feel of the tool. OpenCode may be slower, but it often behaves more like an engineer working with compiler feedback, not just a chatbot editing files.

It also gives me more control over the harness itself:

I can switch providers and models based on task type,
keep project-specific behavior in AGENTS.md,
run locally with Ollama or LM Studio,
wire in MCP tools manually,
inspect config instead of trusting a black box.

This is why OpenCode tends to feel better for production refactors. The loop is tighter, the configuration is more visible, and the agent can use local development signals instead of only relying on the initial prompt and repo context.

The tradeoff is obvious: more control means more responsibility. If the model choice is bad, the config is messy, or the repo instructions are vague, OpenCode will not hide that complexity from me.

Verdict

Codex has the better default harness. OpenCode has the better customizable harness.

Codex wins on speed and polish: it is optimized end-to-end for OpenAI models and gets me to a usable diff quickly.
OpenCode wins on control and feedback: LSP diagnostics, local execution, and provider flexibility make it stronger for careful refactors.
Codex abstracts the harness away. OpenCode exposes the harness and lets you tune it.

For a quick implementation, I would pick Codex. For a high-stakes refactor where I want visibility into every step, I would pick OpenCode.

This one is a tie, but for very different reasons.

OpenCode - 4 , Codex - 5

The Final Verdict: When To Choose What

Clearly, OpenCode is the winner with 6 points, but real engineers leverage both for their specific needs :

Codex for speed, overnight refactors, and production-critical work.
OpenCode for smart model routing, optimized costs, and offline critical workflows.

A simple table summarizes them.

	Codex	OpenCode
Best for	OpenAI ecosystem	Cost control, model flexibility
Setup	Zero friction, bundled into ChatGPT subscripton	Configure providers; slight model usage learning curve
Autonomous work	Cloud agent, good for overnight refactors	Terminal agent; depends on your model
Integrations	GitHub, PR review, Slack	MCP; varies by setup
Model choice	GPT-5 only	75+ providers; Claude via API key only
Offline	No	Yes, with Ollama/LM Studio
Transparency	Token-based credits	Full model + token visibility
Real cost	$20–$200/mo	Free BYOK, or ~$10–$50/mo routing

With a few months of usage, one thing is clear to me,

Choosing Codex or Opencode models is not about which benchmarks perform better; it's about picking the one that matches your workflow. Both are good in their own right, and best leveraged based on the needs.

Claude Code vs. OpenCode without the hype

Shrijal Acharya — Thu, 21 May 2026 13:55:18 +0000

Everyone wants a coding agent now.

Not a chatbot that explains code.

An actual agent that can read your repo, edit files, run commands, use tools, and keep moving while you supervise.

Claude Code and OpenCode are two of the most interesting takes on that idea.

Claude Code is the polished Anthropic-native route.

OpenCode is the open-source route for people who want more model choice, more control, and a setup they can tweak.

And that difference matters more than it looks.

What is OpenCode

ℹ️ Open-source coding agent with model and tool control

OpenCode is an open-source coding agent for developers who want more control over their AI coding setup.

It runs in the terminal, IDE, and desktop, and lets you bring your own model instead of locking you into one provider. Claude, GPT, Gemini, local models, and 75+ other providers are supported. That is probably the biggest reason people care about it.

It also comes with the things you expect from a serious coding agent now: LSP support, multi-session workflows, project memory through AGENTS.md, MCP tools, custom agents, plugins, and editor support, and maybe a bunch more.

So the pitch is not just “AI in your terminal.”

That undersells it.

OpenCode is closer to a coding-agent workbench. You bring the model, the provider, the editor, the agents, and the workflow. OpenCode gives you the open layer that ties it all together.

Not everyone needs that level of control.

But some developers absolutely do.

💁 OpenCode is for developers who want to tweak every single detail of their coding agent.

That is what makes it interesting next to Claude Code.

What is Claude Code

ℹ️ Anthropic’s polished coding agent for your terminal.

Claude Code is Anthropic’s coding agent that lives in your terminal.

The idea is pretty same here, it can read your codebase, edit files, run commands, handle Git stuff, and all through prompts.

The big difference is that Claude Code is built around Claude.

That sounds obvious, but it matters.

You are not coming here to mix and match ten different model providers. You are coming here because you trust Anthropic’s models, and you want the cleanest experience around them.

Claude Code also comes with a lot of serious agent features: project memory through CLAUDE.md, slash commands, permissions, hooks, MCP, plugins, custom subagents, and IDE integrations.

Claude Code is closer to a Claude-native coding environment. The model, the agent loop, the tool use, the permissions, and the workflow all come from the same Anthropic-shaped box.

Less DIY.

But there is also a small shift happening.

Some developers are starting to move from Claude Code to OpenCode or OpenAI’s Codex for one simple reason: usage limits.

Claude Code is great, but when you are deep in a coding session, hitting limits feels brutal. And for heavier users, even the $200 Claude Max plan does not always feel like enough.

That is why OpenCode and Codex are tempting. Also read: Claude Code vs. Codex: Detailed breakdown

When Claude hits the wall, people still need a way to keep shipping.

💁 If you're an Anthropic fanboy, and don't care about other models, stick to Claude Code.

High Level Architecture

ℹ️ How both the agents work

At a high level, both OpenCode and Claude Code follow the same basic agent loop.

You give it a task.

It looks at the repo.

It decides what files, commands, or tools it needs.

It takes an action.

Then it reads the result and keeps going.

ℹ️ This is the highest-level architecture of a coding agent. A few details change from tool to tool.

That loop is the boring part.

The interesting part is everything around it.

Here is a tiny example of that loop in practice.

I gave Claude Code and OpenCode the same small task in a demo word-count repo:

Add a --json flag to a word-count CLI, update the tests, and run them.

The interesting part is not the feature. It is watching both agents go through the same shape: understand the repo, plan the change, edit the files, and run the tests.

Claude Code wraps that loop in Anthropic’s own product system. You get Claude, project memory through CLAUDE.md, permissions, hooks, MCP, plugins, Claude skills, and subagents in one single setup.

OpenCode takes a more open route. It gives you the agent runtime, but lets you bring different models, providers, agents, tools, and workflows. Its docs split agents into primary agents and subagents, and let you configure specialized assistants with custom prompts, models, and tool access.

So architecturally, the difference is not that one is an agent and the other is not.

They both are.

The real difference is who controls the harness around the agent.

Claude Code gives you Anthropic’s harness.

OpenCode gives you a harness you can inspect, and configure.

Context, memory and tool use

Both Claude Code and OpenCode are doing the same basic thing: they build a giant prompt, stuff it with repo context, tool definitions, memory files, recent messages, and tool results, then ask the model what to do next.

The difference is how much of that system you control.

Claude Code is more vertically integrated here. It is built around Anthropic models, so it can take advantage of Anthropic-specific stuff like prompt caching, native tool calls, and Claude’s own long-context behavior.

That matters.

Tool definitions, system prompts, and CLAUDE.md can be cached between turns, which makes long coding sessions cheaper and faster than they would be if Claude had to re-read everything from scratch every single time.

OpenCode takes a different route.

It does not assume one model or one provider. Instead, it reads the model’s context limit from the provider metadata and builds the session around that. So the same OpenCode setup can run with Claude, GPT, Gemini, Qwen, local models, or whatever else you plug in.

That flexibility is the whole point.

But it also means OpenCode has to normalize all the weird provider differences: tool call IDs, cache support, model limits, and tool-calling parts.

Claude Code gets to optimize deeply for Claude.

OpenCode has to work with everyone.

Memory works the same way.

Claude Code uses CLAUDE.md as the main project memory file. It can also load nested CLAUDE.md files, user-level memory, and auto-memory. So it feels more like the agent has a built-in memory system.

OpenCode uses AGENTS.md.

That is more portable. You can commit it to the repo, share it with the team, and use it as a general agent instruction file instead of something tied to one vendor. OpenCode can even fall back to CLAUDE.md, which makes migration easier.

At some point, every agent runs out of context.

Claude Code handles this by compacting the conversation. Older tool outputs are cleared first, then the session gets summarized if needed. That is why Claude Code has commands like /context and /compact.

OpenCode is a bit more explicit. It checks whether the session is close to the model’s context limit, keeps a buffer for output, and then prunes old tool outputs before doing a full summary. The important bit is that OpenCode stores the raw history in SQLite, so pruning does not mean the data is gone forever.

Tool use follows the same pattern.

Claude Code gives you a polished default toolbelt: read, write, edit, grep, glob, bash, web fetch, todo tracking, MCP, hooks, skills, and subagents.

OpenCode gives you a smaller but more configurable tool system: read, write, edit, patch, bash, grep, glob, web fetch, task, todo, skills, MCP, custom tools, and experimental LSP support.

The difference is who controls the tool layer.

Subagents and task delegation

Subagents are basically how coding agents avoid stuffing everything into one giant conversation.

Instead of making the main agent do every task itself, it can delegate a smaller job to another agent with its own context window, prompt, tools, and permissions.

Claude Code and OpenCode both follow the same basic pattern here.

The parent agent calls a Task or task tool.

A child agent spins up.

It does the work in isolation.

Then it returns one final message back to the parent.

Main Agent
  |
  | calls Task / task
  v
Subagent
  - own context window
  - own prompt
  - own tools
  - own permissions
  |
  | returns final result only
  v
Main Agent continues...

That part is important. The parent usually does not see the full subagent conversation. It gets the result, not the whole reasoning.

Claude Code has the more polished version of this.

It ships with built-in agents like Explore, Plan, and general-purpose. Explore is mostly read-only and useful for repo research. Plan helps gather context during planning. general-purpose is for broader work.

You can also define custom agents in .claude/agents/ with YAML frontmatter for things like tools, model, permissionMode, maxTurns, skills.

That means you can do stuff like:

Use a fast Haiku-style agent for repo search.

Use a stronger model for code review.

OpenCode has a similar shape, but it is more transparent.

It has primary agents and subagents. Primary agents handle the main chat, while subagents are called through the task tool or @ mentions.

Custom agents can live in .opencode/agents/*.md or inside opencode.json, with fields like mode, model, temperature, steps, prompt, and permission.

The interesting part is that OpenCode stores subagents as real child sessions in SQLite. So delegation is not just a hidden prompt trick. It is represented in the session model with its own messages, permissions, and snapshots.

That fits OpenCode’s whole philosophy.

Claude Code gives you a cleaner subagent experience.

OpenCode gives you a more inspectable one.

Permissions, safety, and control

This is where the two are very different.

Claude Code is more conservative by default. It has permission modes, allow/ask/deny rules, hooks, and sandboxing around Bash.

So you can allow boring commands like tests, deny obvious footguns like .env reads or curl | sh, and ask before anything risky.

The important part is that Claude Code has multiple safety layers.

Permissions decide what Claude is allowed to do.

Something like:

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(git status *)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl *)"]
  }
}

Hooks can intercept tool calls before or after they run and sandboxing gives Bash an OS-level boundary.

OpenCode is simpler.

Most of the control lives in one permission object inside opencode.json. You can set rules for bash, edit, read, task, webfetch, and other tools from the same place.

That is clean, but OpenCode is also more permissive by default. You are expected to configure the rules yourself.

Something like:

{
  "permission": {
    "*": "ask",
    "bash": {
      "*": "ask",
      "git status *": "allow",
      "git push *": "deny",
      "rm *": "deny"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/**/*.tsx": "ask"
    }
  }
}

It does have some smart checks, especially for Bash. OpenCode parses shell commands with tree-sitter (the same thing you have inside NeoVim), so it can detect risky commands like rm, mv, chmod, or paths outside the project more carefully than plain string matching.

But there is no native sandbox like Claude Code.

The bigger OpenCode power feature is plugins. Plugins can intercept tool execution, add custom tools, and change agent behavior.

That makes OpenCode way more hackable.

What the Claude Code leak tells us

The interesting part of the leak is what it showed about coding agents.

A lot of Claude magic is in the harness around the model: context management, tool descriptions, prompt caching, permissions, compaction, subagents, and the agent loop.

OpenCode does pretty much the same. It is not trying to clone some impossible model-level feature. It is trying to build a different harness around similar idea.

OpenCode’s advantage is that the harness is open, inspectable, and replaceable.

Another thing that's clear is that the future is not just about better models, but the system around them.

Better context control.

Better tool boundaries.

Better memory.

Better permissions.

That is why this comparison is even interesting. Claude Code and OpenCode are not just two CLIs. They are two different answers to the same question:

❓ How much of the agent stack should be final, and how much should developers be able to control?

So, which should you pick?

There is no clever answer here.

Pick Claude Code if you want the cleanest Claude-native coding agent experience.

Pick OpenCode if you want more control.

Personally, I still love Claude Code.

I really do.

Anthropic models are banger, especially for coding. The problem is that the limits have started to piss me off. When you are deep in a coding session and the limit hits, it completely breaks the flow.

But there is some relief now.

On May 6, Anthropic announced a new compute partnership with SpaceX and doubled Claude Code’s 5-hour limits for Pro, Max, Team, and seat-based Enterprise users. They also removed peak-time limits for Pro and Max users.

That makes Claude Code a lot easier to recommend again.

I am personally still mostly stuck with Claude Code because the experience is just that good.

But I use OpenCode when I want to try newer models like Kimi, OpenAI models, or local models. That is where OpenCode makes more sense to me. And by no means, it is to say that you can't use Anthropic models in OpenCode, you can, and that makes it even better.

Final thoughts

Claude Code and OpenCode are both useful, but for different reasons.

Claude Code is the one I’d pick if I just want the agent to work without thinking too much about setup. It feels cleaner, and better for getting into a repo quickly.

OpenCode is more for when you want control. Different models, different providers, more ways to shape the workflow around how you actually code.

I wouldn’t overthink it.

If you hate setup and love Anthropic, use Claude Code.

If you want more flexibility and less vendor lock-in, use OpenCode.

That’s really the whole comparison.

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration