DEV Community: Composio

DeepSeek Harness (DSH) vs Pi Agent: Everything you need to know

Shrijal Acharya — Wed, 09 Sep 2026 12:45:00 +0000

DeepSeek released its own agent harness this August.

It crossed 66k stars in about a day (yes, sir!) and went over 200k by early September. That is already pretty crazy for something that is still a developer preview.

But while researching this post, I found something much more interesting. DeepSeek Harness actually uses Pi's model layer to connect to models outside DeepSeek. Yep.

The new agent runtime from DeepSeek uses Pi under the hood for part of its model support. And Tianyi Cui, who leads the Harness project, has publicly said Pi is a favourite daily driver for many people at DeepSeek. Lol.

That makes this comparison way more fun because they agree on quite a lot. Both think the harness matters, both are open source, both let you change a lot of the runtime, and both try to avoid locking you into one model.

But they take the idea in very different directions. Pi gives you a tiny coding agent with four tools and lets you build from there. DeepSeek Harness gives you a full agent runtime where even the agent loop itself can be swapped.

This is going to be an interesting one. Stick to it!

TL;DR

Category	Pi	DeepSeek Harness	Winner
Real tool use in our eval	21/30 passed	20/30 passed	Pi
Cost per shared success	$0.031	$0.028	DeepSeek Harness
Median time per task	362.9s	252.1s	DeepSeek Harness
Avg runtime tokens in our run	924,990	88,562, with a catch	DeepSeek Harness
Simplicity	Four main tools and a tiny prompt	Much larger runtime with 53 built in tools	Pi
Deep runtime control	Powerful TypeScript extensions around a small core	Even the agent loop can be replaced	DeepSeek Harness
Model support	25+ providers and very easy switching	Broad support, partly through Pi's model layer	Pi
Local models	Ollama, vLLM, and custom providers are well supported	Possible, but needs more setup	Pi
Sandbox	None in the core	Three built in sandbox modes	DeepSeek Harness
Session inspection	Very readable session tree	Full append only trajectory and replay	DeepSeek Harness
Daily use	Very small and easy to run	Web UI and more setup	Pi
Maturity	Mature enough for normal daily work	Still a developer preview	Pi

In summary

Scorecard: Pi 6, DeepSeek Harness 6. Dead tie.

And the benchmark is basically a tie too. Pi passed 21 of 30 tasks and DeepSeek Harness passed 20. DeepSeek Harness was cheaper on the shared successful tasks and also finished tasks faster.

But there is an important catch. DeepSeek Harness ran through DeepSeek's own endpoint. Pi ran through OpenRouter. So I would trust the pass rate and cost comparison more than I would trust a clean 10x token claim.

Still, the overall result is pretty clear. Pi is the better choice if you want a coding agent you can install, understand, modify, and use every day.

What is DeepSeek Harness?

ℹ️ DeepSeek's open source agent runtime where almost every part of the agent can be replaced as a plugin.

DeepSeek Harness, or dsh, is DeepSeek's official agent harness. DeepSeek released it on August 13, 2026 alongside DeepSeek V4 Pro.

And the basic idea is simple:

Agent = Model + Harness

The model does the thinking. The harness handles everything around it. It gives the model tools, builds the prompt, runs shell commands, manages files, stores sessions, handles context, runs the loop, and decides how all these pieces connect.

That part is normal. Claude Code, Codex, Pi, OpenCode, and basically every coding agent already has some version of this.

DeepSeek did something different with how it built the runtime. It uses a plugin system called Cordis, and almost everything runs as a plugin. The model adapter is a plugin, the tools are plugins, the sandbox is a plugin, the session system uses plugins, and even the main agent loop can be replaced.

Cordis also gives plugins a proper lifecycle. You can mount them from config, reload them, and clean them up when they are removed. So this is much closer to building an agent runtime from replaceable parts than adding a few extensions to a coding CLI.

💁 DeepSeek's own docs basically say there is no special core that you need to patch.

It also ships several different modes. Standard gives you the full agent setup. Code mode, also called PTC, gives the model a generated TypeScript SDK for its tools. So instead of making lots of separate tool calls, the model can write one small program that calls those tools and handles the intermediate data itself.

Minimal gives it basically shell plus a file editor. Creator lets the agent inspect and modify parts of its own runtime. 🤯

Yes, that last one is as weird as it sounds. It is very different from most coding agents.

It also comes with 53 built in tools, MCP support, subagents, LSP, web search, scheduling, sandboxing, and a local browser UI. So despite the plugin first design, this is not a tiny framework with nothing included.

What is Pi?

ℹ️ A minimal terminal coding agent that gives the model a few tools and expects you to build whatever else you want.

You probably know Pi by now if you have read the other posts in this series. Mario Zechner built it after getting tired of how much stuff Claude Code kept adding.

Pi goes almost completely in the other direction. The model gets read, write, edit, and bash. The system prompt stays under roughly 1,000 tokens. And that is most of the product.

Need grep? Use bash. Need Git? Use bash. Need another tool? Write a TypeScript extension. Need a whole new workflow? Ask Pi to build the extension for you.

The project now lives under Earendil, has around 100k GitHub stars, and is still open source and MIT licensed.

The interesting part is that Pi is not small because nobody built more features yet. It is small because that is the actual design. Every extra tool schema and every extra instruction costs tokens on future model calls, so Pi tries to keep the default harness small.

DeepSeek Harness "kinda" agrees with some of this, but there's a whole lot to it.

1. Philosophy: Pi vs DeepSeek Harness

This is probably the most interesting part of the whole comparison because at first they look very similar. Both are open source, both are written mostly in TypeScript, both have the concept of extensions, and both want the model layer to stay flexible.

And DeepSeek Harness literally uses Pi's model layer for its broad provider support.

But they disagree on what the starting point should look like.

Pi starts tiny

Pi has a small core agent loop. That loop stays pretty simple and extensions can change almost everything around it.

The idea is that the model already knows how to code. So give it file access, shell access, editing, and enough freedom to work. Then stop adding stuff unless the user actually needs it.

DeepSeek Harness starts from replaceable parts

It splits the runtime into parts and lets you swap those parts through Cordis. Pi gives you a small core and says, build around this. DeepSeek Harness gives you a way to replace its parts too.

Even the actual loop works differently from an extension point of view. DeepSeek Harness fires events through each turn, such as turn/start, system-prompt/assemble, tools/pre-execute, and turn/end. A plugin can hook into these points, change messages, add behaviour, or stop a tool before it runs.

That is a lot deeper than adding another command or tool.

That sounds like a small difference. It is actually the whole comparison.

💁 Pi is easier to understand. DeepSeek Harness gives you deeper control (DeepSeek gives you deeper control, what a nice rhyme to the name itself 🫡).

There is another interesting part here. DeepSeek used its own Minimal mode for its public V4 coding benchmarks. Minimal mode is basically shell, a file editor, and a tiny system prompt.

So even DeepSeek's own benchmark setup gets pretty close to the same minimal idea Pi has been pushing from the start.

2. Architecture: four tools vs basically the whole runtime

Underneath, both still do the normal agent thing. You send a task, the model responds, it calls tools, the harness runs them, the results go back to the model, and this repeats until the model finishes.

The difference is everything around that loop.

Pi Agent

Pi runs as one small process. It has the model layer, the agent loop, the terminal UI, session handling, and the extension system.

Its session format is also pretty neat. Messages form a tree (/tree slash command), so you can jump back to an old point and continue in another direction without throwing away the old path. And because the core is small, you can actually open the source and follow what is happening.

It is one of Pi's best features, at least for me.

Pi extensions are also just TypeScript files. You can put them inside ~/.pi/agent/extensions/ and use them to add tools, block calls, change context, replace compaction behaviour, or add your own TUI stuff.

That is a very simple way to extend a coding agent because you do not need to understand a big plugin runtime first.

DeepSeek Harness

DeepSeek Harness is much bigger, and it does much more. It has a full plugin graph, sandboxing, subagents, MCP, scheduling, compaction, a browser UI, an append only session log, replay, and much more.

The session system is probably my favourite part. Every model visible event gets logged. So if the model saw something, there should be a record of it. You can inspect the trajectory later and see what happened, or replay and fork sessions from the stored events.

There is a technical reason for doing this too. DeepSeek Harness does not go back and rewrite old session history. It keeps appending new events instead.

That makes it easier to keep the beginning of the model context stable, which is useful for DeepSeek's prefix caching.

That is very useful if you are building agent infrastructure.

I would take Pi for understanding my own coding session. I would take DeepSeek Harness if I were building a system that runs thousands of agent sessions and I needed to inspect exactly what happened.

3. The benchmark: same model, different harness

This is the part I was most curious about. We ran 30 hard agent tool use tasks across the harnesses.

The agent has to work with real apps and real data through tools, and then our verifier checks whether it actually completed the job. Each task had a 900 second cap.

For this run, we used DeepSeek V4 Pro.

Here is what happened:

Harness	Tasks passed	Median time	Avg runtime tokens	Cost per shared success
Pi	21/30	362.9s	924,990	$0.031
DeepSeek Harness	20/30	252.1s	88,562	$0.028

Pi won by one task. That is basically a tie on quality. Pi passed 21/30 tasks, while DeepSeek Harness passed 20/30.

And that matters because DeepSeek built Harness around its own model. You might expect the first party harness to have some huge advantage. It did not. Pi actually finished one more task.

But pass rate is only one part of the story.

DeepSeek Harness also came out slightly cheaper. It cost around $0.028 per shared success, compared to $0.031 for Pi. OpenCode was very close at $0.032, while Claude Code came out much higher at $0.074.

The difference gets more interesting when you look at speed.

DeepSeek Harness had a median time of 252.1 seconds per task, while Pi took 362.9 seconds. Claude Code was the fastest at 181.8 seconds, but it also cost much more per successful task.

So DSH did not beat Pi on task success, but it was faster and slightly cheaper in this run.

Then look at the runtime token column. That number is wild.

DeepSeek Harness recorded about 88k runtime tokens per task. Pi recorded about 925k.

Again, there is a provider routing catch here, and I will get into it in a second. But DSH clearly ran DeepSeek V4 Pro very efficiently on its native route.

The task split is also interesting

Most of the tasks ended the same way for Pi and DSH. Pi and DeepSeek Harness agreed on 27 of the 30 outcomes. The entire 21 vs 20 difference came down to three tasks.

Pi passed the CRM migration archive task while DeepSeek Harness failed it. Pi also passed the handover audit while DeepSeek Harness failed that one. DeepSeek Harness got the Sheets to Airtable tracker right while Pi failed it.

Task	Pi	DeepSeek Harness
CRM migration archive	✅	❌
Handover audit	✅	❌
Sheets to Airtable tracker	❌	✅

The bigger chart is useful because it shows that this did not only happen between Pi and DSH. The same DeepSeek model changed behaviour when we moved it between Claude Code, OpenCode, Hermes, Pi, and DeepSeek Harness.

For example, Claude Code cleared every check on the renewal screen task while Pi and DSH only cleared 5 of 11. On Slack action items, Pi, DSH, Claude Code, and Hermes all passed, while OpenCode only cleared 2 of 5 checks.

So we did not see one harness destroying the others across every kind of work. The same model behaved differently depending on the harness around it.

And I think that is the important result. The harness changed efficiency a lot. It changed speed. It changed cost. And on some tasks, it changed whether the model actually finished the job.

💁 Same model. Almost the same pass rate. Very different runtime behaviour.

So did DeepSeek Harness really use 10x fewer tokens?

The raw table makes it look like Pi is eating up tokens, but that is not really the full story.

DeepSeek Harness used DeepSeek's official endpoint, while Pi used OpenRouter. That changes how caching and token usage get reported.

Pi also has a much smaller base prompt. One separate comparison measured around 4.5k uncached input for Pi against 47.6k for DSH on the first turn. Pi keeps the prefix tiny, while DSH keeps a much larger prefix stable and gets strong cache reuse from it.

💁 They are solving the same token problem in different ways.

And once you look at actual cost per success, the gap is tiny: $0.028 for DSH vs $0.031 for Pi.

So DSH was very efficient in our run, but I would not treat the 88k vs 925k token number as a clean 10x win.

4. DeepSeek Harness uses Pi

This still makes me laugh. 🥴

For DeepSeek models, DSH has its own model adapter. Makes sense. That adapter understands things like DeepSeek reasoning levels and cache usage.

But when it needs other model support, it can use an adapter built on Pi's pi-ai layer.

So DSH can connect to Anthropic, OpenAI, Gemini, Bedrock, Vertex, Azure, Codex, and other providers through the model work Pi already did.

That tells you quite a lot about Pi. It looks like a tiny terminal coding agent from the outside, but its model layer has become super useful infrastructure on its own.

DeepSeek could have written another provider abstraction. It reused Pi's.

💁 I would probably do the same thing. Why not?

Pi still wins on model flexibility

Pi has had much more time to build this part out. It works with 25 plus providers, local models, OpenRouter, Ollama, vLLM, cloud providers, and custom compatible endpoints. You can also switch models during a session.

DeepSeek Harness can work with many of the same providers, but the whole product still feels very "DeepSeek first." And that is fine.

If you mainly use V4 Pro or V4 Flash, DSH has a real advantage because its native DeepSeek adapter understands the provider directly.

If you change models often, run local models, or use different cloud providers, Pi is easier.

5. Extensibility

Pi is one of the most hackable coding agents I have used. Its extensions run in TypeScript inside the same process. They can change tools, add UI, inject context, block tool calls, store custom state, and so much more...

And because the codebase is small, Pi can often write its own extension when you ask it to. That is still very cool.

A basic Pi extension can just live in ~/.pi/agent/extensions/. You do not need to learn a separate framework before adding one tool or one hook.

But DeepSeek Harness goes further. With DSH, the loop itself can be a plugin. So can the sandbox, model handling, context management, and a lot of the runtime around them.

A Cordis plugin can join the runtime's dependency graph, expose a service, listen to agent events, and clean itself up when it gets removed. That is more work for a simple extension, but it gives you much deeper control.

The agent can even inspect its own plugin tree and, in Creator mode, experiment with runtime changes. That is more control. It is also more stuff to understand and tbh, most of it is something I don't know at all.

If you are researching agent loops, building your own agent product, testing new context systems, or replacing parts of the runtime itself, DSH gives you way more room.

💁 Pi is a lot easier to extend. DSH is the deeper thing to change.

6. Safety and Security

Pi is chill about permissions. The agent gets your user permissions and can run commands. There is no big built in approval system protecting you from every shell command.

You can add safety through extensions or run Pi inside a container or VM, but the core itself does not try to do much here.

DeepSeek Harness comes with actual sandbox modes. It can run read only, it can allow writes inside the workspace, or you can give it full access.

And this is not just a UI permission setting. On Linux, DSH can use bwrap and Landlock. On macOS, it uses Seatbelt. Windows uses a restricted token model.

The sandbox also tries to fail closed. If DSH expects a sandbox and cannot create one, it should not silently continue with full access.

That is a real DSH win.

There are two catches though.

The sandbox controls tool execution, but plugins themselves run inside the harness process. So if you install a random third party plugin, you are still trusting that code with serious access to your machine.

And DeepSeek itself says the sandbox has not been security audited yet.

So I would still be careful with unattended runs, but DSH gives you much stronger safety defaults than Pi.

7. The biggest DSH problem right now is maturity

This is where the comparison stops being close for me.

Pi has been around for more than a year. People use it every day. OpenClaw runs on it. And the core is stable enough that people build real workflows around it.

DeepSeek Harness launched in August. It is still a developer preview and warns that compatibility breaking changes will happen.

And those changes are actually happening. The project pushed several alpha versions within days, and community reports have already found plugin breaks and many more issues.

There is also one governance thing worth knowing. GitHub Issues are disabled right now, and DeepSeek is not accepting outside pull requests yet. Feedback mainly goes through Discussions and Discord.

That does not make the project bad, especially this early. But if I am deciding which open source agent I want to build on today, that matters.

This is normal for a project this new, but it changes who I would recommend it to.

I would happily use DSH to experiment with agent architecture today. I would not build an important production workflow around a runtime that is still telling me its interfaces can break.

8. Daily use

This one is pretty simple.

Pi is a pretty regular agent that opens in the terminal. You pick a model and start working. The whole thing feels small because it is small.

DeepSeek Harness starts a local web app by default. You run it and open the UI in your browser. The official command is basically one npx call, so installation itself is not hard.

But once you start changing profiles, plugins, providers, Cordis config, sandbox settings, and runtime parts, there is much more to learn.

Pi can get you to a useful coding task in a few minutes. DSH needs more setup and its docs make much more sense once you already understand agent infrastructure.

That is also why I do not really see DSH replacing Pi for normal users right now. It solves a bigger problem, and bigger does not automatically mean better. 🤷‍♂️

Which one should you pick?

Pick Pi if:

You mainly want a coding agent
You want something small enough to understand
You use many different model providers
You run local models
You care about keeping the fixed prompt tiny
You want a clean TypeScript extension system
You want something mature enough to use every day
You would rather add the few features you need than start with 50 tools

Pick DeepSeek Harness if:

You are building agent infrastructure
You want to replace the agent loop itself
You need strong session traces and replay
You want a built in sandbox
You want MCP, subagents, LSP, and more tooling out of the box
You mainly use DeepSeek models and want the native integration

And you can obviously run both. They are free and open source. They even share some code.

Conclusion

The scorecard says 6 to 6. Our benchmark says Pi 21, DeepSeek Harness 20. That is as close as it gets.

But I do not think these two are actually fighting for the same user yet.

Pi feels like a coding agent made by someone who wanted the tool to stay out of his way. DeepSeek Harness feels like something built by people who want to inspect and change every part of how an agent works. Both are right. It depends on your preference. 💁

For normal coding, I would pick Pi today. It is smaller, easier to understand, and works with basically anything. It actually passed one more task in our run.

For agent infrastructure work, DSH is way more interesting. Being able to swap the loop, sandbox, model layer, and other runtime parts without rebuilding the whole agent is genuinely useful.

And DSH is still very new. It shipped all of this in a developer preview. If DeepSeek can make the runtime stable without losing the parts that make it interesting, I think it is going to be worth watching.

For now, I just would not treat it like a daily driver yet. DeepSeek itself tells you it is a developer preview.

So yeah. If I just want to code, I am still picking Pi. ✌️

Shrijal AcharyaFollow

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

A Beginners Guide to Grok Bot: From Theory to Building Agent Swarms

Developer Harsh — Sun, 23 Aug 2026 05:08:50 +0000

Grok Bot launched on August 11, 2026, and it caught my attention for one simple reason. You can create persistent AI teammates, give them access to a cloud computer, and let them continue working after you close your laptop.

I wanted to understand how far that idea could go. A research Bot is useful, but what happens when four Bots have separate roles, share context, use the same external tools, and pass work between themselves?

So I started from the basics. I wanted to understand what Grok Bot actually does, how the system works, and what changes when you give these Bots access to real tools.

What is Grok Bot?

Grok Bot is SpaceXAI's early-beta product for persistent AI agents. It launched on August 11, 2026, after starting as an internal prototype that SpaceXAI teams used for sales, marketing, operations, and engineering work.

A Bot is a persistent, named agent. You message it from the Grok Bot app, give it a job and access to the required tools, and it can continue working on a cloud computer while your own computer is offline.

This release also has some useful history:

SpaceXAI added scheduled Automations to Grok in July,
Then added large parallel workflows to Grok Build.
Finally, Grok Bot brings several related ideas into a teammate-style interface where persistent agents can coordinate.

Grok Bot currently works on macOS, Windows, and iPhone. Initial access includes SuperGrok Heavy, Cursor Ultra, and eligible Cursor team plans, while enterprise availability is still rolling out. Linux desktop, Android, and iPad were not supported at the initial launch.

Grok Bot features

The interesting part is how these pieces work together, because Grok Bot combines persistent execution, computer use, tools, and multiple Bots inside one product.

Persistent cloud computer: Your Bots work on a cloud computer with browser access, files, and command-line tools. Work can continue after you close your laptop.
Shared workspace: All Bots on your account share the same cloud computer, files, browser sessions, and command-line credentials. Each Bot has a separate screen for parallel computer work.
Computer use: Bots can work through websites when a connector or clean API is unavailable. Some sites can still block automation or require a CAPTCHA or human confirmation.
Plugins and MCP: Grok Bot can use connectors, plugins, and MCP servers for structured tool access. xAI recommends a connector when one is available because it can give the Bot a more reliable integration path.
Multi-Bot collaboration: You can put two to six Bots into a group chat. They can message each other, pass ownership, and continue work without you manually moving information between chats.
Skills: A successful process can become a reusable skill with steps, decision rules, output requirements, and approval boundaries.
Routines: A Bot can run workflows on a schedule or, where supported, after an event.
Teach a task: Where the feature is enabled, you can perform a browser workflow once while the Bot watches. Grok Bot then creates a draft skill that you can review and test.
Approvals: You can require approval for actions such as sending messages, publishing content, deleting data, purchasing, or changing production systems. Passwords, 2FA codes, CAPTCHAs, and similar steps stay with the human through computer takeover.

That gives us the product surface. The next question is what actually happens underneath when you send one of these Bots a task.

How Grok Bot works

SpaceXAI has documented Grok Bot's public execution model, but it has not published the complete internal orchestration code.

So the diagram below is a conceptual architecture based on documented Grok Bot behaviour, arranged in layers similar to an OpenManus-style agent architecture, that I tried.

The main detail to remember is the shared computer. Your Bots can have separate roles and screens, but files, browser sessions, and command-line credentials on that cloud machine can be available to all of them.

xAI also says not to treat separate Bots as separate security boundaries.

Shared context vs individual Bot memory

One thing I didn't realise at first is that sharing one computer doesn't mean every Bot has the same memory.

Each Bot can keep its own role, stable preferences, and summaries from earlier work. Its conversation and learned context stay separate, while shared files, browser sessions, group messages, and direct handoffs can move context between Bots.

This becomes useful when you start building a swarm. In my company simulation, each agent keeps its own role and persona while shared work still moves between them.

I later saw Nate Herk use a similar approach. He separates information that should be available to the wider agent setup from context that should stay with one Bot.

For important or changing facts, xAI also recommends checking the current source rather than relying only on Bot memory.

That architecture also explains why setup is fairly short. Next, let's look at how to set up Grok Bot.

How to set up Grok Bot

Step 1: Check access

You need an eligible Grok Bot account. Current documented options include SuperGrok Heavy, Cursor Ultra, eligible team access, and some trial access.

Step 2: Install Grok Bot

Download the Grok Bot desktop app for macOS or Windows and sign in with your Cursor account.

On iPhone, you can use the Grok Bot companion app. The same Bots and conversations sync between supported signed-in devices.

Step 3: Create your first Bot

Select a suggested role or create your own.

Give it a short name, one main job, and a clear description of how it should work. xAI recommends focused Bots because a focused role gives the Bot more useful context over time.

For example:

Name: Researcher

Job: Competitive research

Description:
Research AI agent products using public sources.
Keep direct source links for every important claim.
Separate verified facts from assumptions.
Do not publish or send anything externally.

This should be your 1st prompt; it sets the persona, goals, tasks, and role. See the title changed to Name: Researcher

Step 4: Give it a real task

A useful first prompt should tell the Bot the result you want, the sources it can use, its limits, the output format, and when you want to review its work.

For example:

Find the five most important AI agent platform announcements
from the last seven days.

Use public sources only.

Return:
1. Product
2. Announcement
3. Date
4. Source
5. Why it matters

Do not publish or send anything.

That is enough for basic research. But things become less convenient when one workflow needs several external tools.

Step 5: Add Composio when your Bot requires secure access to apps you use

Grok Bot can sign into websites through its browser, and it can also use connectors and plugins. Browser access is flexible, but xAI recommends using a connector when one exists because structured integrations are more reliable.

If you only need one website, signing in directly can be fine. If your workflow moves between GitHub, Slack, Gmail, Linear, Salesforce, Notion, and other services, managing every connection separately becomes more work.

This is where I added Composio.

Composio is available as a Grok Bot plugin, and Composio currently exposes tool discovery and execution across more than 1,000 apps. Its authentication layer supports user-scoped OAuth connections and automatic token refresh for supported services.

Install the Composio plugin

Open:

Settings → Plugins → Marketplace

Search for Composio and install it.

Grok Bot's plugin settings are the place where supported connectors and packaged skills are discovered and managed. The same applies to other supported tools.

Step 6: Connect tools only when you need them

Most people ask, why do I connect to Composio when I can connect with their own provided connector? The answer is simple: safety, context, security, efficiency and usability.

You don't need to connect every app before you start.

With Composio, the agent can discover tools when a task needs them. When an app requires authentication, the connection flow can ask you to approve the account in your browser and then reuse that connection later.

For public research, there is also a useful option. Composio Search is a no-auth toolkit for web, news, location, financial, and other public search data.

This keeps the Grok Bot setup fairly simple even when a workflow needs more than one external service.

Real-world Grok Bot use cases with Composio

I was so into testing and pushing the limits that I planned to simulate an entire company.

The idea was to fetch a company's top individuals, analyse their personas and simulate decision-making within the organisation. Something many CTOs, CXOs, and CEOs often do in silos.

So if you are one, this might help.

1. Finding personas

I went to Reddit and X, looked at people's past tweets and company registration docs, and also the company website itself; based on all that, I generated a persona for each. Prompt I used:

Give me a list of all the top members at <company> and their roles as well - fetch from X, Reddit, the company Teams page and the company registration. Output (bullet point):
 
Name - job role and one-liner description

Ok, based on people's bios, tweets, Reddit posts, replies, and content-posting behaviours, create a persona for each one. I want it to closely match their online and offline presence.
 
Output: name as section title. Person: 3-5-liner short sentences.

2. Creating Swarm Agent Prompt

Next, I used the generated persona to create a prompt that generates a swarm of agents in Grok Bot. This is the prompt I used.

Note: To keep things specific and simple, I have used the composio connector keyword. This will make the agent swarm aware of the plugin

Cool, now I am giving you a prompt; you need to modify it and include the persona of core members, and while building the agents for them, the core goal is to simulate <company>. Also, use Composio as the connector for outside apps when needed; if it is not connected, prompt the user to connect it.
 
The aim here is to replicate the entire company so that I can talk to any of the people (agent with that person's persona) and then finalise the decisions/task that need to be performed (routes to the right agent personas/role - can be multiple as well). I want to simulate the entire <company> inside Grok bot.

//// Prompt to modify: 

Create an entire company inside Grok Bot with CEO, Manager, Researcher, Engineer, Marketing specialist, Worker 1, Worker 2. Give everyone their own role, duties and responsibilities.” Output: Agents interact, coordinate, and improve skills autonomously (video demo of behaviour).
 
Original: https://x.com/Debuggerdam/status/2087304735535554808 \   

///Important (Output Format)

Output the entire updated prompt, without placeholders, that I can put in Grok Bot to create the agent and do this simulation thing. Format it into multiple paragraphs, and for names, use the same role

This generates a prompt that one can put in Grok Bot.

3. Creating the Swarm

Note: The swarm creation is a heavy token usage process, so best be on the max / super grok plan and take time to optimize, remove all the unnecessary personas and workflow, as grok now went into weekly limit mode.

Now I added the generated prompt and let it execute in auto mode. In a few minutes, the entire agent swarm was ready.

This creates a swarm activated by the prompting in the current chat/ to an individual agent.

4. Test Time!

I added the task next: A New Eval Launch

“Hey team, I need help with this:

We’re launching a new public eval report next week comparing the top 5 coding agents (Claude Code, Cursor, Codex, OpenCode, and our own setup) on real multi-app workflows (GitHub + Linear + Slack + Gmail).

I want:

1. **Alice and Bob** to decide the positioning and what message we should own.
2. **Charlie** to design the exact eval criteria and failure modes we should measure.
3. **Delta** to prototype a small internal agent that can run parts of the eval using **< company>**.
4. **Echo and Bravo** to draft the narrative + the first blog post / announcement.
5. Anyone who needs external tools (GitHub, Linear, etc.) should use **< company>**. If something isn’t connected, just tell me what to connect.

Can you align on the plan, assign owners, and come back with a clear and clean output?

As the prompt went in:

The agent analysed the steps required,
Distributed them according to its role and persona.
Communicate with others while keeping its specific task running in parallel.

If it hits a roadblock:

wait for the previous task to finish, then start executing it, and
finally provide the result along with the summary.

Then the worst happens: the weekly limit is exceeded, and the agent gets stuck mid-task (same goes for Hermes and Codex). This is the drawback I mentioned at the start of this section.

However, this is how it looked mid-task.

As we explicitly mentioned composio, the agent checked the pre-blocker - Slack and Linear were not connected, so it asked to connect them with a one-click connect option while other agents were working in parallel.

I was truly amazed by what I could do with simple English instructions. The only bottleneck is the weekly limit, which hits fast for swarm agentic flow.

Bonus Tasks (Use Cases)

Note: I have not personally run or verified the tasks below end to end. Treat these as inspiration / ideas for what you can build, not as guaranteed implementations.

Here are a few more ways you could push Grok Bots beyond simple single-agent workflows:

Competitive intelligence swarm: Use four specialised bots to research AI agent platforms, collect pricing and feature data, rank competitors, and produce an executive brief.
Open-source project audit: Give one bot a public GitHub repository and have it analyse recent commits, active issues, risks, and remediation priorities.
Market trend synthesis: Research recent AI agent announcements and discussions, structure the findings into a dataset, identify market segments, and forecast emerging trends.
Multi-agent research pipeline: Have separate bots discover sources, verify claims, score evidence quality, and combine everything into a timeline and gap analysis.
Autonomous code generation: Ask a bot to research a problem, build a complete Python utility, generate tests, and validate the expected behaviour.
Fact-verification engine: Give a bot a public claim and have it gather supporting and contradicting evidence before producing a scored verdict.
Parallel scenario planning: Run optimistic, base-case, and pessimistic research agents in parallel, then use another bot to combine their findings into a decision matrix.

Grok Bot is especially useful for work involving parallel agents, handoffs, specialised roles, shared context, tool use, and multi-step coordination within a single workflow.

Keep track of what every Grok Bot is doing

Once several Bots start working in parallel, another problem appears: tracking who owns what, what is running, and where the work is blocked.

One setup I found interesting was Nate Herk's approach of making his Bots log their work to ClickUp. He uses it to see what each agent is doing, who it handed work to, and where a task is stuck.

You can use the same idea with any task tracker your Bots can access. For my company swarm, I would use it to keep the task, owner, status, and handoffs visible while the agents work in parallel.

It fits naturally with how Grok Bot already works.

Bots can coordinate in parallel, pass context through direct messages and group chats, and hand work to each other, while the tracker gives you one place to follow the workflow.

However, like everything else, this also comes with a caution.

Security and governance for Grok Bot

One thing to keep in mind before connecting Grok Bot to sensitive systems:

All Bots for one user share the same cloud computer. That means files, browser sessions, and command-line credentials on the machine can be accessible across your Bot roster. Therefore, don't use separate Bots as separate security boundaries.

For consequential actions, keep explicit approval rules in the prompt and in Grok Bot's Auto Review controls where available.

Specifically, sending, publishing, purchases, deletion, permission changes, and production changes are actions where approval boundaries are most useful.

And prefer a structured connector when it exists. Browser control gives Grok Bot broad coverage, but websites can change, reject automation, present CAPTCHAs, or require human confirmation. Even XAI warns about the same.

This becomes more important when you start adding several MCP servers. Integrating & Managing them securely and efficiently becomes a production bottleneck.

That’s why Composio's MCP Gateway sits between the agent and those servers, and gives users one place to manage access, credentials, and tool activity instead of handling each MCP connection separately.

They can also limit access by organisation, team, user, or individual action, and record the user, tool, action, and outcome for calls that pass through the gateway.

For teams & business, this means Grok Bot can keep approval around sensitive work, while the MCP Gateway adds another governance layer around which MCP actions the Bot can access in the first place.

Personally, I use it for my projects for the same reasons, and it really helps me ease my mind.

Conclusion

Grok Bot is one of the more interesting agent products I have looked at recently because several useful ideas now sit in the same interface.

You get persistent named Bots, a cloud computer, browser and terminal access, plugins and MCP, group chats, agent-to-agent handoffs, skills, routines, and human approvals. The work can also continue while your own device is closed.

The multi-Bot part is what I find most interesting. You can assign one Bot to research, another to verify, another to analyse, and another to produce the final deliverable.

Grok Bot handles its own communication, while a tool layer such as Composio can give it structured access to public search or connected apps.

There are still clear boundaries. Grok Bot is in early beta, browser automation can still hit website restrictions, and all Bots under one user share the same computer security boundary. Those details matter once you move from experiments to real company systems.

It will be interesting to see how performant the Grok bot is in those settings.

Sources

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: