Mirza Ishraq
← All issues

Issue #1 · By · · 6 min read

The one-prompt lie: 5 repos, a free fix, one app idea

Claude Opus 5.5 dropped and X turned into a motion-design flex-off overnight. Every clip said “one prompt.” I tried it myself: 30 minutes, real output, and a token bill that reminded me I’m not made of API credits. Turns out I wasn’t the only one who got got by the hype.

This issue: what “one prompt” actually costs, a token-saving fix that’s free, five repos worth a look, and an app idea for an IDE that only bills you when you ship.

Talk of the Town

Claude Opus 5.5 is Anthropic’s newest Opus model, released September 22. It’s now the default Opus in Claude Code (v2.1.280), with a 1M-token context window at $4/$20 per million tokens, and Anthropic says it matches Fable 5.1 on most tasks while costing 40% less to run than Opus 5.

The launch page topped Hacker News with over 1,800 points, but the real fuel was motion design. Within hours, X filled with “one prompt” showreels: 15-second motion graphics reels, posters breaking out of their own frame, whole product explainers rendered entirely in code, no After Effects. People love that it needs less hand-holding, pushes back less, and burns less quota while still producing work that used to need a real motion designer. Not everyone’s sold: one poster asked Anthropic not to “nerf” it the way past models reportedly were, and another pointed out that a one-prompt AI game is unplayable if nobody actually tests it.

I tried building my own motion-design skill with it. Impressive output, but very high token costs, and I was running it on Max, so I really should’ve known better than to let the X hype get to me. Full workflow, prompting, tuning, building the skill, and finding the right rendering approach, took 30 minutes. I wasn’t the only one: one builder logged 3 hours and $54.52 for one clip, another spent 5 hours 28 minutes and $90. “One prompt” undersells what actually goes into the good ones.

Still, I love Opus 5.5. Worth using, even after seeing what the flashy demos actually cost.

This Week in AI

Claude Code v2.1.283: managed settings for teams

Claude Code’s v2.1.283 added availableModelsMatch, a managed setting that pins an exact model version, plus deniedModels to block specific ones outright, and opt-in gateway headers that group every request from one prompt together. Run Claude Code across a team and you can now stop a config from quietly switching everyone to a different model version, and gateway operators can finally see which requests belong to the same user turn. Boring infrastructure work, and boring infrastructure work is exactly what keeps a team’s Claude Code bill predictable. Worth it if you run Claude Code across a team, skip it solo.

→ v2.1.283 release notes

The AGENTS.md telemetry bug, now fixed

A documented Claude Code bug meant project instructions in AGENTS.md were silently skipped unless telemetry was turned on. It’s fixed now, and v2.1.282 added a startup notice listing any telemetry variables that were ignored or that turned telemetry off. If your Claude Code sessions seemed to “ignore” your project rules for no obvious reason, this might have been why, and a bug where your own instructions get silently dropped is exactly the kind of thing that makes you doubt your own prompt instead of the tool. Good to know if yours ever seemed ignored; already fixed, just update.

→ Claude Code reads AGENTS.md only when telemetry is on, fixed

anthropic-sdk-python v1.8.0

The Python SDK added support for claude-opus-5-5, inline tool definitions, and beta MCP tool-list pinning, plus a fix for a Python 3.13 crash when a stream is left open at exit. If you build directly on the API in Python, this is the update that gets you Opus 5.5 access and stops your process from crashing on exit under 3.13, the kind of release you only notice when it fixes a crash you’d already learned to work around. Worth grabbing if you build on the API directly; the 3.13 crash fix alone earns it.

→ v1.8.0 release notes

Steal #1: Native code intelligence for Claude Code (TypeScript & Python)

What it is: A pair of official, Anthropic-maintained plugins that give Claude Code real code intelligence, go-to-definition, find-references, type diagnostics, backed by an actual language server instead of grep-and-read. Same accuracy as your editor’s own type-checker, at effectively zero setup cost.

How to install:

npm install -g typescript-language-server typescript
npm install -g pyright   # or: pipx install pyright

claude plugin install typescript-lsp@claude-plugins-official
claude plugin install pyright-lsp@claude-plugins-official

Then reload: /reload-plugins in an open session, or just start a new one.

How to use it: Nothing changes in how you talk to Claude Code. It reaches for the LSP tool on its own for symbol lookups instead of grepping the repo, and shows Found N new diagnostic issues in M files right after an edit, catching a type error before your next build or test run.

Watch out for: The plugin wrapper auto-updates itself, but the underlying language-server binaries (ordinary npm/pip packages) don’t, keeping those current is on you, a periodic npm outdated -g check. It also doesn’t touch git history, cross-file dependency graphs, or semantic search, that’s still an unsolved, separate problem.

Builder Radar

  • jevgrep: a CLI that finds code by asking what it does, built for coding agents that need to find the relevant files. Less time spent grepping for the wrong symbol name.
  • Foremerge: catches intent conflicts between parallel coding agents that git alone misses. The multi-agent failure mode nobody’s watching for yet.
  • magpie: a menu-bar tool that points Claude Code at other models, for example running it on Kimi. Useful for comparing models without leaving your workflow.
  • Whiteboard: an open-source canvas Claude Code or Codex can draw on to explain its own work. For design reviews with an agent, not just code review.
  • Drop: a rootless Linux sandbox with gVisor support, no full container or VM needed. Limits the damage a compromised dependency can do on your dev machine.

App Ideas

The problem: Exploring a codebase, planning, and asking Claude questions burns the same tokens as shipping real code. That makes you hesitate to dig in and ask more, even though digging in is exactly what produces a better answer.

Who it’s for: developers on token-metered Claude plans who don’t want to watch the meter while they explore.

How I’d build it with Claude:

Interview & Sketch prompt:

I want to design a tool that only bills a developer's token usage against
code that actually ships (gets committed or merged), not against
conversation, exploration, or planning. Claude Code already exposes exact
per-turn token counts in its local JSONL session transcripts (see this
issue's Steal This). Before sketching anything, interview me one question
at a time about my actual workflow, what I explore versus build, how I use
Claude Code day to day, what "shipped" should mean for me, until you have
enough to design around my real habits, not a generic one. Then sketch an
architecture: what would need to be measured, where the line between
"exploring" and "shipping" should be drawn, how you'd separate billed
tokens from free ones, and give me the answer as a numbered list of
implementation phases.

Demo/Mockup prompt:

Build a dummy-data prototype called "ShipMeter", a token-usage dashboard
for developers that only bills for tokens tied to code that actually
ships.

## Design & Theme
- Dark mode only, near-black background (~#0d1117), soft white text
- Primary accent: a clear "billed" vs "free" color pair (e.g. amber for
  billed tokens, green for free ones)
- Monospace for numbers and token counts, sans-serif for labels
- Minimal developer-tool look. No gradients, no glow, no rounded bubbly
  cards
- Desktop-first, works on a laptop screen at minimum

## Pages

### 1. Dashboard (/)
- Top bar: project selector, date range picker, a large "This week's
  billed tokens" number in the accent color
- 4 stat cards: Billed Tokens, Free Tokens, Sessions This Week, Average
  Cost per Shipped Change
- A stacked bar chart: billed vs free tokens per day, past 7 days
- A Recent Sessions table: project, total tokens, billed tokens, free
  tokens, a Shipped / Exploration only badge

### 2. Session Detail (/session/:id)
- A timeline of the session's turns, each tagged Billed or Free
- Marks which turns line up with an actual git commit or merge (the
  "shipped" boundary)
- A running total: "$X billed so far, $Y saved exploring for free"

### 3. Settings (/settings)
- Define what counts as "shipped" (a commit on a tracked branch, a PR
  merge, a manual mark)
- Connect a git repo (mock connection state is fine)
- Pricing config: cost per billed token

## Important Notes
- This is a prototype with dummy data only, no real backend, no real
  Claude Code integration
- All data hardcoded to look like a real week of usage
- Prioritize making the billed-vs-free distinction visually obvious at a
  glance
- Make navigation between the three pages functional

Build it? Hit reply.

Build & Experiment Log

  • Building: Two simpler pricing tiers for Tradion (Starter, Pro), renamed tools (Snipe, Lens, Earnings Deep Research)
  • Tried: A one-prompt Claude motion-design skill on Opus 5.5
  • Broke: Forgot to push a migration on Tradion, locked myself out of login
  • Learned: Deleting code you’re proud of hurts. A product that tries to do everything hurts more

From the Blog

P.S. Forward this to a friend who builds. Read it on the web: The one-prompt lie

Hit reply and tell me: what are you building?

More issues