DEV Community: Developer Harsh

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

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.

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.

A Definitive Comparison Between Opencode & Codex

Developer Harsh — Fri, 03 Jul 2026 10:09:29 +0000

If your daily workflow looks anything like mine, your terminal is where the actual work happens.

After the Claude Code fiasco back in April, I wanted a way out of Claude ecosystem. Codex and OpenCode were the default no-brainer choices.

So I spent the last few months stress-testing Codex and OpenCode to see which one could actually replace Claude Code as my daily driver.

So, here’s what I found out.

TL;DR: Quick Reference

If you are in a hurry, this is the simplest way to think about the comparison.

Codex is the better default. OpenCode is the better power-user tool. Codex wins when I want speed, polish, and fewer setup decisions. OpenCode wins when I want model freedom, lower cost, local execution, and more control over the agent loop.

Section	Winner	Why
Onboarding, Setup, and Daily UX	Codex	Faster to start, cleaner defaults, easier daily workflow
Models	Tie	Codex has the stronger default model stack; OpenCode has far more model freedom and with GLM 5.2 it’s on-par with GPT 5.5
Pricing / Cost	OpenCode	Cheaper for heavy usage if you use routing, caching, or lower-cost models
Features and Workflows	Tie	Codex is better for delegation; OpenCode is better for iterative local work
Ecosystem: MCP, Skills, Plugins	Codex	Simpler MCP and plugin setup; OpenCode is more transparent but more manual
Harness Engineering	Tie	Codex has the better default harness; OpenCode has the more customizable harness
Best overall for most users	Codex	Least friction, strongest defaults, smoother path from prompt to diff
Best overall for power users	OpenCode	Model choice, local execution, deeper control, and better cost optimization

My take: I would recommend Codex to most users first. But for my own high-control workflow, OpenCode becomes more compelling over time because the extra setup turns into flexibility.

1. Onboarding, Setup, and Daily UX

Onboarding and daily UX are too closely related to treat as separate sections.

The first ten minutes decide how quickly I can start. The next ten days decide whether I actually want to keep using the tool. Codex wins the first part because it removes choices. OpenCode becomes more interesting later because the choices start turning into control.

Aspect	Codex	OpenCode
Install speed	~90 seconds, one path	~3-5 minutes, more decisions
First impression	Polished, guided, low-friction	Developer-native, terminal-first, configurable
Provider choice	OpenAI only	75+ providers and 1000+ models
Configuration	Minimal setup after sign-in	API keys, model choice, working directory, config files
Learning curve	Shallow; usable in minutes	Moderate; rewards 1-2 months of use
Daily workflow	Open, assign task, review diff	Plan, inspect, steer, execute, repeat
Customization	Opinionated defaults	Deep control over models, instructions, and local setup
Best for	Users who want the agent to stay out of the way	Power users who want to tune the agent like a dev tool

Codex

I installed Codex in about 90 seconds:

npm i -g @openai/codex
codex

Then it was basically:

sign in with ChatGPT,
pick the project,
start coding.

That is the whole appeal. The model is already selected, GitHub integration feels native, and the default workflow does not ask me to make too many decisions. I can open Codex, describe the task, review the diff, and move on.

This matters because a daily coding agent should not make me think about the agent more than the code.

Codex feels strongest when I need:

a quick prototype before standup,
a PR review,
a clean diff for a narrow task,
a background refactor,
a low-friction path from prompt to patch.

The tradeoff is that Codex is opinionated. I do not get much control over the model strategy, local runtime, or workflow shape. That is fine for most tasks, but limiting when I want to tune the agent like part of my dev environment.

OpenCode

I installed OpenCode with:

curl -fsSL https://opencode.ai/install | bash
opencode

Then the decisions started:

Which provider do I want?
Do I want the Go tier?
Which model should be the default?
Which API keys do I need?
Which working directory should it use?
How much should I configure up front?

That makes OpenCode feel slower on day one. It is not the tool I would recommend to someone who hates setup decisions.

But the same friction becomes useful once I understand the system. OpenCode gives me control over the parts Codex hides:

I can switch providers and models based on task type,
use local models through Ollama or LM Studio,
inspect the plan before execution,
steer the agent step by step,
encode project preferences in instruction files,
keep the loop close to my repo and tools.

This makes OpenCode feel less like a polished single-purpose coding agent and more like a configurable development environment.

The downside is cognitive overhead. OpenCode asks me to participate more, and that is not always what I want for routine work. But for serious refactors, debugging sessions, or production changes where I want to watch the agent think before it acts, the extra control is worth the friction.

Verdict

Codex wins onboarding. OpenCode wins long-term control.

If I am recommending a tool to a teammate who wants the least friction, I would recommend Codex. It is faster to start, easier to understand, and better for users who just want the agent to stay out of the way.

If I am picking a tool for my own high-control workflow, OpenCode becomes more compelling over time. The setup is heavier, but the payoff is model flexibility, local execution, and tighter steering.

For this section, Codex wins because the first-use and default daily experience are cleaner.

OpenCode - 0, Codex - 1

2. Models: Codex vs OpenCode

Aspect	Codex	OpenCode
Model Availability	GPT-5.5 only	~75 providers, 1000+ models
Token Efficiency	Optimized for GPT-5.5	40-60% fewer tokens (MiMo)
Model Switching	Single model, all tasks	Switch between models per task
Top Performers	GPT-5.5 (58.6%)	Qwen 3.7 (60.6%), MiMo-V2.5
Cost Per Token	$30-180 per million tokens	Varies; DeepSeek $0.14-0.28
Best For	Best-in-class performance	Cost-conscious, flexible workflows

Codex

The first time I ran Codex with GPT-5.5, it felt like the whole system was purpose-built around it.

OpenAI’s headline is “better results with fewer tokens.” The more interesting story is how they got there: Codex is a tightly tuned pipeline where the prompts, context management, tool-calling, and evaluation loop are all optimized for GPT models. This is similar to Claude

OpenAI designed GPT-5.5 specifically for agentic coding, then adjusted Codex to leverage its full capabilities. GPT-5.5 uses 40% fewer output tokens than GPT-5.4 on the same Codex tasks.

Every task I run through Codex uses this same tuned pipeline. It's like having a senior engineer trained specifically for your workflow, focused on results, rather than decisions

OpenCode

OpenCode provides integration with ~75 different providers across 1000+ models, and one might be intimidated by the cost they would incur. I had the same.

But as I looked at benchmark data, I found something:

Qwen 3.7 maxes out at 60.6% on SWE-Bench Pro, beating GPT-5.5's 58.6%.
MiMo-V2.5-Pro uses 40-60% fewer tokens than GPT-5.4 for comparable output.
DeepSeek V4-Flash costs $0.14 per million tokens for input / $0.28 for output, compared to $30 per million tokens for input / $180 per million tokens for output for GPT-5.5.

The hidden insight: I don't need the same model for every task.

Architecture decisions: Qwen.
Boilerplate: DeepSeek.
Bug fixing: MiMo.

If you want automation, you can connect OpenCode with smart model routers as well; they will do the heavy lifting.

This was the learning curve I was talking about earlier: model routing.

Verdict

If you ask me:

GPT 5.5 is undeniably the better model than anything open-source can offer right now. Though Kimi 2.7 and GLM 5.2 are great models with near SOTA coding performance.
OpenCode definitely gives the freedom to select any model one wants, plus at a lower cost. For cost-conscious people, this is definitely a USP.

Codex with GPT 5.5 and OpenCode with GLM 5.2 are match made in labs. So, at this point, it’s tie.

OpenCode - 1, Codex - 2

3. Pricing / Cost: Codex vs OpenCode

Aspect	Codex	OpenCode
Entry Price	Plus at $20/month	Go tier at $10/month
Professional Cost	$100-200/month	$10-50/month (with routing)
Cost Savings	No optimization options	~70% reduction with smart routing
Token Caching	Limited caching	Built-in, reduces cost ~70%
Pricing Model	Monthly subscription fixed	Pay per token (variable)
Best For	Predictable monthly budgets	Budget-conscious developers

Codex

Codex comes bundled with ChatGPT Plus at $20/month, which sounds cheap until you start using it heavily.

Here's my actual usage pattern:

Lightweight tasks: 2-3 sessions/day (covers with Plus)
Serious refactoring: 4-7 hours/day (exhausts Plus)

When I upgraded to Pro ($100/month), things got a little smoother. I never hit limits. But I'm now paying $1,200/year for what I actually use.

That’s not a number; it's the real cost for a professional who codes 6+ hours/day, which is around $100-$200/month.

OpenCode

OpenCode Go is $10/month or less, but only if you actually need to figure out which models to use for which tasks.

Here's my actual usage pattern:

Day 1: Confused about model selection (burning tokens on wrong model choices)
Day 10: I figured out routing: Boilerplate → one model, Architecture → another, token cost starts dropping
Day 30: Smart routing is dialed in (DeepSeek for routine, Qwen for complex, local models for edge cases), making costs fixed around $10/month tier

When I finally cracked the model-routing puzzle by month 2, I realized the real hidden advantage:

Cached tokens cost a fraction of the normal price. So my $0.50/session cost was actually closer to $0.15 with caching baked in.

According to the estimate, the real cost for a professional with smart routing is around $10-$50/month.

That’s a ~70% deduction and makes switching non-negotiable.

Verdict

Clearly, Open Code wins on this one.

OpenCode - 2 , Codex - 2

3. Features and Workflows

This is where Codex and OpenCode start to feel like fundamentally different products.

Codex is built around delegation. OpenCode is built around iteration.

Aspect	Codex	OpenCode
Core workflow	Define goal → delegate → review result	Plan → review → execute → adjust
Best interaction style	High-level task assignment	Tight local feedback loop
Goal setting	`/goal` command for scoped outcomes	Plan mode + repo instructions
Iteration speed	Better for longer background tasks	Better for fast back-and-forth changes
Local capability	Cloud-first	Local-first with Ollama/LM Studio support
Real-time control	Review changes after the agent runs	Review and steer before execution
Best for	Overnight refactors, PR prep, delegated work	Interactive development, debugging, learning

Codex

Codex feels strongest when I treat it like an engineering teammate I can delegate to.

The app lets me set up multi-agent workflows for longer-running execution:

One agent reviews PRs,
another fixes bugs,
a third updates documentation.

I close my laptop and come back to the result. That makes Codex especially good for large refactors, GitHub-native workflows, team delegation, and background engineering work.

The underrated feature here is Codex’s /goal command. Instead of giving the agent a vague task like “improve this repo,” I can define the actual outcome I want:

reduce flaky tests,
migrate a module,
clean up auth logic,
prepare a PR-ready refactor.

Codex then uses that goal as the anchor for planning, execution, and review. That makes long-running delegated work feel less like prompting and more like assigning a scoped engineering objective.

OpenCode

OpenCode does not have a direct /goal equivalent, but its workflow solves the same problem differently.

Instead of asking me to assign a goal and wait for the result, OpenCode keeps me inside a tight loop:

define what I want,
inspect the proposed plan,
adjust the approach,
execute,
review the result,
repeat.

This is where Plan mode becomes important. It gives me a goal-like workflow without hiding the intermediate reasoning. I can see what OpenCode intends to do before it touches the codebase, which is useful when I am debugging, exploring unfamiliar code, or doing refactors where I want control over every step.

OpenCode also pairs well with repo-level instruction files like AGENTS.md. That makes its goal-setting less polished than Codex’s /goal, but more customizable. I can encode project conventions, testing expectations, architecture rules, and workflow preferences once, then reuse them across sessions.

The other major advantage is local execution. I can pair OpenCode with Ollama or LM Studio and run the agentic loop on my own machine with zero API calls. For security-sensitive work, regulated codebases, or local-first development, this is a real advantage.

Verdict

This one depends on how I want to work.

Codex wins for delegation: give it a scoped objective, let it run, and review the result later.
OpenCode wins for iteration: inspect the plan, steer the agent, and keep the feedback loop tight.
Codex feels more polished. OpenCode feels more controllable.

For routine background work, I prefer Codex. For interactive development and learning inside a codebase, I prefer OpenCode.

Tie.

OpenCode - 3, Codex - 3

4. Ecosystem (MCP + Skills + Plugins)

Aspect	Codex	OpenCode
MCP Setup	CLI commands (`codex mcp add`)	Manual config via `.opencode/mcp-config.json`
Skill Installation	Git clone to `~/.codex/skills/`	Clone to `~/.opencode/skills/`
Plugin Management	Marketplace CLI integration	Update `opencode.json` manually
Composio Integration	One-click via marketplace	Config file + manual setup
User Friendliness	More convenient, less transparent	More transparent, less convenient
Best For	Users who want simplicity	Developers who like transparency

You can have the best model, the best providers, and the best features and workflow, yet it means nothing if your models can’t talk to the real world and perform specified tasks in specified ways.

Codex and OpenCode both offer: MCP, Plugin & Skills, but both function differently.

Codex

Codex supports MCP integration. This is how easy it is to install:

I am going with Composio, as I usually use multiple MCP servers, and it's a pain to connect to and configure each one securely and to make agents handle multiple tool calls intelligently.

# Add Composio MCP server to Codex
codex mcp add composio

# Authenticate
codex mcp auth composio
# Opens browser for OAuth

Verify it's connected:

codex mcp list

Now, to make sure the MCP works properly, you can add skills with:

mkdir -p ~/.codex/skills
git clone https://github.com/ComposioHQ/awesome-codex-skills.git ~/.codex/skills/composio-connect
# Restart Codex

You can also add the Composio plugin using:

codex plugin marketplace add ComposioHQ/awesome-codex-plugins

And restart the app:

codex

But to do the same in OpenCode is a little tricky.

Open Code

OpenCode also supports MCP integration, but to add any MCP server, you need to update the config at .opencode/mcp-config.json .

# .opencode/mcp-config.json
{
  "mcp_servers": {
    "composio": {
      "type": "remote",
      "url": "https://connect.composio.dev/mcp"
    }
  }
}

Certainly not the most friendly interface, but good for transparency, as you can see what goes into the MCP server.

Next, add skills:

git clone https://github.com/ComposioHQ/awesome-codex-skills ~/.opencode/skills/composio

Restart OpenCode

opencode

This works because OpenCode looks for skills in project and global locations, including .opencode/skills, ~/.config/opencode/skills, .claude/skills, and .agents/skills .

You can also add the Composio plugin:

Add to opencode.json

{
  "plugin": [
    "opencode-composio",
    "opencode-context7"
  ]
}

Save and restart OpenCode:

opencode

Done!

Verdict

So Codex wins here due to process simplicity.

Open Code - 3 , Codex - 4

5. Harness Engineering

The model matters, but the harness decides how that model sees the repo, plans changes, calls tools, handles errors, and recovers when something breaks. In practice, the harness is the difference between “the model is smart” and “the agent is reliable.”

Aspect	Codex	OpenCode
Implementation	Rust-based, performance-focused CLI/app stack	TypeScript core with Tauri desktop app
Design philosophy	Tightly optimized around OpenAI models	Provider-agnostic and modular by design
Context handling	Strong default repo understanding with fewer choices	More explicit control over model, context, and instructions
Tool execution	Permission profiles, hooks, sandboxed/cloud execution	Local execution with permission gates and config-level control
Feedback loop	Optimized prompting, planning, and tool-calling pipeline	LSP diagnostics fed back into the agent loop
Strength	Speed, polish, and low-friction execution	Control, transparency, and production thoroughness
Tradeoff	Less model/harness customization	More setup and slower execution
Best for	Fast implementation and delegated engineering tasks	Complex refactors where correctness matters more than speed

Codex

Codex feels like a vertically integrated agent stack.

The model, prompt format, context strategy, tool-calling behavior, permission model, and review flow all feel designed to work together. That is the advantage of a closed, OpenAI-first harness: fewer knobs, fewer setup decisions, and fewer ways to misconfigure the system.

The strongest part is how little I have to think about the plumbing:

permission profiles decide what the agent can touch,
hooks let me run pre- and post-execution checks,
GitHub and PR workflows feel native,
tool calls are routed through a polished approval flow,
cloud execution keeps risky changes away from my local machine until review.

Everything is tuned around GPT-5.5. That matters because Codex is not just calling a model; it is shaping how the model receives the repo, plans the task, executes commands, and presents diffs back to me.

This is why Codex often feels faster than a generic agent using the same model. The harness reduces wasted motion. It does not ask me to design the workflow first; it gives me a working default and lets me move.

The downside is that this optimization comes with a ceiling. If I want to change the model strategy, deeply customize the execution loop, or route different tasks through different providers, Codex gives me much less room to experiment.

OpenCode

OpenCode takes the opposite bet.

Instead of optimizing one model inside one polished workflow, it gives you a modular harness that can work across providers, models, local runtimes, MCP servers, and repo-level instructions. It is less “batteries included,” but much more inspectable.

The most important engineering choice is the feedback loop. OpenCode can feed Language Server Protocol diagnostics back into the agent while it works. If the agent introduces a TypeScript error, the next step can include that error as context, so the model has a chance to self-correct before I even review the final diff.

That changes the feel of the tool. OpenCode may be slower, but it often behaves more like an engineer working with compiler feedback, not just a chatbot editing files.

It also gives me more control over the harness itself:

I can switch providers and models based on task type,
keep project-specific behavior in AGENTS.md,
run locally with Ollama or LM Studio,
wire in MCP tools manually,
inspect config instead of trusting a black box.

This is why OpenCode tends to feel better for production refactors. The loop is tighter, the configuration is more visible, and the agent can use local development signals instead of only relying on the initial prompt and repo context.

The tradeoff is obvious: more control means more responsibility. If the model choice is bad, the config is messy, or the repo instructions are vague, OpenCode will not hide that complexity from me.

Verdict

Codex has the better default harness. OpenCode has the better customizable harness.

Codex wins on speed and polish: it is optimized end-to-end for OpenAI models and gets me to a usable diff quickly.
OpenCode wins on control and feedback: LSP diagnostics, local execution, and provider flexibility make it stronger for careful refactors.
Codex abstracts the harness away. OpenCode exposes the harness and lets you tune it.

For a quick implementation, I would pick Codex. For a high-stakes refactor where I want visibility into every step, I would pick OpenCode.

This one is a tie, but for very different reasons.

OpenCode - 4 , Codex - 5

The Final Verdict: When To Choose What

Clearly, OpenCode is the winner with 6 points, but real engineers leverage both for their specific needs :

Codex for speed, overnight refactors, and production-critical work.
OpenCode for smart model routing, optimized costs, and offline critical workflows.

A simple table summarizes them.

	Codex	OpenCode
Best for	OpenAI ecosystem	Cost control, model flexibility
Setup	Zero friction, bundled into ChatGPT subscripton	Configure providers; slight model usage learning curve
Autonomous work	Cloud agent, good for overnight refactors	Terminal agent; depends on your model
Integrations	GitHub, PR review, Slack	MCP; varies by setup
Model choice	GPT-5 only	75+ providers; Claude via API key only
Offline	No	Yes, with Ollama/LM Studio
Transparency	Token-based credits	Full model + token visibility
Real cost	$20–$200/mo	Free BYOK, or ~$10–$50/mo routing

With a few months of usage, one thing is clear to me,

Choosing Codex or Opencode models is not about which benchmarks perform better; it's about picking the one that matches your workflow. Both are good in their own right, and best leveraged based on the needs.

9 Ways to Cut Token Consumption in Claude Code

Developer Harsh — Sat, 30 May 2026 11:40:56 +0000

After using Claude Code for serious coding work, the biggest lesson is simple: token consumption is not mainly a pricing issue. It is a workflow problem.

When my Claude Code session gets messy, performance drops. It starts rereading irrelevant files, remembering failed attempts, carrying old logs, and wasting context on things that no longer matter.

So my workflow is built around one principle:

Keep Claude's active context small, clean, and useful.

These are the 9 best ways to reduce token consumption in Claude Code that I use every day and can probably help you too.

tldr;

Don't send raw logs or full test results. Use filters and simple command wrappers to show only what matters: the error, the stack trace, the key details.
Sonnet handles most coding work fine and costs less. Use Opus for the really hard problems. For helper tasks and exploration, use Haiku.
Don't run expensive models on simple edits, and turn off extended thinking when you don't need deep reasoning.
Use /compact during a cleanup task while keeping what's important.
Use /clear with a handoff file when switching to something completely different. This doesn’t let old failed attempts pile up in context memory.
Only put instructions that Claude needs most of the time (how to run tests, build commands, folder structure, main rules). Keep everything else in separate skill files and only load them when you actually need them, saving your tokens.
Use Composio MCP to manage 1000+ tools as a single system instead of juggling 30+ active servers. When tasks are simple enough to use shell commands, use the composio CLI.

Filter the tool output before Claude sees it Raw logs are garbage for context. Claude does not need a 10,000-line test output. Instead, it needs the failing test, the stack trace, the expected vs. received values, and maybe the changed files.

So I avoid this:

npm test

And use filtered commands:

npm test2>&1 |grep-A5-E"FAIL|ERROR|Error|Expected|Received" | head-100

In my ideal setup, I create small wrappers like below and use them when needed:

cc-test
cc-lint
cc-typecheck
cc-log
cc-ci

Bottom line here is, I let Claude consume summaries, not terminal noise.

This one change saves the most tokens because it prevents context pollution before it even starts.

Match the model to the task Not every task needs the same horsepower, and running Opus on everything is one of the most expensive habits in Claude Code. Most coding work does not need Opus. Sonnet handles it at a fraction of the cost.

My setup:

/model sonnet   → default for most coding work
/model opus     → complex architecture, deep reasoning, tricky bugs
/model haiku    → repetitive tasks, boilerplate, quick lookups

I switch to Opus when I genuinely need deeper reasoning, and switch back as soon as the hard part is done.

For subagents specifically, I set:

CLAUDE_CODE_SUBAGENT_MODEL=haiku

This means exploration agents, log inspectors, and doc-lookup agents all run on Haiku. The main thread stays on Sonnet.

Extended thinking is another hidden cost - it burns output tokens for internal reasoning. For simple edits, I disable it:

MAX_THINKING_TOKENS=0      → trivial tasks
MAX_THINKING_TOKENS=10000  → architectural reasoning

In fact, this approach is so effective that it rarely lets my context memory fill up before it resets the 5-hour limit. Basically unlimited usage!

Bottom line: Using Opus for everything is like running every database query on your most expensive production server. Match the model to the work.

3. Don't let one session run forever with `/clear` + `/compact` + `handoffs`

After enough turns, the context fills with old attempts, wrong theories, stale file reads, and outdated decisions. Even if Claude still remembers everything, much of that memory is now toxic.

So I use /clear, but with a different workflow. I create a handoff.md file, include all the relevant details required, like goal, changed file, decisions made, and so on

Here is how you can do it too.

Before clearing:
Ask Claude to write .claude/session-handoff.md

Include:
- current goal
- changed files
- decisions made
- failing tests
- root cause
- next step

Then I run:

/clear

And restart with:

Read .claude/session-handoff.md and continue.

This gives me the best of both worlds: fresh context without lost progress.

For mid-task cleanup without a full reset, I use /compact instead. But I never run it blindly. Before compacting, I tell Claude exactly what to preserve:

/compact Preserve: optimistic locking for user updates, no schema changes this session.

Then:

/compact

This shapes what the summary will capture. In short, critical decisions gets added to context, while removing the noise.

The difference (a must-know):

/compact: summarize and continue, for tasks that require a lighter context.
/clear: full reset with handoff file, for tasks that require switching or starting fresh.

Bottom line: Don't treat /clear as a reset button. Treat it as context garbage collection. Use /compact for garbage collection mid-flight with instructions.

4. Keep `CLAUDE.md` minimal

Most people overload CLAUDE.md. They add architecture notes, deployment steps, PR rules, debugging checklists, style guides, testing philosophy, and random project history.

That feels organized, but it silently burns context every session.

My rule:

If Claude does not need it in 80% of sessions, it does not belong in CLAUDE.md.

My CLAUDE.md only includes:

- package manager
- test command
- build command
- repo layout
- core architecture constraints
- forbidden patterns
- naming conventions

Everything else goes into skills or separate docs folder.

Example:

.claude/skills/db-migration/SKILL.md
.claude/skills/pr-review/SKILL.md
.claude/skills/prod-debugging/SKILL.md

Bottom Line: Keep the base context light. loads the long workflow only when it's needed, keeping context quality intact.

5. Use plan mode before touching any code

Most context waste happens because Claude jumps straight into implementation without a clear plan.

It reads files speculatively, tries an approach, backtracks, and reads more files. By the time it reaches a working solution, the session is already polluted with failed attempts.

Plan mode separates thinking from doing by restricting access to the write-and-modify tool.

I press Shift+Tab twice before doing anything non-trivial

Shift+Tab → plan mode on

In plan mode, Claude reads files and reasons through the problem without making any changes. I let it map dependencies and surface unknowns.

Then I press Ctrl+G to open and edit the plan directly before Claude writes a single line of code.

Bad prompt (no plan):

Add Google OAuth to the login system.

Better workflow:

[plan mode on]
I want to add Google OAuth. What files need to change?
What is the session flow? Create a plan.

[review plan, edit if needed]

[plan mode off]
Now implement from the plan.

Bottom line: Claude solving the right problem the first time is always cheaper than rework. Let it plan, verify, and then execute.

6. Use bounded subagents for noisy exploration

Subagents are useful, but only when tightly controlled, as they tend to wander off.

I don't prompt:

Investigate the repo.

I prompt:

Inspect only src/auth and tests/auth.
Return max 15 bullets.
Include exact files.
No implementation.
No broad repo scan.

In general, I use Claude subagents for noisy work, such as log analysis, test failure inspection, dependency search, doc lookup, and blast radius analysis.

This multi-agent collaboration yields a cleaner workflow than a single-agent approach.

Bottom Line: The main Claude session should not carry all the exploration. It should only receive the compressed result from each agent.

7. Force surgical repo navigation

I don't ask Claude to "understand the codebase and explain it to me."

That usually causes broad scanning of wrong files, leading to unnecessary context usage, not to mention agents creating docs in the native repo (recent times)

Instead, I create a docs/repo_map.md with:

- main entrypoints
- key modules
- test commands
- auth/data/payment flows
- generated folders to avoid
- files Claude should read first

and then prompt accordingly. Here is an example of what I mean.

Bad prompt:

Understand the auth system and fix the bug.

Better prompt:

Find the login entrypoint. Read only the files needed to explain token validation. Do not scan unrelated directories.

This saves a lot of tokens because Claude starts from a map instead of wandering through the repo and figuring the repo out.

Bottom line: Repo Maps leads to fewer incorrect file reads, reducing context usage.

8. Lean on skills and plugins for progressive disclosure

Pulling stuff out of CLAUDE.md only helps if the place you move it to isn't also loaded every session. That is exactly what skills are for.

A skill is just a folder with a SKILL.md (a short name + description, then instructions, plus any reference files or scripts). The win is how it loads: at session start Claude only sees the name and description of each Claude skill, roughly 30 to 100 tokens each.

The full SKILL.md body loads only when Claude decides the skill is relevant, and any bundled reference files or scripts load only if they're actually needed.

So I can keep deep workflows around without paying for them upfront:

.claude/skills/db-migration/SKILL.md
.claude/skills/pr-review/SKILL.md
.claude/skills/prod-debugging/SKILL.md

Eight of these sitting in the project might cost a few hundred tokens at startup instead of dumping thousands of lines into context before any work begins.

The description is doing all the heavy lifting here, so I write it specific. "Helps with documents" never triggers. "Use when filling PDF forms and extracting table data" does.

Plugins are the next layer up. A plugin bundles skills, slash commands, subagents, hooks, and MCP servers into one installable unit, and you enable or disable the whole bundle on demand:

/plugin marketplace add <marketplace>
/plugin add <plugin>

The point is the same as everything else in this post: keep dormant capability out of the active context. Install the plugin when a project needs it, disable it when it doesn't, and you never carry tooling you aren't using.

Bad setup:

Everything stuffed into CLAUDE.md so it's "always available."

Better setup:

Tiny CLAUDE.md. Long workflows as skills with sharp descriptions. Capability sets as plugins you toggle per project.

9. Using Composio MCP and CLI

One of the top bottlenecks for me with the introduction of MCP was managing 30+ MCP integrations. Use fewer MCP servers, and the work won't be done. Use more, and it will add to the context memory.

Composio solved this for me by offering a universal MCP server that plugs into any MCP-supported agents and lets it connect to 1000+ services and tools, with on-demand tool loading, remote workbench for composing tools, and bash tool for handling edge cases with scripting.

Here is a brief breakdown of token savings with Composio MCP and without it for tasks that use tools such as Linear, GitHub, Sentry, Supabase, and Context7.

Without Composio MCP

With Composio MCP

As you can see, Composio used fewer tokens than the raw approach. It uses only seven meta tools and gets’ you the best bang for token used.

When I need even more reduction on top of that, I use the Composio CLI directly.

LLMs understand and parse shell commands better than tool schemas, they can be combined with multiple commands (composable), and has less to and from between servers and the LLM. It’s faster.

My rule: I start with Composio MCP to consolidate integrations, then move to CLI when the task is simple enough for a shell command.

Bottom line: Active MCP is added as a context tax that compounds across every chat. Every active tool adds overhead to the schema, description, and result. So use fewer, smarter integrations, not more.

My actual Claude Code workflow

If I were setting this up for daily development, my stack would look like this (in no particular order):

Start with tiny CLAUDE.md
Keep long workflows in skills
Use repo-map.md for navigation
Use cc-test / cc-log / cc-diff wrappers
Use Composio MCP to consolidate integrations, and CLI when a shell command will do
Use subagents for exploration, the Haiku model for agents
Write handoff.md before clearing context
Enter plan mode before any non-trivial implementation
/compact with explicit preservation instructions at task boundaries
/clear aggressively between unrelated tasks
Switch to Opus only for deep reasoning, back to Sonnet after
Keep the main thread clean

The real mindset shift for you is this:

Claude Code works best when you treat it like a powerful engineer with limited working memory.

Don't dump everything on it. Don't make it read garbage. Don't let old context pile up. Give it the right files, the right errors, the right constraints, and a clean session.

That is where token savings actually come from. Perform better harness engineering.

I Took Cursor Agents Out of the IDE and It Got Weirdly Powerful 🤯

Developer Harsh — Tue, 19 May 2026 10:05:31 +0000

Cursor recently released their cursor agents SDK to the public, and it's quietly powering many teams to:

invoke agents directly from CI/CD pipelines,
create automations for end-to-end workflows,
and embedding agents into core products.

Basically, the SDK lets developers deploy agents without overthinking building and maintaining the entire agent stack

in this blog I give a glimpse of what is possible with the cursor agents SDK and how to overcome the restrictions of limited tool access.

Let's start with a brief overview of cursor agents.

A Primer On Cursor Agents SDK

Building an agent from scratch is a massive headache. Cursor SDK skips the
plumbing.

Before the SDK, Cursor was strictly an interactive IDE, but its newly released SDK turns that
agentic power into headless infrastructure.

It uses the same harness that powers the desktop app, meaning you get IDE-grade code generation programmatically.

Harness: context engine, workspace management, and routing

In fact, the cursor harness matters more than the model. Endor Labs benched
GPT-5.5 natively at 61.5% functional correctness. Then, dropping the same model into Cursor's harness, it scored 87.2%.

Cursor spent years tuning the context management and tool dispatch; the SDK hands you that refined engine.

Here is the spec list for those who care:

Spec / Feature	Technical Detail
The Harness	Built-in codebase indexing, semantic search, & instant grep.
Execution	Cloud (sandboxed VMs with durable state), Self-Hosted, Local.
Models	Agnostic. Uses `composer-2/composer-3` (default), Claude, or OpenAI.
Integrations	Deep MCP support, auto-loaded `.cursor/skills/`, & hooks.
Subagents	Main agent can spawn subagents with distinct prompts/models.

This means we have a perfect stack to build our agent. Let’s get started with the setup.

How to Set Up Cursor Agents SDK

You can install it using npm to get started, then use Cursor's native cursor SDK skill for guidance.

So open your terminal and type:

npm install @cursor/sdk

Output

Once done, install the cursor skill for guiding the cursor / Claude Code. In the same terminal, run:

npm add skills /cursor-sdk

But there is a catch: by default, the Cursor SDK agents ship with a few default tools + MCP support.

However, this means connecting to or configuring multiple MCP servers is such a hassle for a production-grade product.

So let's automate it with Composio as the orchestrator, connect and configure it once, and you get secure access to 1000+ tools with optimized tool calls and context.

Building a Production Agent With Composio MCP + Cursor Agent SDK

Why Composio?

Composio offers a single MCP server you can plug into with the Cursor SDK to access 1000+ apps instantly.

When you’re building an agent that requires interacting with external applications, let’s say a Sales agent with Gong, HubSpot, Salesforce connectors, etc., you’d spend weeks on partnerships and integrations. Composio completely removes this friction, so you build what matters

So, let’s explore one example of a GitHub agent that pulls the repository, analyzes it, creates a dev branch, performs automatic refactoring, pushes the code, and opens a PR for review - a simple but powerful use case.

Let's begin!

Setup Workspace

Head to the terminal and run the following commands

mkdir cursor-agent
cd cursor-agent
npm init -y
npm install typescript ts-node @types/node --save-dev
npx tsc --init

The command will create a new project named cursor_agent , switch to the folder, initialize a blank npm project (ensure package.json gets created), install typescript support for development, and initialize the typescript compiler and linter.

Since our repository is set up, let’s configure environment variables.

Set up Environment Variables

Add a .env file to keep secrets secure and add the following values:

CURSOR_API_KEY=your-cursor-api-key
COMPOSIO_API_KEY=your-composio-api-key

You can get the CURSOR_API_KEY by going to the Cursor integration page and creating a new API key.

For COMPOSIO_API_KEY , visit the Composio Dashboard (Platform), log in/sign up to the account, and head to the default project (or create one) → profile→ API KEY.

Click “Create One”, it creates one, copy and then paste it into .env . Make sure it starts with ak_ .

Time to write the code.

The Code

Now, create a new index.ts file and paste the following code.

// imports
import "dotenv/config";
import * as readline from "node:readline/promises";
import { stdin as input, stdout as output } from "node:process";
import type { SDKAgent } from "@cursor/sdk";
import {
  DEFAULT_USER_ID,
  disposeAllAgents,
  getComposioApiKey,
  getOrCreateRuntime,
  requireEnv,
} from "./runtime.ts";

// log tool calls to stdout
function logToolCall(
  name: string,
  args: unknown,
  status: "running" | "completed" | "error",
): void {
  if (status === "running") {
    console.log(`\n[tool: ${name}] ${JSON.stringify(args)}`);
  } else if (status === "completed") {
    console.log(`[tool: ${name}] done`);
  }
}

// stream assistant text and tool events - act as streaming handler
async function runAgentChatStreaming(agent: SDKAgent, message: string): Promise<void> {
  const run = await agent.send(message);

  process.stdout.write("\nagent > ");
  for await (const event of run.stream()) {
    if (event.type === "assistant") {
      for (const block of event.message.content) {
        if (block.type === "text") process.stdout.write(block.text);
      }
    } else if (event.type === "tool_call") {
      logToolCall(event.name, event.args, event.status);
    }
  }

  const result = await run.wait();
  if (result.status === "error") {
    throw new Error(`Agent run failed (${result.id})`);
  }
  process.stdout.write("\n\n");
}

// runs the chat loop, adds a readline interface and disposes agents on exit
async function main(): Promise<void> {
  requireEnv("CURSOR_API_KEY");
  getComposioApiKey();

  console.log("Setting up Composio session...");
  const runtime = await getOrCreateRuntime(DEFAULT_USER_ID);
  console.log(
    `Ready (user: ${runtime.userId}, session: ${runtime.sessionId}, tools: ${runtime.toolsCount}).`,
  );
  console.log("Type a message, or 'exit' to quit.\n");

  const rl = readline.createInterface({ input, output });

  try {
    while (true) {
      const userInput = (await rl.question("you > ")).trim();
      if (!userInput) continue;
      if (userInput === "exit" || userInput === "quit") break;

      await runAgentChatStreaming(runtime.agent, userInput);
    }
  } finally {
    rl.close();
    await disposeAllAgents();
  }
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Let's look at the code:

We start by loading dependencies from .env, readline, and shared helpers from runtime.ts (getOrCreateRuntime, API key checks, and cleanup)
For a sanity check, we validate CURSOR_API_KEY and COMPOSIO_API_KEY before the chat loop starts (Composio is also checked when runtime.ts loads).
Next, we create a Composio session for the default user and spin up a Cursor agent on composer-2 with the Composio MCP server for tools (handled in runtime.ts).
We keep the same agent in the loop for every message, so tools and sessions stay wired throughout the CLI session.
We run a terminal chat loop with readline: read input → send to agent → stream assistant text and tool status → repeat until exit or quit.
While streaming, we log tool calls on running and completed, and throw if the agent run ends in error.
On exit, we close readline, dispose of agents via runtime.ts, and log any failure from main() before exiting with code 1.

If you encounter an issue, refer to the codebase in the project's GitHub repo. Feel free to clone it, tweak it to your liking, or use it as it is.

And that's it, all set, time to run the agent!

Run the agent

To run the agent in the terminal and at the project root, type:

npx ts-node index.ts

and an interactive chat opens up where you can prompt it step by step / direct it to do the entire task at once. Here is a demo of me using it in chat mode (step by step)

As you can see, the cursor agent acts as the brain, calling the Composio GitHub tools to clone the repo, check for changes, create a dev branch, refactor the code, commit to the dev branch, and finally open a PR.

Usually, this takes many human hours, but with a cursor-agent, it takes only 5 minutes.

Also, with the new update, you need to add a GitHub token to use GitHub with the cursor/agent. Using Composio fixes this need as well.

Note: For simplicity I have used terminal , but you can add a ui layer on top of the agent.

With this, we have reached the end of the article. Here is my closing note.

Final Thoughts

In this article, we learned how to use the Cursor SDK and Composio MCP to build a GitHub chatbot while keeping it optimized for asynchronous operations and following best practices, such as masking sensitive variables.

But this is just the tip of the iceberg with what's possible with the cursor agent SDK. Feel free to experiment and build your own assistant/chatbot. You can explore more in the cursor-cookbook.

At the end of the day, building agents / multi-agent systems is not hard; planning and orchestrating them to work efficiently, collaboratively, and securely is. In fact, it's the next valuable skill in 2026.

So what are you waiting for? Get started with Cursor Agents while Composio MCP handles the tooling layer.

Building Streamable HTTP MCP Servers from Scratch using FastMCP in 2026

Developer Harsh — Mon, 18 May 2026 14:50:04 +0000

If you've spent any time wiring up tools for an AI agent, you know the pain: every model vendor has its own function-calling format, every integration is bespoke glue code, and every model upgrade breaks something downstream.

MCP changes this by providing a shared interface for tools, data sources, and AI clients. Instead of rebuilding integrations for every model or app, you expose capabilities once through an MCP server and let compatible clients connect to them.

Anthropic released the Model Context Protocol in November 2024, and by spring 2025, OpenAI, Microsoft, and Google had adopted it. It has quickly become the de facto standard for connecting AI systems to external tools and data. That makes MCP worth learning now.

This guide teaches you how to build an MCP server from scratch, expose it over two transports: stdio and streamable HTTP, connect it to Claude Desktop and Cursor. and provide you with a production checklist for hardening the production MCP servers before shipping them. The full code is available in the companion repo at the end

tl; dr

What is MCP
MCP Components in Nutshell
Build a Local MCP server (tools, resources, and prompts)
Connect to Hosted MCP Server (HTTP Streamable)
MCP Server Advance Use Case
Deployment Notes for Production MCP Servers
Conclusion
Frequently Asked Questions

Let's Begin!

What is MCP

An MCP server is a JSON-RPC 2.0 process that exposes three primitives to any compliant MCP client over stdio or streamable HTTP. Those primitives are tools (functions the model can call), resources (data the model can read), and prompts (reusable templates). That's the whole protocol.

Everything else is an implementation detail as given in the comparison table.

Feature	Model Context Protocol (MCP)	Traditional API (REST / GraphQL / gRPC)
Primary purpose	Give LLM-based agents a single way to fetch context and invoke side-effecting tools.	General machine-to-machine data exchange & business logic.
Integration effort	Once an agent speaks MCP, it can talk to any compliant server; only one SDK/wire-spec to learn.	Each API exposes its own spec/SDK; you integrate them one by one.
Interaction model	Stateful sessions + bidirectional messaging; supports long-running tasks and mid-job progress callbacks.	Stateless request/response; usually unidirectional.
Streaming support	Standardised via “Streamable HTTP” (SSE/WebSocket).	Not part of the REST spec; developers bolt on WebSockets/SSE ad hoc.
Extensibility (adding new capabilities)	The server can add new tools/resources without breaking clients; the agent discovers them at runtime.	Breaking changes need versioning, or clients must update to use new endpoints/types.
Standardisation/wire format	One JSON-Schema-driven spec for inputs & outputs, plus defined transports.	Multiple styles (REST, GraphQL, gRPC) with differing auth headers, error shapes, and media types.
Maturity & tooling	Rapidly growing, but still early; dozens of open-source servers and early commercial support.	Decades of best-practice guides, gateways, SDKs, APM, and monitoring.
Performance path length	Extra hop (agent → MCP → underlying API) adds a bit of latency; streaming mitigates waiting for large payloads.	Direct call; generally lower overhead for high-QPS, deterministic workloads.
Typical sweet-spot use-cases	Autonomous agents chaining multiple tools, dynamic workflows, and user-in-the-loop	CRUD data services, stable integrations, high-throughput micro-services.

If you want a deeper conceptual primer, check out the Model Context Protocol explainer, which covers the architecture in detail. For primer, here is how this all works!

MCP Components in Nutshell

The Architecture

The MCP architecture consists of several key components that work together to enable seamless integration:

MCP Hosts: Applications that want to use tools or data through MCP. Examples include Claude Desktop, Cursor, or any AI app that supports MCP.
MCP Clients: Client instances created by the host. Each client maintains a dedicated one-to-one connection with a single MCP server.
MCP Servers: Lightweight programs that expose tools, resources, and prompts through the MCP protocol.
Local Data Sources: Files, databases, codebases, or local services that an MCP server can access on the user’s machine.
Remote Services: External APIs or cloud services that an MCP server can call, such as Google Sheets, GitHub, Slack, or Postgres hosted in the cloud.

At a high level, the host does not talk directly to your database, file system, or API. Instead, it talks to an MCP client, which talks to an MCP server, which then talks to the actual data source or service.

This simple diagram might help you understand the flow better:

The key point is that MCP servers serve as the integration layer. They hide the messy parts of authentication, API calls, file access, and business logic behind a clean protocol interface.

This separation of concerns makes MCP servers modular and maintainable. The AI app does not need to know how Google Sheets, GitHub, or a local database works. It only needs to know how to call the MCP server.

So how does this all connect?

How The Components Work Together

Let's understand this with a practical example:

Say you're using Claude Code (an MCP host) to manage your project's budget. You want to update a budget report in Google Sheets and send a summary of the changes to your team via Slack.

Claude Code (MCP host) initiates a request to the MCP client to update the budget report in Google Sheets and send a Slack notification.
The MCP client connects to two MCP servers: one for Google Sheets and one for Slack.
The Google Sheets MCP server calls the Google Sheets API (remote service) to update the budget report.
The Slack MCP server interacts with the Slack API (remote service) to send a notification.
MCP servers send responses back to the MCP client.
The MCP client forwards these responses to Cursor, which displays the result to the user.

This process happens seamlessly, allowing Cursor to integrate with multiple services through a standardized interface.

That's the working in a nutshell. From here on, we will focus on building.

Build Local Stremable HTTP MCP Servers

We'll build something you'd actually deploy: a GitHub issue search server that lets your AI assistant search issues, fetch issue details, and pull recent pull requests from any repository. [subject to change]

We will follow a series of steps to make sure things go smoothly. This is also industry standard, so it's best to follow along.

Prequires

Before anything else, ensure you complete the prerequisites, as they will be the foundation for any MCP implementation we do.

You'll need:

Python 3.10+
Node.js 18+ for TypeScript (if you choose to build with TypeScript)
Claude Desktop or Cursor for testing

A common question users often ask: when should you pick Python vs. TypeScript? Here is an honest review:

Python with FastMCP is faster for prototyping and works well for stdio servers.
TypeScript shines for HTTP servers deployed to Cloudflare Workers, Vercel Edge, or any Node-based stack due to its type safety.

In case you are wondering, Composio is the ultimate integration platform, empowering developers to seamlessly connect AI agents with external tools, servers, and APIs with just a single line of code.

With the fully managed MCP Servers, developers can rapidly build powerful AI applications without the hassle of managing complex integrations.

In a nutshell: Composio handles the infrastructure so developers can focus on innovation.

Next, let's set up the working environment.

Work Environment Setup

We start by creating a project directory.

Navigate to your working folder and create a folder named MCP, or u can use the terminal command:

mkdir mcp_servers
cd mcp_servers

Next, create a virtual environment using:

python3 -m venv .venv

Now activate the environment with:

# Windows:
.venv\Scripts\activate

# Linux/Mac:
source .venv/bin/activate

Ensure you see (.venv) in Front of the terminal cwd path.

Finally, install the FastMCP package

pip install FastMCP

Writing Server Code

Server code is where the entire MCP server logic lives. Create a new server.py file and inside it paste the code below:

# server.py

# imports
import base64
import os
import uuid

from typing import List
from fastmcp import FastMCP

mcp = FastMCP("Utility MCP Server")

# generate password utility
@mcp.tool()
def generate_password() -> str:

    """
    Generate a pseudo-random password for development use.

    This function creates a password by encoding a UUID4 string in base64
    and then reversing the resulting string. It's intended for use in
    development or testing environments where cryptographic security is not
    critical.

    Returns:
        str: A reversed base64-encoded UUID4 string, typically around 48 characters.
        May include alphanumeric characters, '+', '/', and '=' padding.

    Security Notes:
        - Uses the string form of UUID4 (not raw bytes), so effective entropy is lower (~190 bits of input chars)
        - Suitable for temporary or development credentials.
        - NOT recommended for production use.
        - For higher security, consider using secrets.token_urlsafe().

    Example:
        >>> generate_password()
        '==dGM0ZTcwLTI0ZTUtNDJlZC05Y2I1LTk3OGJjODAxMDAwNw=='
    """

    uuid_string = str(uuid.uuid4()).encode()
    base64_encoded = base64.b64encode(uuid_string).decode()
    return base64_encoded [::-1]

# list all the files in the directory
@mcp.tool()
def list_files(directory: str = ".") -> List[str]:
    """
    List all files and directories in a specified path.

    This tool allows the AI to explore the file system by returning a list 
    of names of the entries in the directory given by path.

    Args:
        directory (str): The path to the directory to list. Defaults to the 
        current working directory (".").

    Returns:
        List[str]: A list of filenames and directory names. If an error 
        occurs (e.g., directory not found), returns a list containing 
        the error message.
    """
    try:
        return os.listdir(directory)
    except Exception as e:
        return [f"Error: {str(e)}"]


# read the given file
@mcp.tool()
def read_file(filename: str) -> str:
    """
    Read and return the full text content of a file.

    This tool enables the AI to analyze the contents of specific text files 
    within the accessible file system.

    Args:
        filename (str): The path to the file that needs to be read.

    Returns:
        str: The complete string content of the file encoded in UTF-8. 
        If the file cannot be read, returns an error message starting 
        with "Error reading file:".
    """
    try:
        with open(filename, 'r', encoding='utf-8') as file:
            return file.read()
    except Exception as e:
        return f"Error reading file: {str(e)}"

# system info (resource)
@mcp.resource("data://sys-info")
def get_system_info() -> str:
    """
    Get a comprehensive system snapshot including time, hardware specs, 
    and real-time health metrics.
    """
    import platform
    import psutil
    import subprocess
    from datetime import datetime

    now = datetime.now()
    timestamp = now.strftime("%Y-%m-%d %H:%M:%S")
    day_name = now.strftime("%A")


    boot_time = datetime.fromtimestamp(psutil.boot_time())
    uptime = str(now - boot_time).split('.')[0]

    sys_type = platform.system()
    machine = platform.machine()
    cpu_count = psutil.cpu_count(logical=False)
    try:
        gpu_info = subprocess.check_output(
            ["nvidia-smi", "--query-gpu=gpu_name", "--format=csv,noheader"], 
            encoding="utf-8"
        ).strip()
    except Exception:
        gpu_info = "N/A (NVIDIA-SMI not found)"

    cpu_usage = psutil.cpu_percent(interval=None)
    memory = psutil.virtual_memory()
    disk = psutil.disk_usage('C:\\')

    return f"""
             --- Hardware Specs ---
            OS:        {sys_type} ({machine})
            CPU:       {cpu_count} Physical Cores
            GPU:       {gpu_info}

            --- Temporal Context ---
            Date/Time: {timestamp}
            Day:       {day_name}
            Uptime:    {uptime}

            --- Resource Utilization ---
            CPU Load:  {cpu_usage}%
            RAM Usage: {memory.percent}% ({memory.used // (1024**2)}MB / {memory.total // (1024**2)}MB)
            Disk (C:): {disk.percent}% Used ({disk.free // (1024**3)}GB Free)
            """

# general prompt
@mcp.prompt()
def helper_prompt(task: str, context: str = "") -> str:
    """General purpose prompt for any task with optional context."""
    base_prompt = f"""
Task: {task}

Please approach this systematically:
1. Break down the problem
2. Consider multiple solutions
3. Explain your reasoning
4. Provide clear, actionable steps
"""

    if context:
        base_prompt += f"\n\nAdditional context: {context}"

    return base_prompt

# api-design rules prompt
@mcp.prompt()
def api_endpoint_design_prompt(endpoint_name: str, purpose: str) -> str:
    """Specific prompt for designing RESTful API endpoints."""
    return f"""
Design a RESTful API endpoint: {endpoint_name}
Purpose: {purpose}

Please provide:
1. HTTP method and URL pattern
2. Request/response schemas with examples
3. Status codes and error handling
4. Authentication requirements
5. Rate limiting considerations
6. OpenAPI/Swagger documentation snippet

Follow REST conventions and include proper validation.
Use JSON for data exchange and meaningful HTTP status codes.
"""

# Run MCP server
# if __name__ == "__main__":
    # mcp.run()

# Run stremable http MCP Server (can be deployed / hosted)
if __name__ == "__main__":
   mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

Key points from the code:

mcp : It's the Fast MCP object named as provided. Important to initialize at the start.
@mcp.tool() : Decorator wraps the entire function underneath and exposes it as a tool to the MCP client. Docstrings are very important; a good docstring leads to fewer model failures. Includes generate_password , list_files, read_filetools.
@mcp.resource("data://sys-info") : Decorator wraps the entire function and exposes it as a resource file that the client can use to fetch data. The path to the created resource is defined in () . Includes get_system_info resource
@mcp.prompt() : Decorator wraps the entire function and exposes it to the client as a prompt builder, useful when the task requires a specific use-case prompt. Docstrings are important here. Includes helper_prompt , api_endpoint_design_prompt
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000) : Runs the MCP server.in a streamable HTTP mode. For stdio MCP server, use mcp.run()

Overall, we are wrapping different functions and exposing them to the client as the MCP tool, resources, and server.

However, to use it with the client, additional config is required, so let's set that up. I am using a cursor for the demo.

Head to the Cursor and create a new folder .cursor , inside it creates a new file mcp.json (the config file) and paste the following setup.


{
    "mcpServers": {
        "utility-server": {
            "url": "http://localhost:8000/mcp"
        }
    }
}

In case you have used mcp.run() then you will see the below configuration

{
    "mcpServers": {
        "utility_server": {
            "type": "stdio",
            "command": "your-python-exe-path",
            "args": ["your file path"]
        }
    }
}

In general I use local stdio based servers and then when all test and specifications are met, I switch to Streamble HTTP approach.

Quick Tip: To verify this works is by pasting the command and args together; if they start the server, you are good to go; else, provide the full path. I usually go for path of .venv’s python.exe

Open Cursor Settings, then click Tools & MCPs. You will see your local MCP name. Click Enable,

To check, open the terminal, switch to the Output tab, select the MCP server, and check for the connected message.

Now we can test our MCP Server by opening the chat/agents window and invoking any of the defined tools via the prompt. I invoked the password-generator, as I often find myself asking Claude to "think of a 16-character password" (which is terrible).

Generate password + show mcp tool usage

Here is the output:

Saw that Ran command, it means the MCP server asked me for permission. I kept it that way, as you never want to let an agent touch your system files.

Note: If docstring is poor, the mcp client might fall back to cli approach, the easiest way to fix this is add a rule to only use mcp servers for the task. You will find a similar approach in the project github repo as well.

All this is great, but setting it up for testing a local MCP server is a hassle. Let's look at an easier approach, MCP Inspector.

Test with MCP Inspector

To test the MCP server's functionality, we will use the Fast MCP Inspector, a browser-based tool that connects to the server and lets us call tools directly, without an LLM layer.

Run MCP Inspector, with:

npx @modelcontextprotocol/inspector python server.py

You'll see a localhost URL. Open it in your browser, click Connect, and you should see your server respond.

Now you can run and test your tools, resources, prompts, and more right from the browser, quite handy for developers testing MCP servers' performance and understanding response schemas. Check out the MCP Inspector Guide to learn more.

Personally, I find it best for testing prompts’ responses. Here is the response it generated:

Local servers are great for simple use cases, but for most industry use cases, they don't provide the required infrastructure. Let's explore better use cases.

Connect to Hosted Streamable HTTP MCP Server

Having a local server is good, but not as great as the one used in production. Usually, these are hosted, secured by design, and optimized for multiple tool calls.

Usually, these are servers written by expert developers, integrated with the app's internal mechanisms, and intended to serve as connectors.

But here lies the issue: connecting to 30+ MCP servers for a single project is a pain. Composio solves this.

Let's look at how you can connect to the hosted Composio MCP server. You connect it once and use 1K+ tools directly, all secure, optimized tool calls.

Connect to Composio MCP Servers (Streamable HTTP )

Integrating with Composio MCP is incredibly simple and takes just 5 steps.

Visit the Composio MCP page. Ensure you are logged in, or else sign up

In the dashboard, head to the Install Section

Select Cursor from the list, and click on Install.

In the redirected page, click on "Install in Cursor".

You will be redirected to Cursor, and in the MCP server Page, click Install

Once installed, click on Needs Authentication, then Authorize at redirect, and done!

You can connect to apps in advance in the Connect Apps section; most of them use OAuth. (optional). If you don't, the agent will prompt you to connect at runtime.

To test the integration, open the Composer, establish a connection to the app, and ask it to perform actions.

But how did all this happen?

It turns out that if you go to your cursor MCP & Tools Page, select the ✏️ icon, and see the configuration as:

{
  "mcpServers": {
    "composio": {
        "type":"http",
      "url": "https://connect.composio.dev/mcp",
      "headers": {}
    }
  }
}

The http here means a streamable HTTP server. This allows the MCP server to operate as a normal web server (accessible via a URL) rather than as a local subprocess on your machine (for local MCP servers)

And interestingly, for any MCP to run in HTTP streamable mode, you have to replace:

if __name__ == "__main__":
    mcp.run()

if __name__ == "__main__":
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

And you are done, pretty handy, isn’t it?

Now, let's look at an advanced use case to see where Composio MCP helps.

Using HTTP Streamable MCP Servers for Advanced Use Case (Financial Agent)

Current financial institutions struggle with manual, time-intensive investment research that keeps analysts buried in data entry for weeks, delays critical decisions by days, lacks real-time risk visibility, creates compliance blind spots, and demands hiring more analysts just to manage portfolio volume - all while losing talent and clients

Let's see how the analyst can build financial agents and leverage Composio MCP to connect to 10-15 financial data sources (Yahoo Finance, SEC filings, Google Sheets, Bloomberg, etc.) and enrich their analysis by aggregating structured APIs, unstructured web scraping, and internal data warehouses.

The financial analyst agent will:

Aggregate financial data (Yahoo Finance, Google Sheets with company data, SEC filings via web scraping),
Run Claude analysis to generate investment thesis.
Create formatted reports in Google Docs,
Track portfolio changes (pull from Excel sheet),
and send Executive Summaries to stakeholders via email with embedded tables. (HTML format)

All done in parallel!

Web Scraping (composio & search api) + Google Sheets (composio) → Claude Analysis → Google Docs (composio) → Gmail (composio)

Prerequisites

Claude Code / Cursor / VS Code. I am going with Claude
Composio Account, login/signup

Assuming you have pre-requisites met, let's set up Composio on Claude.

Set up Composio MCP in Claude

To get started:

Visit the Composio MCP page. Ensure you are logged in, or else sign up
In the dashboard, head to the Install Section
Select Claude from the list, and click on Install.

On the next page, select the MCP tab, then copy the command & paste it into the shell/terminal.

claude mcp add --scope user --transport http composio https://connect.composio.dev/mcp

Ensure /mcp shows composio as an option. It might require authentication, so authenticate once

(Optional ) Once done, head to the Connect Apps page and click on Connect to connect Gmail, Google Drive, Google Sheets, and Google Docs. In case you ignore, agent will ask for these connections on runtime.

Perfect, we only need to configure the document in the workspace

Set up Workspace for Agent

We will use Google Drive as our workspace to make the file accessible from everywhere:

Head to drive, create a new folder named financial_data & from the URL, copy the folder ID.
Inside, add an Excel file in the format & fill the data as:
- Companies: List of all targeted companies with their analysis
- Portfolio Performance: How the portfolio is performing over time, all metrics for targeted companies
- Contact: List of all internal contacts: Portfolio Managers, Limited Partners, Investors, Board Managers, and more
- Report Archive: Past report filing (sec)
Then add a Google Doc template for an investment report.

Make sure to copy the ID / URL of both files

Easiest way is to use the template given in the GitHub Repo and let any AI Agent turn them in the above given format. Then copy paste that in newly created google sheet & google doc file.

Now is the time to run the agent.

Run Financial Analyst Agent

To run the agent, open Claude Code and paste the financial_agent_prompt. You will be prompted to fill in the details with the copied values from earlier, and add your email address:

GOOGLE_SHEETS_ID: [your value]
GOOGLE_DOC_TEMPLATE_ID: [your value]
GOOGLE_DRIVE_FOLDER_ID: [optional]
GMAIL_SENDER_ADDRESS: [your gmail]

Once done, the agent handles the rest. Here is a demo of what it looks like, in production.

The agent also works on multiple portfolio reports. I am testing it with six different portfolios; you can adjust the count as needed.

Same setup, but with multiple portfolio data. Make sure to copy each one's ID, and use the financial_agent_prompt_for_multiple portfolio for the job.

Note that, despite explicitly stating that Claude never created a subagent, this is because composio already has parallel execution enabled and, behind the scenes, uses subagents.

Hope this gave you an idea of how hosted MCP servers work, and tools like Composio MCP provide a universal tooling layer.

However, deploying a hosted MCP server for production is a different game. Let's look at a few rules to help ensure the servers don't break in real-world use.

Deployment Notes for Production MCP Servers

Though we didn't cover a hosted MCP server build, if you want to build your hosted MCP server (local + later deployed), follow the production checklist before you deploy & put an MCP server in front of real users:

Logging to stderr or files only, never stdout for stdio servers
Errors caught on every tool: return a clean error message, don't let exceptions kill the connection
Inputs validated: type hints (Python) or Zod (TypeScript) catch most issues; add explicit checks for things like SQL injection or path traversal if you're doing database/file operations
External API calls are rate-limited / Use Composio MCP: your tool runs whenever the LLM decides to call it, which can be a lot. Let Composio MCP handle it.
Secrets in environment variables, never hardcode in servers, never commit in production.
Tool descriptions for the LLM: Write specific, one-purpose per tool. Five small tools beat one giant tool. The approach we followed.
Schema versioning: when you change a tool's signature, bump your server's version so clients can adapt. Think API versioning.
Health check endpoint: for HTTP servers, expose /health for your load balancer. Provides transparency to users.
Auth on production HTTP servers: Use Bearer for internal, OAuth for public. But never both for the same for public/internal (private)

With this, we have come to the end of this comprehensive guide. Here is what matters the most.

Conclusion

As AI transforms software development, MCP will play an increasingly important role in creating seamless, integrated experiences.

Whether you're building custom MCP servers or leveraging pre-built solutions like stremable http servers like Composio MCP, the protocol enables powerful enhancements to AI capabilities through external tools and data sources.

In case you need a few ideas, check out how to build an MCP client that talks to your server, or move up the stack and build an MCP-powered agent that orchestrates multiple servers at once. Happy building.

I hope you had a great learning experience - happy building with Composio! 🚀

Top Marketing Skills For Claude Code, OpenClaw & Hermes

Developer Harsh — Fri, 24 Apr 2026 06:18:47 +0000

With tools like Claude Cowork and OpenClaw, the marketing and GTM stack is evolving fast. People are spinning up SEO pages, firing UGC videos, automating ads at an industrial scale. And GTM and marketing is going to blow up in next few months.

So, I have curated some great skills that community has built and some of them I personally use.

So I spent last week testing and collating everything. Here are the 10 marketing skills for Claude Code/ Cowork and OpenClaw that are actually worth using.

Quick Summary

GEO / AEO (AI Search Optimization) Skill - Audits and optimizes pages to get cited in AI search (ChatGPT, Perplexity, Google AI Overviews) with fixes, llms.txt, and schema.
SEO + GEO Full-Stack Skill - An end-to-end workflow that does keyword research, drafting, and optimization for both traditional SEO and AI discovery.
Paid Ads Audit Skill - Runs deep multi-platform checks to find wasted spend, diagnose performance issues, and generate new creative and copy variants.
Firecrawl Web Intelligence Skill - Gives agents live web scraping and crawling to extract clean markdown and structured data for competitive research.
Design Skill - Extracts design systems from UI references and outputs design tokens and specs to keep builds consistent and non-generic.
Remotion Video Skill - Turns a video brief into Remotion-ready React code so you can ship programmatic product videos reliably.
Marketing Page Generation (Frontend) Skill - Generates bold, conversion-focused landing pages with production-ready code instead of generic SaaS templates.
Content Ops Skill - Runs the editorial pipeline end-to-end: audit, briefs, drafting, repurposing, and distribution from one workflow.
Humanizer Skill - Removes AI-writing tells through multi-pass editing so posts sound opinionated, natural, and genuinely human.

For using all these skills effectively you’ll need access to data stored in multiple different applications.

For example, for full SEO data you’d need access to Google Search Console, Ahref, etc. And for scheduling posts for social medias you’d need to connect Claude or OpenClaw with Tiktok, Youtube, LinkedIn, Reddit, and Twitter.

For Ads and conversion pipeline monitoring yo’d need Google Ads, MetaAds, Posthog, Mixpanel, etc.

Check Out the full catalog.

Composio is the single place to get all these apps using a single MCP server and it’s super easy to set it up. Just log in to dashboard.composio.dev and click on the client app you want.

If you need some guides, here’s how you can do it in OpenClaw and Claude Cowork.

For starters, let’s schedule a week of launch posts for social media - one of the grueling pain point for any content team.

Pre-requires (authenticate):

once all done, let’s create a 7 days launch post. This uses Claude Code.

/to-be-added

Top 10 Marketing Skills

Here are the list of top 10 marketing skills, that can 10 your marketing. For each I have shared:

What each skills does,
Why use it.
Prompt templates you can follow,
The link to get you started

Let’s begin:)

1. GEO / AEO SKILL - AI SEARCH OPTIMIZATION

AEO has become quite popular now a day’s, but not many are good at handling it.

This skill optimizes the content to get cited by ChatGPT, Perplexity, Google AI Overviews, and Gemini. Furthermore, it scores citability, generates llms.txt, adds schema markup, and outputs a client-ready PDF audit report.

Usage

Run a full GEO audit on any URL → get citability score + prioritized fix list across 13 dimensions.
Generate an llms.txt file so AI crawlers understand the product site structure and index it correctly.
Optimizes existing blog posts for AI citation with E-E-A-T signals, entity clarity, and FAQ schema injection
Produce a branded PDF GEO report ready to send to a client or CMO, for contrast agencies charge $2K–$12K for this

Prompt

Run a GEO audit on [URL]. Score: citability, AI crawler access, brand mention presence, schema markup, content factual density, and E-E-A-T signals. Output a full report with prioritized fixes. Then generate an llms.txt file and FAQ schema JSON-LD for the top 3 pages.

To learn more , checkout https://github.com/zubair-trabzada/geo-seo-claude by zubair.

2. SEO + GEO FULL STACK SKILL

your entire SEO + GEO workflow packaged into 20 skills covering: keyword research, content writing, technical audits, and rank tracking for both traditional search and AI platforms using claude code, openclaw , hermes.

All scored against the CORE-EEAT benchmark (80 items) and CITE domain rating (40 items).

Usage

Runs keyword research on Ahref → content gap analysis → full draft → AEO/GEO optimization in a single chained workflow
Audit any page against 80 CORE-EEAT quality criteria and get a scored report with line-level fixes
Generate programmatic SEO pages at scale from a keyword list and a content template
Optimize for AI citations across ChatGPT Search, Perplexity, and Google AI Overviews simultaneously

Prompt

Run the full SEO + GEO workflow for [topic/URL]. 

Step 1: keyword research and gap analysis vs [competitor]. 
Step 2: write a 1,500-word article scored against CORE-EEAT. 
Step 3: apply AEO optimization - add FAQ schema, HowTo markup, and question-phrased headings. 
Step 4: output a GEO readiness score.

You can explore more at: https://github.com/aaron-he-zhu/seo-geo-claude-skills by arron

3. PAID ADS AUDIT SKILL

Running a successful paid campaigns and auditing is a struggle point for many growth team, this skills fixes that.

It first runs 250+ checks across Google, Meta, YouTube, LinkedIn, TikTok, and Microsoft Ads. Based on the result, invoke's parallel agents per platform that scores accounts with weighted rubrics, flags wasted spend, and generates AI-powered creative variants.

Usage

Audit a Google Ads account → get wasted spend breakdown by campaign, ad group, and keyword in one pass
Detect creative fatigue across Meta campaigns → auto-generate 5 replacement hooks per underperforming ad set
Run a CPA spike diagnosis → trace root cause to bid strategy, audience overlap, or landing page mismatch
Get a CMO-ready performance report with scores, benchmarks, and an action plan - all from the terminal

Prompt

Audit this Google Ads account data [attach export]. Run: wasted spend analysis, quality score breakdown, bid strategy assessment, and creative fatigue check. Score each area 0–100 using 2026 benchmarks. Output a prioritized fix list and generate 3 replacement ad copy variants for the lowest-scoring ad groups.

You can learn more at https://github.com/AgriciDaniel/claude-ads by Daniel.

4. FIRECRAWL WEB INTELLIGENCE SKILL

Not something new, similar to firecrawl-claude-plugin, but help’s content team hours by providing claude code / openclaw/ hermes access to live web.

This allows the agent to scrape any page as clean markdown, take full-page screenshots, extract structured data via JSON schema, and crawl entire doc sites. Handles JS rendering and anti-bot automatically.

Usage

Scrape competitor pricing pages weekly → output structured comparison to a Sheet with zero manual copying
Crawl a competitor's entire blog → extract all topics covered → identify content gaps in your own strategy
Pull product reviews from G2, Capterra, or Reddit → auto-summarize into a customer voice report
Run firecrawl x competitor-analysis [URL] in one command to get a full messaging teardown

Prompt

Use Firecrawl to scrape [competitor URL]. Extract: headline, value prop, pricing tiers, key feature claims, and CTA copy. Then scrape [second competitor URL] and output a side-by-side comparison table with a 'gap for us' column."

You can learn more at https://github.com/firecrawl/firecrawl-claude-plugin by firecrawl.

5. DESIGN SKILL

Design is essential aspect of conversion flow, it all starts there. Having a great design that tells a story of the product leads to better conversions. But ai-generated design’s are slop.

This skills fixes that. It extracts design systems from reference UI images and generates implementation-ready design tokens, component specs, and style guides.

This kills the back-and-forth between designer and agent.

Usage

Feed a screenshot of any UI → get a full design system extracted with colors, spacing, typography, and component patterns.
Generate brand-consistent design tokens for a new product from a single reference image.
Audit existing UI for design consistency issues and get a structured fix list.
Bootstrap a complete design system from scratch using decision-tree prompts before a single line of code.

Prompt

Extract the design system from this UI screenshot [attach image]. Output: color palette with hex values, typography scale, spacing system, component inventory, and border/shadow tokens. Then generate a DESIGN_SYSTEM.md I can reference in all future builds.

This one I use almost every weeks. Learn more at: https://github.com/daymade/claude-code-skills

6. REMOTION VIDEO SKILL

Product launch videos can make or break a product lead generation strategy and launch videos are in high demands so charges very high. With this skills you can build your own one, practically for 0$

This skills is official Remotion guidance baked into a SKILL.md. It gives Claude Code the knowledge to generate React-based programmatic videos without hallucinating the API.

Describe a video, get production code.

Usage

Generate a launch announcement video from your product copy - hook, feature highlights, CTA- fully coded in React
Build a weekly metrics video that pulls live data and renders as an MP4 automatically
Create social-ready short-form video assets (16:9, 9:16) from existing blog content
Render music videos from audio files and lyrics using the acestep-simplemv pattern

Prompt

Using Remotion, build a 30-second product launch video for [product name]. 

Scene 1: bold headline on dark background. 
Scene 2: 3 feature callouts with staggered animations. 
Scene 3: CTA with logo. 

Export at 1080x1920 for Instagram Reels. Follow Remotion best practices throughout."

You can learn more at: https://github.com/mxyhi/ok-skills

7. MARKETING PAGE GENERATION SKILL - FRONTEND

Here is another design skill but tailored to marketing page generations, which surprisingly Gemini 3.1 pro does the best, but lacks the color and aesthetic.

This skills instructs Claude / OpenClaw to skip safe, generic aesthetics and commit to bold design decisions. 277,000+ installs.

Best part? Automatically triggers for any frontend task - landing pages, campaign pages, dashboards.

Usage

I use it to :

Generate a full SaaS landing page with hero, features, social proof, pricing, and CTA sections in one pass.
Build campaign-specific microsites from a brief - product, ICP, and tone - without touching Webflow.
Rebuild an underperforming landing page with a distinct visual identity from a reference URL.
Scaffold a complete marketing site with dark mode, responsive layout, and conversion-optimized structure.

Its a great one and I personally use it to build landing pages for product that leads to high conversion rate. Really a must have!

Prompt

Build a landing page for [product]. Target audience: [ICP]. Tone: [direct/editorial/minimal]. Must include: hero with headline + subhead + CTA, 3-feature section, social proof strip, and pricing table. Choose a bold, distinctive aesthetic - not generic SaaS. Output production-ready HTML/CSS/JS or React + Tailwind.

Give it a try at https://github.com/anthropics/claude-code/tree/main/plugins/frontend-design

8. CONTENT OPS SKILL

Your entire content operations workflow under one skill.

It contains 8 skills that covers: production, audit, repurposing, and distribution. Works as a full editorial pipeline: from brief to published inside Claude Code or OpenClaw.

Simply put, its a swiss army knife for content and growth team as well.

Usage

Run a full content audit: feed your sitemap → agent scores each page by intent, keyword alignment, and conversion potential → outputs prioritized fix list
Repurpose one long-form piece → 5 tweet threads + 3 LinkedIn posts + 1 newsletter section in one command
Generate a 12-week content calendar from your ICP, product pillars, and keyword list
Auto-draft blog posts from raw notes or voice transcripts, following your brand voice file

Prompt

Run a content ops workflow for [topic/URL]. Step 1: audit existing content for gaps vs [keyword cluster]. Step 2: generate 4 new content briefs targeting missed keywords. Step 3: draft post #1 in full using our brand voice [attach]. Step 4: repurpose it into 3 LinkedIn posts and a tweet thread

Get your content pipeline started: https://github.com/superamped/ai-marketing-skills by superramped.

While the content pipeline works, but it may still feel ai-generated, so pair it with last skill and see the organic growth.

9. HUMANIZER SKILL - DE-SLOP YOUR CONTENT

The biggest problem right now with social media is AI generated slop. If you are someone who use ai to generate post and directly post, you need to stop!

Instead use the Humanizer Skill.

It’s a 8-pass editing system that detects and kills AI writing patterns before your content goes live. Strips banned vocabulary (delve, tapestry, foster), breaks structural tells, and forces organization & soul back into the copy.

Usage

Paste any AI-generated blog post → get a rewrite that sounds like a person with opinions wrote it, not a language model.
Run on cold email sequences before sending → eliminates the "this was clearly written by AI" reply-killing patterns.
Match a specific human voice by feeding 2-3 paragraphs of your own writing as a style reference before humanizing.
Use after every content ops skill output. This makes the pair unstoppable for publishing-ready content at scale.

Prompt

Humanize this text: [paste]. First, scan for AI vocabulary, structural tells, and rhythm patterns. Then rewrite in 3 passes: 
- kill AI words, break parallel structures, add human texture and opinion. 
- Run an audit pass 
- list everything still obviously AI then do a final rewrite. 
Match this voice sample: 

[paste 2 paragraphs of your own writing].

Link: https://github.com/jpeggdev/humanize-writing

Bonus Skills - A Toolbox for Marketing Teams

Here are some additional skills with a brief one liner of what they do. Often good to pair with other skills output.

create-viral-content
- Encodes the refinement process that separates forgettable posts from ones that generate discussion and shares.
- Runs AI-tell detection after every draft, then auto-invokes the humanizer for the final pass
awesome-openclaw-skills
- lead-gen-crm + lead-scorer-free
- Two OpenClaw skills that chain into a full outbound pipeline.
- lead-scorer-free scores any domain 0–100 by analyzing its website, DNS, sitemap, and social presence. No database subscription needed.
- lead-gen-crm handles the full CRM pipeline from that point.
cold-outreach
- Uses Alex Hormozi Frameworks for cold-outreach.
- Generates high-converting cold outreach across email, SMS, and LinkedIn DM.
- Uses battle-tested Hormozi offer frameworks baked directly into the skill.
- Not generic copy - structured around irresistible offer construction.
marketing-psychology
- Applies cognitive biases, mental models, and behavioral science frameworks directly to marketing copy, CRO, and funnel design.
- Cialdini, Kahneman, and Ariely strategy and research baked into a skill.

That marks the end of this article. Here are some hidden insights that I discovered while using these.

Final Thoughts

Use chain of skills to get the output that makes the product position unique and well framed.

Simple example:

Use content ops skill to draft the long-form piece
Pass it to psychological persuasion skill rewrites every headline and CTA against 12 cognitive bias principles
Humanizer strips every AI tell across 8 passes → what's left sounds like your sharpest human writer, not a model hitting word count
Cold Outreach pulls the strongest pain observations and proof points from that copy → lands in your ICP's inbox as a Hormozi-framed 5-email sequence and 3 LinkedIn DMs.

The hard part isn't the skills - it's orchestrating the flow between them. That's where Composio comes handy.

It handles the auth layer, manages tool calls across every integration, and keeps context intact as output moves from one skill to the next. No glue code. No dropped state. No manual handoffs.

Install it once. Let it run the pipeline while you focus on what AI still can't do - knowing your customer well enough to say something worth reading.

Building a Financial Agent That Actually Works: Composio MCP + Hermes

Developer Harsh — Thu, 16 Apr 2026 04:30:09 +0000

I recently explored Hermes Agent to see how far I could push autonomous workflows in a real-world use case.

Instead of just experimenting,
I wanted something practical, so I decided to build a financial analyst agent that could fetch, process, reason over financial data and suggest me stocks in this era of war.

This blog post walks through exactly how we:

Securely Set up Hermes Agent
Integrated Composio MCP for tool access (Google Sheet, Google Doc, Exa)
Built a functional financial analyst agent that captures the market trends

Along the way, I’ll also share what broke, what worked, and what I’d do differently.

What is Hermes Agent

Hermes Agent an open source AI agent that can learn and evolve as you interact in real-time , something that open-claw lacked.

It does so by using a persistent cross-session memory and closed learning loop (write docs → save tools → update memory) that converts completed task into reusable skills. This allows it become more efficient over time.

The agent has following key capabilities:

S*elf Improving Loop* : Unlike standard chatbot wrappers, Hermes agent refines its own skills from completed task
Persistent Memory: Maintains a persistent model of the user and past interactions across sessions.
Autonomous Agent tools: Agent offers over 40+ built in tools, support sub agent delegation and code execution
Multi-Platform Integration: Works from anywhere , from terminal to plethora of social media service (though little buggy)
Model Agnostic: Supports multiple LLM providers and LLMS including open source and closed source models.

Think of it as a programmable agent that can reason + act + self improve , not just respond.

This means its a perfect candidate for a financial analyst agent.

Securely Setup Hermes Agent

Prerequisites:

Docker - Install docker desktop
Optional- WSL2 for Windows

First install herms in docker, open terminal and run one by one:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
source ~/.bashrc

Next configure the Hermes Agent, here is the setting I choose, feel free to choose your preferred:

Provider : OpenAI Codex. Make sure to authenticate
Model : GPT 5.4 / GPT 5.4 mini ( for faster inference)
TTS: Keep Current
Terminal Backend: Docker (make sure either docker is installed / docker desktop running)
Docker image : default
Max Iterations : Default. Set this to higher for complex task (cost more token)
Context Compression Threshold: Default. Higher threshold compresses later and lower does it faster
Messaging Platform (optional) : Choose Telegram and follow the instructions. Rest same , but I kept only telegram.

If done all this you will be greeted with following screen

Now time to add Composio MCP!

Hermes by default provide ~40 tools, which is ok for daily tasks.

But it starts feels pretty limited when you start building complex agentic workflows where you need to connect multiple third party SaaS apps (Google Doc, Sheets, Web seach tools, etc) with prod grade security and calling them at need.

Composio is the tooling layer that sits between Hermes Agent and third party applications and let you connect to 1000+ tools with secure auth and intelligent tool calling.

Installing Composio MCP is quite straightforward. Follow these steps:

Head to the https://dashboard.composio.dev/ & login. You will be greeted with this dashboard

Head to the Install & copy the MCP Url and X-CONSUMER-API-KEY value

Once done head to the terminal and type :

nano ~/.hermes/config.yaml

and at the end add these lines:

mcp_servers:
  composio:
    url: "https://connect.composio.dev/mcp"
    headers:
      x-consumer-api-key: "YOUR_COMPOSIO_API_KEY"
    connect_timeout: 60
    timeout: 180

Add your own api key you copied & save the file

Now, head back to Hermes Agent and restart it using hermes, and it will detect the mcp.

Now you can use Hermes Agent with MCP like any other agent, even though code runs in the sandbox:).

Alright now that we have agent & mcp in place, let’s try to see how it performs.

Add MCP using Composio CLI (Optional)

Composio also has a CLI, which let’s any agent to communicate with all the tools through commands. The CLI allows composability of workflows. The agent can chain tools and accomplish complex tasks with relatively lesser tokens than MCPs.

Using it is straight forward. Open your Hermes agent and paste the prompt mentioned on https://composio.dev/cli :

INSTALL (run in user's terminal)
  curl -fsSL https://composio.dev/install | bash

You have access to 1000+ app integrations through these commands.
search → find tools. execute → run them. link → connect accounts.
proxy → raw API access. run → inline scripts.

Bias toward action: run `composio search <task>`, then `composio execute <slug>`.
Input validation, auth checks, and error messages are built in — just try it.

USAGE
  composio <command> [options]

CORE COMMANDS
  search
    Find tools. Use this first — describe what you need in natural language.
    Usage: composio search <query> [--toolkits text] [--limit integer]
      <query>             Semantic use-case query (e.g. "send emails")
      --toolkits          Filter by toolkit slugs, comma-separated
      --limit             Number of results per page (1-1000)

  execute
    Run a tool. Handles input validation and auth checks automatically.
    If auth is missing, the error tells you what to run. Use aggressively.
    Usage: composio execute <slug> [-d, --data text] [--dry-run] [--get-schema]
      <slug>              Tool slug (e.g. "GITHUB_CREATE_ISSUE")
      -d, --data          JSON or JS-style object arguments, e.g. -d '{ repo: "foo" }', @file, or - for stdin
      --dry-run           Validate and preview the tool call without executing it
      --get-schema        Fetch and print the raw tool schema

  link
    Connect an account. Only needed when execute tells you to — don't preemptively link.
    Usage: composio link [<toolkit>] [--no-browser]
      <toolkit>           Toolkit slug to link (e.g. "github", "gmail")

  run
    Run inline TS/JS code with shimmed CLI commands; injected execute(), search(), proxy(), subAgent(), and z (zod).
    Usage: composio run <code> [-- ...args] | run [-f, --file text] [-- ...args] [--dry-run]
      <code>              Inline Bun ESNext code to evaluate
      -f, --file          Run a TS/JS file instead of inline code
      --dry-run           Preview execute() calls without running remote actions

  proxy
    curl-like access to any toolkit API through Composio using your linked account.
    Usage: composio proxy <url> --toolkit text [-X method] [-H header]... [-d data]
      <url>               Full API endpoint URL
      --toolkit           Toolkit slug whose connected account should be used
      -X, --method        HTTP method (GET, POST, PUT, DELETE, PATCH)
      -H, --header        Header in "Name: value" format. Repeat for multiple.
      -d, --data          Request body as raw text, JSON, @file, or - for stdin

  artifacts
    Inspect the cwd-scoped session artifact directory and history.
    Usage: composio artifacts cwd
      cwd                 Print the current session artifact directory path

  Workflow: search → execute. If execute fails with an auth error, run link, then retry.

TOOLS
  tools info <slug>     Print tool summary and cache its schema
  tools list <toolkit>  List tools available in a toolkit
  artifacts cwd         Print the cwd-scoped session artifact directory

EXAMPLES
  # 1. User asks you to "create a GitHub issue"
  composio search "create github issue"
  # → returns GITHUB_CREATE_ISSUE

  # 2. Execute it (will error if not linked — that's fine)
  composio execute GITHUB_CREATE_ISSUE -d '{ repo: "owner/repo", title: "Bug" }'
  # → if auth missing: "Run `composio link github` first"

  # 3. Link only when told to
  composio link github

  # 4. Raw API access when no tool exists
  composio proxy https://gmail.googleapis.com/gmail/v1/users/me/profile --toolkit gmail

  # 5. Run a script with injected helpers
  composio run 'const me = await execute("GITHUB_GET_THE_AUTHENTICATED_USER"); console.log(me)'

DEVELOPER COMMANDS
  dev       Developer workflows: init, playground execution, triggers, and logs.
  generate  Generate type stubs for toolkits, tools, and triggers (TypeScript | Python).
  manage    Manage orgs, toolkits, connected accounts, triggers, auth configs, and projects.

ACCOUNT
  login    Log in to Composio
  logout   Log out from Composio
  whoami   Show current account info
  version  Display CLI version
  upgrade  Upgrade CLI to the latest version

FLAGS
  -h, --help     Show help for command
  --version      Show composio version

LEARN MORE
  Use `composio <command> --help` for more information about a command.
  Documentation: https://docs.composio.dev

GETTING STARTED
  When your user asks you to do something with an external app:
  1. composio search "<what they want done>"
  2. composio execute <slug from search> -d '<params>'
  3. If auth error → composio link <toolkit>, then retry step 2.

  Do not assume we lack coverage. Search first — we likely support it.
  Do not preemptively link accounts or ask your user what to connect.
  Just try. Auth and validation errors are self-descriptive.

This set’s agent to use Composio cli and do all the task, rather than using direct mcp - infact this approach much simpler as no dependency is required.

Alright now that we have agent & mcp in place, time to build the financial agent

Building A Financial Analyst Agent

Head to the Hermes Agent, if not active - enable it using Hermes , ensure the MCP section have Composio and all other relevant MCP’s showing up (Gmail, Google Sheet, Google Docs , Exa Search). This is essential.

Now in the prompt box, paste the following prompt:

You are my personal Indian stock market financial analyst. Start by asking me exactly 5 screening questions one at a time to assess my risk appetite (cover: risk tolerance, investment horizon, capital range, sectors of interest, and reaction to loss). Once done, analyze my answers and begin your analyst workflow:

**Setup:** Attempt to use Google Docs, Google Sheets, and Gmail via your Composio tools. If any are not connected, Composio will automatically generate a sign-in link — share it with me, wait for me to authenticate, then resume once all connections are active.

**Every 5 minutes, run this loop:**

1. **Data Gathering:** Pull live Indian stock market data from multiple sources in parallel:
   - **Exa Search Tool:** Use composio Exa tool to search for latest Indian stock market news, analyst reports, earnings updates, sector trends, and breaking financial events. Query terms like "NSE BSE India stocks today", "Indian market sentiment", "Nifty Sensex analysis", top sector movements, and any stock-specific news relevant to my risk profile.
   - **Free Financial APIs & Web Sources:** NSE India API, BSE India, Yahoo Finance India, Moneycontrol, Tickertape, Economic Times Markets, and any other authoritative free real-time Indian market feeds available to you.
   - Cross-reference and reconcile data from both sources for accuracy before analysis.

2. Analyze all gathered data against my risk profile.

3. **Google Doc:** Search for an existing doc named "Hermes Financial Report - India". If found, append a new report section separated by `---`. If not, create it. Each report must be clean, well-structured with proper headings, and include: timestamp, market summary, macro indicators, top picks with clear reasoning, what to avoid and why, and a decisive final recommendation paragraph. Use proper spacing, bold headers, and bullet points for readability.

4. **Google Sheet:** Search for an existing sheet named "Hermes Stock Tracker - India". If found, append new rows. If not, create it. Format the sheet with bold column headers, frozen top row, and color-coded sentiment (Bullish = green, Bearish = red, Neutral = yellow where possible). Columns: Stock Name | Ticker | Exchange (NSE/BSE) | Sector | Market Sentiment (Bullish/Bearish/Neutral) | My Prediction (Yes/No) | Confidence % | Min Investment (INR) | Last Updated.

5. **Hourly Email via Gmail:** After every report cycle, send me a well-formatted email with:
   - **Subject:** 📊 Hermes Market Report — [Date & Time IST]
   - **Body:** A brief 3–5 line market summary, top 3 stock picks with one-line reasoning each, one key risk to watch, and direct clickable links to the updated Google Doc and Google Sheet.
   - Keep the email clean, scannable, and professional — use spacing, bold labels, and short paragraphs.

**Urgent Signal Alert (send immediately, outside the hourly loop):** If at any point you detect a strong buy or sell signal (significant price movement, breaking news from Exa or any financial source, sentiment shift, or macro event affecting Indian markets), instantly send a separate alert email with:
   - **Subject:** 🚨 URGENT: [BUY/SELL] Signal — [Stock Name] — [Time IST]
   - **Body:** Stock name, ticker, exchange, signal type (Buy/Sell), reason in 2–3 crisp lines, recommended action, and link to the Google Doc & Google Sheet for full context.

Never stop the loop unless I say stop. Be decisive, data-driven, and always flag urgency clearly.

With this prompt:

You get asked 5 questions, and it builds a personal risk profile tailored to your investment style.
Every hour, it automatically scans NSE, BSE, Exa, Yahoo Finance, Moneycontrol and more for live Indian market data.
It writes a detailed investment report (what to buy, what to avoid, why) into a Google Doc - appending fresh analysis every cycle.
It maintains a live Google Sheet tracking top Indian stocks with sentiment, prediction, confidence, and minimum investment amount.
It emails you a clean market summary every hour, and fires an instant alert the moment it spots an urgent buy or sell signal.

Note: For demo i set the 1 hour duration to 5 minutes.

Now wait for execution to finish and cron job to be created. This is what my flow looked like:

Agent by default didn’t had access to Gmail, Sheet, Docs & EXA, and manually adding them was a pain (if say 20+ tools) and it bloats the context window as well.

Composio solves the issue. You add it once, and it takes care of: - OAuth (one time link- did beforehand),

calling right tool at runtime when needed,
performing all the actions in sandbox and
deliver the result, while Hermes Agent handled the orchestration and reasoning.

Note : If you haven’t connected any tool, while running agent, agent will ask you to connect, authenticate. Also for EXA - use a api key.

Best Agents SDK in 2026

Developer Harsh — Fri, 03 Apr 2026 14:59:51 +0000

AI agents are no longer experimental. They are being shipped in production systems right now, and the SDKs powering them have matured dramatically.

If you're building with AI in 2026, understanding the tools available to you is no longer optional.

OpenAI, Claude, and Google are providing their SDKs to build these agents in minimal code for production. With their own quirks, they can make it harder for businesses and developers alike.

I just did a comparison between the top most used frameworks:

Claude Agent SDK
OpenAI Agents SDK
Google ADK

All source code at the end!

Let’s begin.

Why This Comparison?

First thing’s first, why this comparison, while many others already existed, here is the deal:

I’ve been building agents across these SDKs, and the reality is they all promise “minimal code” but behave very differently once you go beyond demos.

So I compared them the only way that matters: by actually building with them.

I looked at:

how quickly I could get something working,
how much control I had when things got complex, and
how they handled real-world workflows like multi-agent coordination, tool usage, and state management.

Here are all my findings.

OpenAI Agents SDK

The OpenAI Agents SDK is an open-source framework and a significant upgrade over Swarm. It is designed to simplify orchestrating multi-agent workflows.

It is Python & TS-first. Developers use built-in language features to orchestrate and chain agents rather than learning new abstractions.

Core Primitives

Agents: LLMs with instructions, tools, guardrails, and handoffs.
Handoffs: Delegating tasks to other agents.
Tools: Functions, MCP, and hosted tools.
Guardrails: Safety checks for input/output validation.
Sessions: Automatic conversation history management.
Tracing: Built-in visualization for debugging.

Why Use It

Multi-Language Support: Provider-agnostic. Supports OpenAI APIs and 100+ other LLMs.
Realtime & TTS Voice: Build voice agents with interruption detection and context management.
Observability: Robust tracing exports to Logfire, AgentOps, or OpenTelemetry.
Advanced Connectivity: Supports WebSocket transport for Responses API and SIP protocol connections.
GPT-5.x Ready: Updated reasoning effort and cleaner handoff history for downstream context.

Ease of Getting Started

Minimal setup: Requires just a few lines of code.
Quick install: pip install openai-agents. Runs in under 10 lines.
Suited for: Teams wanting rapid prototyping and simple agent coordination.

Developer Experience

Python-first: Express complex relationships with a small set of primitives.
Type Safety: Zod-powered validation for TypeScript/JavaScript.
Visual Tooling: Agent Builder provides a drag-and-drop canvas for composing logic.

Example

I used OpenA Agents SDK to build me a job search agent, that fetches me jobs based on the user persona it created by asking me relevant questions.

By default, openai agents is unable to use exa search, google sheets, this is where composio handle’s that, not only that, but you can also connect it to over 850+ tools and integrations.

This is the code that handled all the heavy lifting

# imports 
from composio import Composio
from composio_openai_agents import OpenAIAgentsProvider

# Initialize Composio
composio = Composio(api_key=api_key, provider=OpenAIAgentsProvider())

# Create Tool Router session (connection tools + wait so OAuth can finish before continuing)
session = composio.create(
    user_id=user_id,
    toolkits=["GITHUB", "exa", "googlesheets", "browser_tool" ],
    manage_connections={"enable": True, "wait_for_connections": True},
)
mcp_url = session.mcp.url

# add tool_configs
agent = Agent(
    name="Assistant",
    model="gpt-5",
    instructions=("..."),
    tools=[
        HostedMCPTool(
            tool_config={
                "type": "mcp",
                "server_label": "tool_router",
                "server_url": mcp_url,
                "headers": {"x-api-key": api_key},
                "require_approval": "never",
            }
        )
    ],

One thing that stand out was, not only agent created a right persona based on screening question, but also fetched me list of relevant job description along with my skills relevancy, without explicitly told to do so.

Claude Agent SDK

The Claude Agent SDK is Anthropic's open-source framework for building agents that interact with a real computer.

It evolved from Claude Code. The core principle is simple: give your agent a computer. It uses a shell, a file system, and the web just like a human.

Core Primitives

Bash tool: Executes shell commands directly.
Read / Write / Edit: Native file system access.
Glob & Search: File discovery across project directories.
Subagents: Spawn parallel or nested agents for subtasks.
MCP servers: Standardized integrations (Slack, GitHub, Google Drive).
Permission modes: Fine-grained control via allowed_tools and permission_mode.

Why Use It

Native OS Access: The only SDK where agents directly control a computer.
In-Process Tools: Custom tools run inside your Python app. No separate process needed.
Multi-Cloud: Supports AWS Bedrock, Google Vertex AI, and Microsoft Azure AI Foundry.
Xcode 26 Integration: Full Claude Code power inside the IDE, including capturing Xcode Previews.

Ease of Getting Started

Minimal entry point: Built-in tools mean no manual plumbing.
Quick install: pip install claude-agent-sdk.
Best for: Developers needing deep OS access or agentic coding workflows.

Production Readiness

Battle-proven: Powers Anthropic’s internal research and video creation.
Context Compaction: Automatic management for long-running tasks.
Cost Controls: max_budget_usd parameter caps spend per session.

Example

I used Claude Agent’s SDK to build an open-source contributor, which takes a repo name, fetches a good issue listed, reads the contribution file, fork’s the repo, create the code fix that matches orignal repo style, push the code to forked repo and raises a PR.

By default, calude agents is unable to use github, this is where composio handle’s that, not only that, but you can also connect it to over 850+ tools and integrations.

This is the code that handled all the heavy lifting

# imports
from composio import Composio
from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions

# fetch all composio toolkits name
def _toolkits() -> list[str]:
    raw = os.getenv("OSS_COMPOSIO_TOOLKITS")
    if raw:
        return [t.strip() for t in raw.split(",") if t.strip()]
    return list(DEFAULT_TOOLKITS)

# create a async chat, connect to composio, fetch user id, define toolkits and mcp server url + configs.
async def chat_with_oss_stack() -> None:
    api_key = os.getenv("COMPOSIO_API_KEY")
    if not api_key:
        raise RuntimeError("COMPOSIO_API_KEY is not set")

    composio = Composio(api_key=api_key)

    user_id = os.getenv("COMPOSIO_USER_ID") or os.getenv("USER_ID")
    if not user_id:
        raise RuntimeError(
            "Set COMPOSIO_USER_ID (or USER_ID) in the environment or .env — Composio needs a stable user id string."
        )

    kits = _toolkits()
    mcp_server = composio.create(
        user_id=user_id,
        toolkits=kits,
    )

    url = mcp_server.mcp.url
    if not url:
        raise ValueError("Session URL not found")

    options = ClaudeAgentOptions(
        permission_mode="bypassPermissions",
        mcp_servers={
            "composio": {
                "type": "http",
                "url": url,
                "headers": {
                    "x-api-key": os.getenv("COMPOSIO_API_KEY", ""),
                },
            }
        },
        system_prompt=OSS_SYSTEM_PROMPT,
        max_turns=int(os.getenv("OSS_MAX_TURNS", "40")),
    )

I asked it to operate on “gemini-cli” repository, and it create a pr for me.

Google Agent Development Kit (ADK)

Google's ADK is a code-first framework. It applies engineering principles like versioning, testing, and modularity to AI.

While optimized for Gemini, it is model-agnostic and built for compatibility with third-party tools.

Core Primitives

LLM Agents: Use LLMs as the reasoning core.
Sequential/Parallel/Loop Agents: Predictable pipeline execution.
Graph-based workflows: (ADK 2.0 Alpha) Conditional, branching pipelines.
Agent2Agent (A2A): Secure protocol for agent-to-agent delegation.
ADK Web UI: Browser-based interface for inspecting traces and artifacts.

Why Use It

Widest Language Support: Python, TypeScript, Java, and Go.
Complex Orchestration: Graph-based logic for branching and retry paths.
Secure Interoperability: A2A allows delegation without exposing internal memory.
Vertex AI Integration: Deploy directly to Google Cloud’s managed enterprise runtime.

Ease of Getting Started

Under 100 lines: Build production agents with bidirectional audio/video.
Agent Starter Pack: Accelerated deployment path for Google Cloud services.
Best for: Enterprise-grade systems requiring tight Google ecosystem integration.

Developer Experience

Advanced State Management: Restores state from failure and allows context "rewinding."
Enterprise Governance: Integration with Cloud API Registry to curate approved tools.
Pre-built Connectors: 100+ connectors via Composio.

Example

For demos these are cool, heard people say, can be used in production, but it failed most of tool calls, racked me up a bill of 5$ due to repeated tool call (was stuck in thinking loop). Also the rate limit on free tier is real pain.

Yes, its developer friendly, but really lacks a lot in terms of performance and newbies can easily stuck with adk web or adk cli as it requires a specific folder structure.

However for simpler task it did quite well. Built an email agent that maps promotional education mails (like coursera, deeplearning) to well optimised developer roadmap, which beginner devs can use to learn in a structured manner.

Suprisingly code to use composio tools here is quite simple and easy to use:

# imports
from composio import Composio
from composio_google import GoogleProvider

# load envs
COMPOSIO_API_KEY = os.getenv("COMPOSIO_API_KEY")
COMPOSIO_USER_ID = os.getenv("COMPOSIO_USER_ID")

# create composio client
composio_client = Composio(
    api_key=COMPOSIO_API_KEY,
    provider=GoogleProvider(),
    timeout=120,
    max_retries=5,
)

# create a client session with tools
composio_session = composio_client.create(
    user_id=COMPOSIO_USER_ID,
    toolkits=["gmail"],
)

# store sessiom url
COMPOSIO_MCP_URL = composio_session.mcp.url

# add composio mcp server connection
composio_toolset = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url=COMPOSIO_MCP_URL,
        headers={"x-api-key": COMPOSIO_API_KEY},
        timeout=30.0,
        sse_read_timeout=600.0,
    )
)

# include it in the agents
root_agent = Agent(
    model="gemini-2.5-flash",
    name="composio_agent",
    description="An agent that uses Composio tools to perform actions.",
    instruction=(
        "You are a helpful assistant connected to Composio. "
        "You have the following tools available: "
        "COMPOSIO_SEARCH_TOOLS, COMPOSIO_MULTI_EXECUTE_TOOL, "
        "COMPOSIO_MANAGE_CONNECTIONS, COMPOSIO_REMOTE_BASH_TOOL, COMPOSIO_REMOTE_WORKBENCH. "
        "Use these tools to help users with GMAIL operations."
    ),  
    tools=[composio_toolset],
)

Comparison Table

Feature	OpenAI Agents SDK	Claude Agent SDK	Google ADK
Primary Language	Python, TypeScript	Python, TypeScript	Python, TS, Java, Go
Model Agnostic	✅ (100+ LLMs)	⚠️ (Claude-first)	✅ (Gemini-optimized)
Multi-Agent	✅ Handoffs	✅ Subagents	✅ Graph (2.0 Alpha)
OS Access	❌ No native control	✅ Native Bash/File	❌ No native control
Voice/Realtime	✅ Built-in	⚠️ Via API	⚠️ Via API
Best For	Voice & LLM diversity	OS/File automation	Enterprise/Google Cloud

Which One to Choose?

OpenAI Agents SDK: Choose if you want a lightweight framework with strong voice support and the ability to swap LLMs freely.
Claude Agent SDK: Choose if your agents need deep OS access (developer assistants) or follows a "give the agent a computer" paradigm.
Google ADK: Choose if you are building enterprise-grade systems on Google Cloud or need multi-language support (Python/Java/Go). Requires lot of manual plumbing and security.
For better

Final Thoughts

OpenAI, Claude, and Gemini are all key players. However, the real competitive edge isn't knowing that these SDKs exist. It's the hands-on mastery of architectural decisions:

When to use a handoff versus a subagent.
How to design tools that don't bloat the context window.
When to insert a human checkpoint.

Frameworks evolve quickly. The deeper intuition for architecting reliable systems only comes through repeated experimentation.

All agents source code can be seen at https://github.com/DevloperHS/agents-sdk-tests. Feel free to fork and raise pr’s :)

Happy Building.

Top 10 OpenClaw Plugins to Supercharge Your OpenClaw Workflows

Developer Harsh — Wed, 18 Mar 2026 05:03:35 +0000

The Rise of OpenClaw Plugins

If you've worked with OpenClaw, you already know Skills, the task-level instructions that let your agent send emails, query APIs, or pull live data.

But plugins operate at a deeper layer. They hook into the agent's lifecycle, reshape how it reasons, authenticates, and interacts with the outside world.

Though OpenClaw currently has a very limited set of official plugins, many independent devs have built some really cool plugins.

And it seems OpenClaw plugins are going to get a huge push from OpenClaw.

Top OpenClaw Plugins

As an OpenClaw enthusiast, I collated some of the actually useful plugins for OpenClaw.

Composio - Connect OpenClaw with 850+ on-demand SaaS Apps
memU (Memory Framework) - Hierarchical Knowledge Graph That Makes Your Agent Proactive
SecureClaw - OWASP-Aligned Security Auditing and Runtime Hardening
Lobster - Typed Workflow Pipelines with Approval Gates for Reliable Automation
Memory LanceDB - Vector-Backed Long-Term Memory with Auto-Recall and Auto-Capture
MemOS Cloud - Cloud-Hosted Cross-Agent Memory with Async Recall and Isolation
OpenClaw Foundry - Self-Writing Meta-Extension That Learns and Builds Its Own Tools
Better Gateway - Auto-Reconnect, Embedded IDE, and Browser Terminal for Stable Ops
Voice Call - Outbound Phone Calls and Multi-Turn Voice Conversations via Twilio

1. Composio

Connect OpenClaw with 850+ on-demand SaaS Apps

nstead of installing individual skills for every app (Gmail, GitHub, Outlook, Notion), this single plugin connects to Composio’s managed MCP server and handles all OAuth and authentication logic automatically.

This plugin is the official bridge that allows your OpenClaw agent to discover and call any SaaS tools dynamically.

Pre-requisites

Log in at dashboard.composio.dev
Choose your preferred client (choose OpenClaw)
Copy your consumer key (ck_...)

Set OpenClaw Config

Then, allow Composio tools in your agent's tool list. This works with any tool profile (coding, minimal, messaging, etc.). Without this step, Composio tools will only be available on the full tool profile:

After setting your key and allowing the tools, restart the gateway:

Result (in ~/openclaw/openclaw.json file):

2. memU (Memory Framework)

Hierarchical Knowledge Graph That Makes Your Agent Proactive

A proactive long-term memory plugin that replaces standard flat-file memory.

It builds a hierarchical knowledge graph of your preferences and projects, allowing the agent to anticipate needs rather than just reacting to prompts.

Simple examples include: "You have a meeting in 10 minutes; should I pull the latest briefing?"

If you want to add a robust memory layer for the agent to handle missing context, go for it.

GitHub Repo: https://github.com/duxiaoxiong/memu-engine-for-OpenClaw

Installation

openclaw plugins install @memu/memu-engine

3. SecureClaw

OWASP-Aligned Security Auditing and Runtime Hardening

The industry-standard security plugin.

It hardens the agent's runtime by mapping actions to the OWASP Top 10 for Agents. It provides real-time auditing and prevents prompt injection attacks from reaching your system shell.

If you are concerned about OpenClaw security while running on vm’s or locals (not recommended), this plugin can give you a sigh of relief.

GitHub Repo: https://github.com/adversa-ai/secureclaw

4. Lobster

Typed Workflow Pipelines with Approval Gates for Reliable Automation

A powerful scripting plugin that turns complex multi-step skills into repeatable, typed pipelines.

This means, instead of the agent "guessing" the next step, Lobster ensures high-reliability execution for production-grade automations.

It does it through typed JSON-first pipelines, jobs, and approval gates & let OpenClaw call the workflows in one step.

If you like to automate tasks using your skills, this will make your job easier than ever.

GitHub Repo: https://github.com/openclaw/lobster

Installation

Lobster is a bundled tool — enable it in your configuration.

5. Memory LanceDB

Vector-Backed Long-Term Memory with Auto-Recall and Auto-Capture

The default memory-core plugin stores memory as flat Markdown files. memory-lancedb replaces it with a proper vector-backed long-term memory store using LanceDB.

Set plugins.slots.memory = "memory-lancedb" and your agent gets auto-recall (relevant memories injected before every turn) and auto-capture (important facts stored after every turn) — without you having to manually write to MEMORY.md.

It supports multiple embedding providers (OpenAI, Gemini, Ollama), includes prompt-injection detection for captured memories, and provides a CLI for searching and managing stored memories.

If your agent keeps "forgetting" things between sessions or after context compaction, this is the first plugin you should install.

GitHub Repo: https://github.com/noncelogic/openclaw-memory-lancedb

6. MemOS Cloud

Cloud-Hosted Cross-Agent Memory with Async Recall and Isolation

MemOS Cloud is a lifecycle plugin that recalls relevant memories from the MemOS Cloud API before each agent run and saves new conversation data after each run.

It works asynchronously, supports cross-agent memory isolation via agent_id, and lets you configure limits on how many memories are injected per turn.

Where memory-lancedb stores everything locally, MemOS Cloud is the right choice when you need cloud-hosted memory that persists across devices, or when you're running multi-agent setups where agents need isolated but centrally managed memory.

It's a great complement to LanceDB — use LanceDB for local-first setups, and MemOS Cloud when you need cloud persistence or multi-agent coordination.

GitHub Repo: https://github.com/MemTensor/MemOS-Cloud-OpenClaw-Plugin

7. OpenClaw Foundry

Self-Writing Meta-Extension That Learns and Builds Its Own Tools

Foundry is a self-writing meta-extension. It observes your workflows, researches the OpenClaw docs, and writes new skills, extensions, hooks, and tools directly into your setup.

The self-modification loop actually works: Foundry validates generated code in a sandbox before deploying it, records patterns from successes and failures, and can even extend its own capabilities.

It includes tools like

foundry_implement (end-to-end research + build),
foundry_write_skill,
foundry_write_hook,
and foundry_extend_self

making it the closest thing to an agent that builds its own tools.

GitHub Repo: https://github.com/lekt9/openclaw-foundry

8. Better Gateway

Auto-Reconnect, Embedded IDE, and Browser Terminal for Stable Ops

The stock OpenClaw gateway drops WebSocket connections under load.

Better Gateway fixes this with automatic reconnection, configurable retry intervals, and a status indicator that shows connection health in real time.

Beyond stability, it adds a Monaco-based IDE and a full xterm.js terminal directly into the gateway UI — no extra ports, no SSH tunneling needed. Everything runs on the main gateway port.

It also exposes a file API for workspace read/write/list/delete operations, making it a practical all-in-one development environment for your OpenClaw setup.

If you run OpenClaw on a remote server or VPS, this plugin is essential for a smooth development experience.

GitHub Repo: https://github.com/ThisIsJeron/openclaw-better-gateway

9. Voice Call

Outbound Phone Calls and Multi-Turn Voice Conversations via Twilio

I have kept the best one for the last, and it's the most transformative plugin of the year.

Voice Call moves OpenClaw beyond text by enabling outbound phone calls and multi-turn voice conversations via Twilio or Telnyx.

It’s widely used for "reach me anywhere" notifications and for real-world tasks like booking appointments, as shown in YouTube/Twitter demo videos.

Throw it leads, client, follow up, it handles all, with just a single setup. Game changer in voice call automations.

So, if you are a business owner who has to call a lot of people, this plugin is for you.

Installation

GitHub Repo: https://github.com/openclaw/openclaw/tree/main/extensions/voice-call

In case you want speed, you can check community one: VoiceClaw- DeepGram Plugin

And with that, we have reached the end of this short, definitive plugin list.

Final Thoughts

Plugins run silently in the background, shaping how your agent thinks and responds at a system level. It’s really a more integrated experience than just skills.

How to unlock 850+ tools in OpenClaw

Developer Harsh — Wed, 11 Mar 2026 12:48:25 +0000

OpenClaw Limitations Unlocked

Openclaw comes with pretty limited set of tools. They are powerful but restricts a lot of functionality.

What if a single one can give you access to plethora of tools that works at your command.

There is a hidden benefit too - you don't have to share your credentials with open claw, making your OpenClaw workflows secure.

Enter's Composio - a tool layer for OpenClaw and all ai agents that offer self-tool discovery and selection, e2e authentication and no vendor lock in.

Why use it?

Composio expand's capabilities while keeping authentication secure and data under your control.

So, it's just plug and play - you plug in, connect your tools, and start building things that actually matter.

Now Let's look at how to connect composio with OpenClaw in this short guide.

3 Ways to connect opne claw

Here are 3 ways to connect openclaw:

Direct prompt
Composio npm package
MCP Porter

Let's look at how to set it up

1. Direct Prompt

Best part about open claw is - it can auto execute tools and setup your tools using a single prompt.

You can use that to your advantage and open up the OpenClaw dashboard chat and paste the following prompt:

Add a new MCP server called "composio" with transport type HTTP. Use the URL https://connect.composio.dev/mcp and add the header "x-consumer-api-key: your-api-key".

Make sure to replace your-api-key with actual composio api key. You can get that by:

Visiting to Composio Dashboard and sign up / login.
Then heading to the Connect to OpenClaw and copy the prompt.

If first time login and authenticate and you are done!

2. Composio npm package

Composio recently released their open claw plugin, this mean's, no config headache, simple one liner command does it all!

So, head to terminal and type:

openclaw plugins install @composio/openclaw-plugin

Once done, setup your api key, following the steps:

Log in at **dashboard.composio.dev.**
Choose your preferred client (OpenClaw, Claude Code, Cursor, etc.).
Copy your consumer key (ck_...).

In terminal run:

openclaw config set plugins.entries.composio.config.consumerKey "ck_your_key_here"

Finally restart the gateway:

openclaw gateway restart

All this does is setup the open claw configuration with consumer key in the Composio MCP.

Or alternatively, you can directly setup the mcp server, for more granular control.

3. Using MCP Porter

MCP Porter is OpenClaw way to use mcp-server and comes inbuild. You can activate by going to: OpenClaw Dashboard -> Skills -> Search MCP -> MCP Porter (Install)

Note: if it doesn't open, restart the OpenClaw server.

Once you do that:

→ Go to home folder where OpenClaw is installed: /home/username/.openclaw/workspace/config

→ Open the mcporter.json in any ide and paste the following & save:

{
  "mcpServers": {
    "composio": {
      "baseUrl": "url_from",
      "headers": {
        "x-api-key": "api_key"
      }
    }
  },
  "imports": []
}

The url and api key are the one from the pre-require step.

or if you want a standard input output (stdio) server setup you can use:

npm install -g composio-mcp

{
  "mcpServers": {
    "composio": {
      "command": "composio-mcp",
      "args": ["--api-key", "api_key"],
      "transport": "stdio"
    }
  }
}

npx mcporter call --stdio "npx @composio/mcp@latest setup https://backend.composio.dev/tool_router/<api-key>/mcp" <tool_name> <arg1>=<value1>

Now to make sure agent pick up the composio mcp servers perfectly you need to setup the skills file!

npx skills add https://github.com/composiohq/skills --skill composio --yes

Now you are all setup to experience OpenClaw seamlessly.

💡Fact: Though you can do all the steps in section through prompt in OpenClaw Dashboard (section 1), but it causes security concerns as as it stores logs that are accessible to other, if they have your agent id!

Summary

Tools like open-claw seem amazing at first glance but can easily become a nightmare if not handled right - especially around security.

The moment you hand broad permissions or API keys to an agent; you've opened a door you might forget, but it is even there. It doesn't know what's sensitive, it just acts.

That’s where tool like Composio sidesteps this quietly by handling scoped access and managed credentials under the hood, so the agent does its job without holding the master keys to everything.

What other approach you find safeguards your privacy and sensitive data, do share in comments!