DEV Community: Muhammad Moeed

Claude Fable 5.2 vs Opus 5.5: which one should you actually use?

Muhammad Moeed — Thu, 12 Nov 2026 10:03:38 +0000

Anthropic released Claude Fable 5.2 on November 9, 2026. The first question everyone asks: should I switch from Claude Opus 5.5?

This is the short version. The full guide, with Claude Code setup and a longer FAQ, is on my blog: Claude Fable 5.2 vs Opus 5.5: Which One Should You Use?

Quick answer

Opus 5.5 for most work. Coding, bug fixes, writing, data analysis. $4 / $20 per million tokens.
Fable 5.2 for the hardest work. Large multi-file changes, long tasks the agent runs on its own, and bugs Opus keeps getting wrong. $8 / $40, exactly 2x Opus 5.5.
Anthropic's own launch post agrees: start with Opus 5.5 as your "daily driver" and keep Fable for "the most ambitious, open-ended technical work."

Side by side

	Fable 5.2	Opus 5.5
Model ID	`claude-fable-5-2`	`claude-opus-5-5`
Price (input / output)	$8 / $40	$4 / $20
Cache reads	$0.20	$0.20
Fast mode	$16 / $80	$8 / $40
Context / max output	1M / 128K	1M / 128K
Default effort in Claude Code	`medium`	`medium`

Same context window, same output limit, same cache read price. Fable is not "bigger". It is better at long, multi-step work.

Where Fable 5.2 wins

From Anthropic's own benchmark table (not independent tests yet):

FrontierSWE v2 (agentic coding): 69.9% vs 62.3%
Remote Labor Index (long knowledge work): 41.3% vs 21.3%
Terminal-Bench-Science 0.1: 74.6% vs 58.7%
OSWorld 2.1 (computer use): 89.3% vs 87.2%, a small gap
AA-Briefcase Elo: Opus 5.5 is actually ahead, 1800 vs 1785

The pattern is clear: the bigger and longer the task, the bigger Fable's lead.

What 2x means in dollars

One task with 500K input tokens (400K of it cached) and 50K output tokens:

Opus 5.5: $0.40 + $0.08 + $1.00 = $1.48
Fable 5.2: $0.80 + $0.08 + $2.00 = $2.88

Run 20 of those every working day for a month (440 tasks) and it is $651 vs $1,267. That gap is fine if Fable gets hard tasks right the first time. It is wasted money on routine work.

One more detail: Opus 5.5 in fast mode costs the same as Fable 5.2 at normal speed. If you want speed, Opus fast mode is the cheaper path.

A simple rule

Start on Opus 5.5 at the default effort.
If the result is weak, raise effort to high, then xhigh.
Still not good enough? Switch to Fable 5.2 for that one task.
Switch back when the hard part is done.

Switching in Claude Code

Fable 5.2 needs Claude Code 2.1.321 or later:

claude update

Then:

/model fable

Go back with /model opus. One tip: in the /model picker, Enter saves your choice as the default for every new session, while s switches for this session only. Use s for Fable so you do not stay on the expensive model by accident.

Two API gotchas

Thinking is always on. Sending thinking: {type: "disabled"} or budget_tokens returns a 400. Use effort instead. Opus 5.5 works the same way.
Forced tool choice is gone. tool_choice set to any or a named tool returns a 400. Use auto and say in your prompt which tool to use.

spawn npx ENOENT and 9 Other MCP Errors, Explained in Plain English

Muhammad Moeed — Fri, 18 Sep 2026 14:54:36 +0000

You added an MCP server to your config, restarted the app, and one of these happened:

Nothing showed up at all.
The server showed up and then died with MCP error -32000: Connection closed.
Every tool call hits Request timed out after 60 seconds.
You got spawn npx ENOENT and no idea what "ENOENT" even means.

I hit all four in one week. So I sat down with the Claude Code changelog, ~20 open anthropics/claude-code GitHub issues, the MCP debugging docs, and a bunch of Reddit and Stack Overflow threads, and wrote a plain-English fix guide.

Here is the short version.

The 4 things that fix 80% of MCP failures

Before you Google a specific error, try these:

Fully quit the client, then relaunch. Cmd+Q on macOS. On Windows right-click the tray icon and click Quit. Closing the window is not enough. Config only reloads on a cold start.
Run your config file through a JSON linter. A single missing comma, an unescaped Windows backslash, or the wrong top-level key silently breaks the whole file. No error dialog, no servers register.
Replace bare npx with an absolute path. On Mac/Linux run which npx and paste the full path (something like /Users/you/.nvm/versions/node/v22.14.0/bin/npx). On Windows use cmd /c npx or point directly at node.exe.
Check the logs. Mac: tail -F ~/Library/Logs/Claude/mcp*.log. Windows: %APPDATA%\Claude\logs\. Claude Code CLI: claude --debug=mcp then read ~/.claude/debug/<session-id>.txt.

The single most common MCP error

spawn npx ENOENT is the #1 setup failure. It shows up in 30+ MCP repos. Here is why it happens.

Your terminal shells (zsh, bash) source ~/.zshrc or ~/.bashrc on startup. That is where nvm adds its bin directory to your PATH. So npx works in your terminal.

GUI apps like Claude Desktop do NOT source those shell files. They launch with a minimal PATH (/usr/bin:/bin:/usr/sbin:/sbin) that excludes nvm, mise, fnm, and Homebrew. So npx is not on the client's PATH. The child_process.spawn call fails with ENOENT (Error NO ENTity, meaning "file does not exist").

Two ways to fix it. Either paste the absolute path from which npx as the command in your config, or add a per-server env block that gives the child process a working PATH. Full recipe (with Windows and NVM variants) is in the guide.

What is in the full guide

10 named errors with the exact copy-paste text you see and the fix steps for each:
- MCP error -32000: Connection closed
- MCP error -32001: Request timed out
- spawn npx ENOENT
- spawn EINVAL (Windows only)
- Server transport closed unexpectedly
- Could not attach to MCP server <NAME>
- -32601 Method not found
- -32602 Invalid params
- Failed to connect in claude mcp list
- OAuth 401 / authorization with MCP server failed
Per-platform gotchas for Claude Desktop on macOS and Windows (including the MSIX / Microsoft Store virtualized-path trap that opens the WRONG config file), Claude Code CLI, VS Code, Cursor, Node with NVM/mise/fnm, and corporate networks with proxies and OAuth.
7-step diagnostic checklist if your specific error is not in the catalog.
8 H3 FAQs matching the exact questions people paste into Google.

Read the full guide here: MCP Server Not Connecting? 10 Fixes That Actually Work.

If you have hit an MCP error not in the list, drop it in the comments and I will add it in the next update.

Claude Fable 5 is currently unavailable , here's what actually happened

Muhammad Moeed — Tue, 16 Jun 2026 11:12:02 +0000

Claude Fable 5 was live for three days.

It launched on June 9, 2026. By June 12 at 5:21 PM Eastern Time, it was off. And as of June 16, it is still off — for every user, everywhere in the world. Mythos 5 was turned off at the same time for the same reason.

If you have been getting a "currently unavailable" error, this is why.

The short version

The US Commerce Department, signed by Secretary Howard Lutnick, sent Anthropic an export-control order on June 12. The order requires Anthropic to block access to Fable 5 and Mythos 5 for any foreign national, including their own non-US employees.

Anthropic has no way to check, in real time, which user is from which country. So they did the only thing they could to comply — turn the models off for everyone. In their own words:

"We must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance."

What the government said was the problem

The order cited "national security authorities" and pointed at a method to "jailbreak" Fable 5. According to administration officials quoted by reporters, another company demonstrated the jailbreak to the government, and that "alarmed the administration about possible national security risks."

The jailbreak itself, as Anthropic describes it, "essentially consists of asking the model to read a specific codebase and fix any software flaws." In plain English — someone asked Claude to look at software code and find the security bugs in it.

Anthropic pushed back. They called the technique "narrow and non-universal" and pointed out that OpenAI's GPT-5.5 can do the same thing without needing any trick. Their position is that this should not require shutting down the entire model.

When is Fable 5 coming back?

Nobody has said. Anthropic says they "believe this is a misunderstanding" and are "working to restore access as soon as possible." As of June 16, there is no timeline.

If your code used claude-fable-5, switch to claude-opus-4-8 as the closest substitute. Sonnet 4.6 and Haiku 4.5 are cheaper alternatives that still work fine.

Full guide

I wrote a longer breakdown with the day-by-day timeline, a 5-step migration playbook, what to do if you built on Fable 5, and the open questions about when (or if) it comes back.

Read the full guide on moeed.app →

MCP Apps vs OpenAI Apps SDK: are they competing standards?

Muhammad Moeed — Thu, 11 Jun 2026 22:30:32 +0000

If you have started building tools for AI chat hosts, you have probably hit the same fork in the road. There are two ways to add a user interface to a tool right now. The first is MCP Apps, the open standard from the Model Context Protocol. The second is the OpenAI Apps SDK, the framework OpenAI shipped for the ChatGPT app store.

They both let your tool render a UI inside the chat. They both run inside a sandboxed iframe. They both talk to your server over JSON-RPC. So the question almost every developer is asking is the obvious one: are these competing standards?

The short answer

No. The OpenAI Apps SDK is built on top of MCP. It uses MCP for the wire format, the tool definitions, the UI rendering, and the security model. It then adds a thin layer with ChatGPT-specific extensions: a payment hook (window.openai.requestCheckout), a store directory, and a few helpers that only run inside ChatGPT.

So the choice is not "pick one or the other." The honest framing is:

Build to MCP Apps first. Your tool then works in Claude, Claude Desktop, VS Code, Goose, Postman, MCPJam, and any host that supports the open standard.
Light up OpenAI Apps SDK extensions only when you need ChatGPT-specific features. Mostly that means payments and the ChatGPT app store.

The four real differences

Strip away the marketing and there are only four things the OpenAI Apps SDK gives you that MCP Apps do not:

A store and a directory — the ChatGPT app store will list your app and surface it to ChatGPT users. The open MCP spec has no centralised discovery.
In-chat payments — window.openai.requestCheckout() runs a payment flow without leaving the chat. MCP Apps has no checkout primitive today.
Conversation-aware helpers — tighter access to surrounding conversation state.
Distribution to ChatGPT users specifically — ChatGPT has hundreds of millions of users; the Apps SDK is the only way to reach them through OpenAI's surface.

Everything else — the sandboxing, the iframe rendering, the JSON-RPC audit trail, the tool declarations — is the same on both sides because the Apps SDK uses MCP for them.

Which one to pick

If your audience is ChatGPT users specifically and you need in-chat payments, build with the OpenAI Apps SDK. For everyone else, build to MCP Apps and your tool runs across every host that supports the open standard.

I wrote the full comparison — code examples for both sides, the smart progressive-enhancement pattern, a decision tree, and the two pitfalls most teams hit — on my blog.

Read the full guide on moeed.app →

Claude Agent SDK Cost Tracking — what to do before June 15, 2026

Muhammad Moeed — Fri, 05 Jun 2026 11:40:55 +0000

On June 15, 2026 Anthropic moves Claude Agent SDK calls, claude -p, GitHub Actions, and third-party agents off the subscription pool and onto a separate dollar-denominated credit ($20 Pro, $100 Max 5x, $200 Max 20x), billed at
standard API list prices. Interactive Claude Code in the terminal stays where it is. Everything programmatic moves.

So the question your manager is going to ask the next day stops being "are we within the subscription limit?" and starts being "what did this cost?"

The full guide is on my blog: Claude Agent SDK Cost Tracking: A Practical Guide (2026). Here is the short version.

## What the SDK gives you

Every query() call ends with a result message carrying total_cost_usd and a usage object with token counts. There is also a per-model breakdown so you can see how much went to Opus versus Haiku in the same call. Same data in
TypeScript and Python, slightly different field names.

## The one warning

Anthropic is very direct in the official docs: total_cost_usd is a client-side estimate from a price table bundled at build time. It can drift from the real bill when:

pricing changes
the installed SDK does not recognise a model
billing rules apply that the client cannot model (the June 15 credit pool, enterprise discounts, surge pricing)

Use the SDK number for budgeting. Use the Usage and Cost API or the Console for invoicing.

## A minimum viable cost log

  from claude_agent_sdk import query, ResultMessage
  import asyncio

  async def main():
      async for message in query(prompt="Summarise this project"):
          if isinstance(message, ResultMessage):
              print(f"Estimated cost: ${message.total_cost_usd or 0:.4f}")

  asyncio.run(main())

Five lines is enough to start. Add a tag for user, model, and feature when you push it into production metrics.

## The duplicate-ID gotcha with parallel tools

When Claude uses multiple tools in parallel within one turn, the SDK emits several assistant messages that share the same id with identical usage. If you sum tokens across every assistant message, you triple- or quadruple-count.

Deduplicate by ID before you add:

  const seenIds = new Set<string>();
  let totalInputTokens = 0;

  for await (const message of query({ prompt: "..." })) {
    if (message.type === "assistant") {
      const msgId = message.message.id;
      if (!seenIds.has(msgId)) {
        seenIds.add(msgId);
        totalInputTokens += message.message.usage.input_tokens;
      }
    }
  }

Or just read total_cost_usd from the final result message and let the SDK handle deduplication for you.

## Where the 90 percent saving really comes from

Every agent loop reads the same system prompt and the same files on every turn. The SDK turns prompt caching on automatically. Two fields to watch:

cache_creation_input_tokens — billed at a higher rate, once per cache window
cache_read_input_tokens — billed at roughly 10 percent of standard input

After the first turn, the cache read field dominates and the bill flattens out. On a Sonnet 4.6 agent with a 15K-token system prompt and 20 turns, that drops per-turn input cost from roughly $0.045 to roughly $0.005.

## A simple sizing decision

With one week of measured total_cost_usd, you can size the plan in three lines:

  Estimated monthly = weekly_total_cost_usd * 4.33

    < $20      → Pro
    $20-$100   → Max 5x + usage credits on
    $100-$200  → Max 20x + usage credits on
    > $200     → Direct API key (or Bedrock / Vertex)

Two caveats:

Credits do not roll over. Under-spending is real waste, the same way over-spending is.
Bursty workloads (one monthly audit doing 80 percent of the spend in two days) often work out cheaper on direct API billing even if the totals look similar.

## What to do this week

Log total_cost_usd on every query() call, tagged with user, model, and feature.
Deduplicate assistant messages by ID before trusting per-step totals.
Plot cache_read vs cache_create. If reads are not dominant after turn one, your system prompt or files are changing too often.
Pull one week of Console data and compare to the SDK estimate.
Pick a plan tier. Claim your credit when Anthropic emails you. Enable usage credits for overflow.
Pin the SDK version in CI. Bumps silently change the bundled price table.

The full guide on my blog has the per-model breakdown code, cache TTL trade-offs, what changes after June 15 for total_cost_usd interpretation, and an FAQ: Claude Agent SDK Cost Tracking: A Practical Guide
(2026).

Claude Code slow or worse? How to diagnose and fix it in 2026

Muhammad Moeed — Sat, 23 May 2026 19:05:07 +0000

If Claude Code has felt slower or less capable this spring, you were not imagining it. Anthropic confirmed in an official post mortem on April 23, 2026 that three product changes stacked between March and April caused real, measurable quality drops. All three were reverted by April 20.

This is the short version. The full guide is on my blog: Claude Code Slow or Worse? How to Diagnose and Fix It (2026).

What actually happened

Change	Landed	Reverted
Reasoning effort dropped from high to medium	March 4	April 7
Cache eviction bug fired every turn	March 26	April 10 (fixed)
System prompt "25 words between tool calls"	April 16	April 20

All resolved in v2.1.116. Anthropic reset usage limits as an apology.

Three quick checks

1. Are you on the fixed build?

claude --version

Update if you are below v2.1.116. Fast mode now defaults to Opus 4.7 as of v2.1.142 (May 14).

2. Run `/doctor`

It catches about 80 percent of "Claude is broken" cases. Stale install, wrong API key, broken MCP server, outdated CLAUDE.md, silently failing hook. Fix anything yellow or red before blaming the model.

3. Check status

status.claude.com

If it is red, stop and come back later.

Six fixes for the rest

Start fresh sooner. Long sessions lose attention to context bloat. Run /compact every 30 to 45 minutes or restart.
Write a real CLAUDE.md. Project context that belongs in every session. Keep it under two pages.
Use /fast only when speed matters. Same intelligence as standard Opus 4.7, six times the cost.
Put quality constraints at the end of your prompt. Attention weight is higher there.
Shrink your MCP surface. Every connected server eats tokens before you type.
Full restart. Kill Claude Code, wait 10 to 15 minutes, start again.

The diagnostic tree

version >= 2.1.116?      no → update
/doctor clean?           no → fix it
status.claude.com clean? no → wait
session > 45 minutes?    yes → /compact or restart
> 3 MCP servers?         yes → disconnect what you do not use
still bad?               → restart, then file a GitHub issue

Most people stop at one of the middle steps.

The full guide covers what each platform change did, the cost trade off of fast mode, when to file a GitHub issue, and a longer FAQ: Claude Code Slow or Worse? How to Diagnose and Fix It (2026).

Claude Agent SDK vs Vercel AI SDK 6 — which to pick in 2026

Muhammad Moeed — Sat, 23 May 2026 19:02:11 +0000

Two libraries land on most shortlists when you start an agent project in 2026: Anthropic's Claude Agent SDK and Vercel AI SDK 6. Both build agents that use tools, stream, and speak MCP. They were built by teams with different beliefs.

This is the short version. The full guide is on my blog: Claude Agent SDK vs Vercel AI SDK 6: Which to Pick (2026).

The short version

Pick the Claude Agent SDK when your model is Claude and you want the same runtime that powers Claude Code, with caching, compaction, and built in tools on day one. Python and TypeScript.

Pick the Vercel AI SDK 6 when you need multi provider support, your stack is TypeScript and React or Next.js, or you want chat, tools, images, reranking, and speech in one library.

Side by side at a glance

Area	Claude Agent SDK	Vercel AI SDK 6
Languages	Python, TypeScript	TypeScript only
Models	Claude only	Any provider through AI Gateway
Agent API	`query()` with `ClaudeAgentOptions`	`ToolLoopAgent` class
Built in tools	Read, Write, Edit, Bash, Glob, Grep, WebSearch	None by default, you define them
Subagents	First class, own context window	Not built in
MCP support	First class	First class as of v6, OAuth supported
Prompt caching	On by default	Provider dependent, opt in
Context compaction	Automatic	Manual
DevTools UI	None	Local UI at `localhost:4983`
Frameworks	Any	Next.js, React, Svelte, Vue, Node.js

The Anthropic SDK is opinionated and Claude shaped. The Vercel SDK is flexible and provider neutral.

Same agent in both

Claude Agent SDK

import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "What changed in HTTP/3 in 2025?",
  options: {
    allowedTools: ["WebSearch", "WebFetch"],
    systemPrompt: "You are a research assistant. Always cite sources.",
  },
})) {
  if ("result" in message) console.log(message.result);
}

WebSearch and WebFetch are built in.

Vercel AI SDK 6

import { ToolLoopAgent, tool } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { z } from "zod";

const webSearch = tool({
  description: "Search the web. Returns the top three results.",
  inputSchema: z.object({ query: z.string() }),
  execute: async ({ query }) => results,
});

const agent = new ToolLoopAgent({
  model: anthropic("claude-opus-4-7"),
  instructions: "You are a research assistant. Always cite sources.",
  tools: { webSearch },
});

const result = await agent.generate({
  prompt: "What changed in HTTP/3 in 2025?"
});

You bring your own search function. Swap anthropic(...) for openai(...) and the rest of the file is unchanged.

Where each wins

The Claude Agent SDK wins on built in tools, subagents with their own context window, hooks that mirror Claude Code, and defaults that match production. Prompt caching is on, compaction is automatic, retries are sensible.

The Vercel AI SDK 6 wins on provider flexibility, the DevTools UI at localhost:4983, one line human in the loop with needsApproval, and having image, audio, and reranking in the same library.

A simple way to choose

Are you locked to Claude models?
  Yes → Claude Agent SDK
  No  → TypeScript and React stack?
          Yes → Vercel AI SDK 6
          No  → Claude Agent SDK Python build

For LangChain comparisons, the Claude Agent SDK vs LangChain post has the answer.

The full guide covers MCP wiring on both sides, defaults and cost, the June 15 2026 Agent SDK billing change, and a longer FAQ: Claude Agent SDK vs Vercel AI SDK 6: Which to Pick (2026).

AWS Copilot CLI is reaching end of support — your migration options

Muhammad Moeed — Wed, 20 May 2026 13:32:59 +0000

If you have been using AWS Copilot CLI to deploy containers on ECS, the tool has a date on it. AWS Copilot CLI reaches end of support on June 12, 2026. After that, the open-source project stays on GitHub, but AWS will not ship features, fixes, or security patches for it.

This is the short version. The full walkthrough is on my blog: AWS Copilot CLI End of Support: Migration Guide for 2026.

What changes on June 12, 2026

Your running apps do not. The ECS services, load balancers, and CloudFormation stacks Copilot created stay in your account.

What changes is the tool:

No new features.
No security updates from AWS.
No technical support.
The GitHub repo stays open, but it is no longer AWS-maintained.

What AWS recommends instead

Two paths, for two kinds of teams.

Amazon ECS Express Mode. The fastest path from a container image to production. You hand it an image and two IAM roles, and it builds the load balancer, listener, target groups, security groups, scaling, and monitoring. Fargate-only. Closest in spirit to Copilot. Pick this if your service is a standard load-balanced or request-driven web app.

AWS CDK Layer 3 constructs. The aws-ecs-patterns library has constructs like ApplicationLoadBalancedFargateService, QueueProcessingFargateService, and ScheduledFargateTask that cover most patterns Copilot supported. Pick this if you need fine-grained control, blue/green, a service mesh, or non-Fargate launch types.

You can also take over the CloudFormation Copilot generated and manage it directly. Low effort short-term, but those templates are not built to be human-edited. Treat it as a bridge.

Service-by-service map

Copilot service type	Replacement
Load Balanced Web Service	ECS Express Mode, or CDK `ApplicationLoadBalancedFargateService`
Request-Driven Web Service	ECS Express Mode with request-based scaling
Backend Service	CDK internal ALB, or ECS Service Connect
Worker Service	CDK `QueueProcessingFargateService`
Scheduled Job	EventBridge Scheduler + ECS `RunTask`, or CDK `ScheduledFargateTask`
Static Site	CDK CloudFront constructs, or AWS Amplify Hosting

Most teams find that web services land on Express Mode and workers/scheduled jobs land on CDK.

How to plan the move

One service at a time, not one big switch:

Inventory every service. copilot svc ls gives the list; the copilot/ manifests give the type.
Match each to its replacement.
Pick a low-traffic service for the first migration. The point is to learn the workflow, not to ship the hardest case.
Run both versions in parallel for a few days, watch metrics, cut over.
Delete the Copilot service to remove its stack cleanly.
Repeat. Hardest cases last.

If you only do one thing before June 12, do step one.

The full guide covers the IAM-role split for Express Mode, when CDK is actually worth it, the third path of taking over the CloudFormation directly, and what happens if you cannot migrate in time: AWS Copilot CLI End of Support: Migration Guide for 2026.

Claude Code /goal and Agent View, explained

Muhammad Moeed — Tue, 19 May 2026 11:39:31 +0000

The May 2026 Claude Code update added two features for running it without watching every step: the /goal command and Agent View. They are separate, but built for the same workflow, so here they are together. Everything below is from the official docs. The full version is on my blog: Claude Code /goal and Agent View: A Practical Guide.

What /goal does

You write one completion condition. After each turn, instead of stopping, Claude Code asks a separate model whether the condition is true. No, it takes another turn, using the reason as guidance. Yes, the goal clears and you get your terminal back. Requires v2.1.139 or later.

You set one by running /goal followed by the condition, for example: /goal all tests in test/auth pass and the lint step is clean.

Running /goal with no argument shows status. /goal clear stops it early. It also runs non-interactively with claude -p "/goal CHANGELOG.md has an entry for every PR merged this week".

The detail most posts skip

The evaluator is a small fast model (Haiku by default). It does not run commands or open files. It only judges the text already in the session. So the condition has to be something Claude can prove by what it prints. "All tests in test/auth pass" works because the test output lands in the transcript. "The code is good" never will.

A condition that holds up has one measurable end state, a stated check (how Claude proves it), and the constraints that must not change. It can be up to 4,000 characters. Add a clause like "or stop after 20 turns" so it does not run forever. That one clause is the difference between a task that ends and a task that quietly keeps spending tokens.

How it compares

/goal: next turn after the previous finishes; stops when a model confirms the condition.
/loop: next turn on a time interval.
Stop hook: your own script decides. (/goal is actually a thin wrapper over a session-scoped Stop hook.)
Auto mode: removes per-tool approvals inside a turn. Complementary: auto mode plus /goal means turns run unattended and keep coming until done.

Agent View

Once a session runs on its own, you want several. Agent View is one CLI screen listing your sessions: status, last response, when you last touched it. Open it with the left arrow from any session, or by running claude agents. Statuses are Running, Blocked (needs you), and Done. Peek at a session, answer inline if it is blocked, press Enter to attach fully.

Background sessions connect the two: /bg sends the current session to the background, and claude --bg [task] starts one already detached. Start a few goals with turn limits, background them, watch the fleet in Agent View, and step in only on Blocked or Done.

Agent View is a research preview on Pro, Max, Team, Enterprise, and Claude API plans.

The full guide covers writing conditions in depth, the requirements and limits, when not to use it, and how it differs from Outcomes and plan mode: Claude Code /goal and Agent View: A Practical Guide.

What is AWS ECS Express Mode (and when to use it)

Muhammad Moeed — Tue, 19 May 2026 11:33:31 +0000

If you have ever deployed a normal web service on ECS, the slow part was never the container. It was everything around it: a load balancer, listener rules, target groups, two security groups, a task definition, the service, auto scaling, alarms, and the networking that ties it together. ECS Express Mode is Amazon's answer to that. You give it a container image, and it builds the rest.

This is the short version. The full walkthrough is on my blog: What is AWS ECS Express Mode.

What you give it

Three inputs, that is the whole list:

A container image — your actual app, the kind of image you would push to ECR.
A task execution IAM role — the role ECS uses to start the container, pull the image, and write logs.
An infrastructure IAM role — the new one. The permission Express Mode uses to create the load balancer and the rest on your behalf.

The two roles are kept separate on purpose. One runs your app, the other provisions infrastructure. You do not want your running container holding permission to create load balancers.

What it builds

From those three inputs it provisions an Application Load Balancer, an HTTPS endpoint on an AWS-provided domain, auto scaling, health checks, security groups, and monitoring set up with AWS's recommended defaults. Every resource stays fully visible and editable in your own account.

It runs on Fargate only, not the EC2 launch type. It also places up to 25 Express Mode services behind a single shared load balancer when their networking is compatible, so you are not paying for a load balancer per tiny service.

What it costs

The feature has no extra charge and is in all regions. You pay only for the AWS resources it creates to run the app. You save the setup time, not the running cost.

When not to use it

Express Mode trades configurability for speed. Skip it when you need:

Blue/green deployments — not supported.
A service mesh or detailed networking control — not available.
The EC2 launch type — Fargate only.
A dedicated load balancer with custom listener logic.

Because every resource stays in your account, you are not locked in. Start on Express Mode, and when a service grows into one of those cases, migrate it to a standard ECS service rather than rebuilding from scratch.

The full version explains the IAM roles, the shared load balancer model, the comparison table against a standard ECS service, and a full FAQ: What is AWS ECS Express Mode (and when to use it).

How Anthropic's own teams use Claude Code

Muhammad Moeed — Tue, 19 May 2026 11:11:04 +0000

Anthropic published a report on how its own staff use Claude Code. It comes from interviews with internal power users across ten teams, including non-technical ones like legal and marketing. A lot of people have been looking for the PDF, so here is the short version plus the parts that matter even if you are one person and not a company with a large monorepo.

The source is How Anthropic teams use Claude Code (PDF). This is my reading of it, not a copy.

The report in one paragraph

Ten teams, some technical and some not. The recurring lessons are simple and consistent: write a detailed CLAUDE.md, commit checkpoints often so you can revert, treat Claude Code as a partner you iterate with rather than a one-shot machine, paste screenshots instead of describing things, and learn which tasks can run on their own versus which need you watching. The biggest jumps came from people who do not write code for a living.

A few of the stories

Data Infrastructure debugged a Kubernetes outage by pasting dashboard screenshots in and letting Claude Code walk them through the console until they found pod IP exhaustion. They also taught the finance team to run plain-text workflow files.
The Claude Code team builds Claude Code with it. Edge features run in auto-accept loops to about an eighty-percent solution; core logic is watched closely. Vim mode was roughly seventy percent autonomous.
Security Engineering pastes Terraform plans in and asks, in plain words, what it will do and whether they will regret it. They own about half the custom slash commands in the whole monorepo.
Data Science builds React and TypeScript dashboards without reading the code, and treats messy refactors "like a slot machine": commit, let it run thirty minutes, then accept or restart fresh.
Growth Marketing, a non-technical team of one, built ad-generation workflows with subagents and a Figma plugin, cutting two-hour copy tasks to fifteen minutes.
Legal built a predictive-text speaking app for a family member in about an hour.

The patterns worth keeping

These came up independently across teams doing very different work:

CLAUDE.md is the highest-leverage file you have. Three unrelated teams reached this on their own.
Commit checkpoints and be willing to throw work away. Restarting clean usually beats fixing a bad attempt.
It is a partner you iterate with, not a one-shot oracle. Give it the minimum, watch, steer.
Screenshots are an input, not a fallback.
Judge the task before you pick the mode. Edge work can run alone; core logic needs you in the room.
Documentation is a first-class use, not a side effect.
Use MCP and subagents to keep things controlled and focused.

The honest parts

Most write-ups drop these. The RL team says a first attempt fully works only about a third of the time, and that it sometimes puts comments in odd places. Data Science says it tends toward complex solutions and has to be told to keep it simple. That is not a reason to avoid it. It is the reason the checkpoint-and-revert habit exists.

What a solo developer can copy today

Write a real CLAUDE.md, even a short one.
Start risky runs from a clean git state and commit as you go.
Automate the repetitive thing that sits behind an API first.
Plan in a normal chat, then move the structured prompt into Claude Code.
If a run goes sideways, revert and restart instead of wrestling it.

The full version on my blog goes team by team through all ten, with the specific numbers and tips for each: How Anthropic's own teams use Claude Code.

Claude Code vs Cursor — 90 days with both in 2026

Muhammad Moeed — Fri, 15 May 2026 00:43:39 +0000

If you have already tried one of them, you are probably wondering whether the other is worth a switch. The short version is that Claude Code and Cursor are not competing for the same job, even though they look like they are. One lives in your terminal and behaves like a junior engineer with shell access. The other lives inside an editor and behaves like a very fast pair programmer sitting next to you.

I ran both on real work for ninety days. Some of it was a Next.js client project, some of it was a Python data pipeline, and a fair amount was housekeeping in my own blog. The picture that came out of that is more nuanced than the comparison posts I had read going in.

TL;DR

Claude Code is better when the task is large and the work happens across many files. Cursor is better when the task is small and you need to stay in the file you are looking at. Most working developers end up using both.

What they actually are

	Claude Code	Cursor
Form	Terminal CLI (plus IDE extension)	Forked VS Code editor
Default working mode	Agentic — reads, plans, edits, runs cmds	Inline completion + chat + agent
Pricing	Pro $20 / Max $200 per month	Pro $20 / Ultra $200, free tier
Best for	Multi-file refactors, repo-wide work, CI	Single-file edits, fast iteration

Cursor is an editor. Claude Code is an agent. That one sentence explains most of the differences below.

Where Cursor wins

I want to be honest here because the internet has decided Claude Code is the winner and Cursor is yesterday's news. That is not what I saw.

Inline tab completion is still the best in the category. For small edits where you already know what you want, this beats any agent loop on raw speed.
Diff review inside a real editor. Hunk-by-hunk accept/reject with keyboard shortcuts is genuinely nicer than reading the same diff in a terminal.
Exploring an unfamiliar codebase. Right-click → "explain this function" while looking at the function is the fastest way to learn a new repo.
Per-request model switching. Mix Opus 4.7, GPT-5, and cheaper models depending on the task.

Where Claude Code wins

These are the cases where I would not even open Cursor. The gap is large enough that there is no contest.

Large refactors across many files

The first time Claude Code paid for itself was a migration job. Rename a config option across thirty-eight files, update the types, fix every test, add a deprecation notice. In Cursor I would have done this with search-and-replace and a lot of cleanup. In Claude Code I described the task in two sentences and walked away for ten minutes. When I came back, it was done and the tests were passing.

For anything that touches more than four or five files, the agent loop is the right shape. You stop being a typist and start being a reviewer. That shift is the real product.

Long-running, autonomous work

Claude Code can run for thirty or forty minutes on a single task without losing the thread. It plans, executes, hits errors, debugs, and finishes. Ultraplan, the newer cloud-planning feature, pushes this even further by separating planning from execution.

Cursor's agent mode can do similar work, but I have never gotten a clean half-hour run out of it. It stops to ask questions or loses context. Claude Code is more comfortable with autonomy.

Running in CI and headless environments

Because Claude Code is a CLI, it runs anywhere a shell runs. Drop it into a GitHub Action and have it review PRs. Pipe data into it. Cursor is an editor, so it lives where editors live: on a developer's laptop. For team automation, this is a real gap.

Real cost over three months

People hand-wave about cost. Here are numbers I actually saw.

Tool	Plan	Months	Real spend
Cursor	Pro $20/mo	3	$60
Claude Code	Max $200/mo	3	$600
Total			$660

That Claude Code spend looks high until you compare it to what those tasks would have cost in human hours. The refactor I mentioned above would have taken me a full day. Claude Code did it for about eight dollars of compute.

If you are on a tight budget, Cursor Pro at $20 is the better starting point. If you bill client work and your time is worth more than $50 an hour, Claude Code pays for itself inside the first project.

Which one to pick for which work

Your situation	Pick
Solo developer, writing a lot of new code	Cursor
Bug fixes in a codebase you know well	Cursor
Multi-file refactor or migration	Claude Code
Writing tests for an existing module	Either
Reviewing a PR (especially in CI)	Claude Code
Learning a new codebase	Cursor for poking, Claude Code for summaries
Heavy automation, scripting, glue work	Claude Code
Very limited budget	Cursor Pro
Client work where your hourly rate is high	Claude Code Max

The honest answer for most working developers is to use both. They are inexpensive enough together that the question is not which to pick, but how to set up your workflow so each one does what it is good at.

The setup I actually shipped

After ninety days, this is what stayed.

Cursor for active coding sessions. Fast tab complete, quick diffs.
Claude Code for everything else. Refactors, test runs, PR reviews, repo-wide search, anything I want running while I am doing something else.
Both pointed at the same shared .claude/ folder so my hooks, skills, and MCP config travel with the repo. A server I write once works in both places.
A few small subagents for jobs I do often — diff review before commit, weekly change log.

Total: $220 a month for the two of them. Saved a lot of time, I have not measured it carefully enough to put a defensible number on it.

A few common questions I get asked about this

Is Cursor going to be replaced by Claude Code?

No. Cursor is an editor with AI. Claude Code is an agent in your terminal. Either can copy a feature, but the form factor of each one limits how much it can become the other.

Can I use Claude Code inside Cursor?

Yes — run the CLI in Cursor's integrated terminal. You lose the editor integration with the agent but keep Cursor's other features.

Does Cursor support MCP?

Yes. Same .cursor/mcp.json format. An MCP server you write once works in both.

Better for non-developers?

Cursor. CLIs have a learning curve not everyone wants to climb.

The full version

This is the dev.to cut. The full version on my blog goes deeper on:

Speed, reliability, and memory benchmarks I tracked
Editor lock-in concerns with Cursor
A longer "common questions" section
Decision rules I now follow when picking which tool to open

If you have the opposite experience from what I described above, I genuinely want to hear it. The most useful comparisons come from people whose work shape is different from mine.

DEV Community: Muhammad Moeed

Claude Fable 5.2 vs Opus 5.5: which one should you actually use?

Quick answer

Side by side

Where Fable 5.2 wins

What 2x means in dollars

A simple rule

Switching in Claude Code

Two API gotchas

spawn npx ENOENT and 9 Other MCP Errors, Explained in Plain English

The 4 things that fix 80% of MCP failures

The single most common MCP error

What is in the full guide

If you have hit an MCP error not in the list, drop it in the comments and I will add it in the next update.

Claude Fable 5 is currently unavailable , here's what actually happened

The short version

What the government said was the problem

When is Fable 5 coming back?

Full guide

MCP Apps vs OpenAI Apps SDK: are they competing standards?

The short answer

The four real differences

Which one to pick

Claude Agent SDK Cost Tracking — what to do before June 15, 2026

Claude Code slow or worse? How to diagnose and fix it in 2026

What actually happened

Three quick checks

1. Are you on the fixed build?

2. Run /doctor

3. Check status

Six fixes for the rest

The diagnostic tree

Claude Agent SDK vs Vercel AI SDK 6 — which to pick in 2026

The short version

Side by side at a glance

Same agent in both

Claude Agent SDK

Vercel AI SDK 6

Where each wins

A simple way to choose

AWS Copilot CLI is reaching end of support — your migration options

What changes on June 12, 2026

What AWS recommends instead

Service-by-service map

How to plan the move

Claude Code /goal and Agent View, explained

What /goal does

The detail most posts skip

How it compares

Agent View

What is AWS ECS Express Mode (and when to use it)

What you give it

What it builds

What it costs

When not to use it

How Anthropic's own teams use Claude Code

The report in one paragraph

A few of the stories

The patterns worth keeping

The honest parts

What a solo developer can copy today

Claude Code vs Cursor — 90 days with both in 2026

TL;DR

What they actually are

Where Cursor wins

Where Claude Code wins

Large refactors across many files

Long-running, autonomous work

Running in CI and headless environments

Real cost over three months

Which one to pick for which work

The setup I actually shipped

A few common questions I get asked about this

The full version

2. Run `/doctor`