#claude-code

I downgraded my Claude subscription from $200/mo to $100/mo and started paying Cursor $60/mo instead. The trigger was Wednesday's Claude outage, but the real reason is that GLM-5.2 through Cursor has been fast enough and good enough that the math stopped favoring Opus. If a model is 80% as good as Opus 5 but roughly 7x faster, I'll take the speed and pay for the 80%.

The unscientific test

Same workspace, same CLAUDE.md/AGENTS.md, high effort on both. The prompt was "make a quick tetris game as an html file," followed immediately by "now use cyberpunk colors."

Two setups: Cursor running GLM-5.2, and Claude Code running Opus 5.

GLM finished in 53 seconds. Opus took 7 minutes 5 seconds, though a good 2-3 minutes of that was Opus testing the game with Playwright, which GLM didn't do.

The visuals came out mostly the same. Opus edged it on the blank-slate UI, which tracks with my experience. I trust Opus more when there's nothing on screen to anchor a design. The generated code was close to identical in structure.

Adding Kimi to the pile

For a third data point, Cursor with Kimi K3 on max effort: 4 minutes 3 seconds.

Visuals are fine. The code has a bug, the game doesn't auto-start, and the structure feels a step down: a big list of global variables where Opus and GLM both scoped things more tightly. Again, totally unscientific, but Kimi felt buggier and the code quality "felt" lower.

The 7x

Experiencing near-Opus quality at 7x the speed is genuinely a different thing than reading about it. The loop tightens. You ask, you get an answer, you ask again, all before you've lost the thread.

If this is what 7x feels like, I'd like to see 70x.

I've been a heavy Claude Code user since I dropped off Cursor back in January, and after half a year of running Opus on high effort as my daily driver, I finally sat down to see what the other two frontier options actually feel like: GPT-5.6 Sol inside Codex, and GLM-5.2 inside Cursor. This is a first pass, not a benchmark. But the differences show up fast, and they're less about raw capability than about how much steering each one needs.

Why I stuck with Claude Code

Claude Code with Opus has been reliable in a specific way: I know where the edges are. Tell it to do something and I generally know the outcome before it runs. That predictability is worth a lot, even through Anthropic's downtime and the occasional sense that a model's behavior shifted underneath me. Reliability beats novelty when the tool is load-bearing.

Curiosity won anyway. Both Sol and GLM-5.2 have a lot of hype around them, so both are getting a real trial on real work.

GLM-5.2 in Cursor

The initial, unscientific impression of GLM-5.2 is that it's good. Call it 75 to 80% as capable as Opus 4.8. It gets things done without much intervention and mostly stays on the rails, though it sometimes wanders down an implementation path that needs correcting.

Two confounders help it, and I want to be honest about them. One, Cursor is a good harness. Two, our team runs an extensive developer harness module: skills, documentation, helper scripts, a large pile of team-specific context that gives any model an edge. How GLM-5.2 would perform naked, hitting the API through a simpler agent, I genuinely don't know.

One habit across all of this: force thinking as high as the tool allows. Not max, usually the tier just under it, like high.

GPT-5.6 Sol in Codex

Sol on high thinking seems reasonable on capability. The problem so far is inertia.

Ask it to do something, or suggest something be done, and it says sure, it can do that. Say "okay, go do it," and it says yes, it can absolutely do that. Then I have to say, explicitly, no, go do the thing, now. It reads the letter of what you wrote and pays less attention to the intent behind it, so you have to give it more direct instructions than I'm used to giving.

That friction is hindering my evaluation more than any capability ceiling is. I'll keep pushing on it, because the pedantry might just be a prompting problem on my end.

Where I've landed for now

Big tasks and anything that needs writing, design docs, blog posts, stay in Claude with Opus. Small and medium tasks get delegated out to Cursor and GLM-5.2. Sol stays in the rotation as an experiment until I figure out whether the inertia is the model or me.

All my notes live in one directory. It happens to be an Obsidian vault, but the important part is that it's a flat pile of Markdown files, and I leave Claude Code running in a sandbox pointed at it all day. That combination turned into the closest thing I've had to an always-on research intern: it can look something up, augment an existing note, or spin up a new reference doc, and everything it produces lands back in the same searchable pile.

I'm not a heavy Obsidian user and never have been. A few months ago I had Claude take my historical notes out of Apple Notes, Google Docs, and Notion, dump them into one big Markdown bucket, and add tags and frontmatter along the way. Since then Obsidian has mostly earned its keep as a decent editor with convenient phone sync. The agent does the interesting work.

The setup

Claude Code runs under nono in what you might call YOLO mode, or bypass-all-permissions. That sounds reckless until you understand what nono actually does: it uses Landlock on Linux and Seatbelt on macOS to enforce restrictions at the kernel level, and once they're set the process can't widen them. No escape hatch, not even for nono itself. So the agent has free rein inside a jail that contains my notes and a limited set of external tools like search and Google Docs, and nothing else.

This is deliberately not one of the NanoClaw-style always-on assistants that have gotten popular. Those come with real risk. Handing an agent bypass permissions is only comfortable because the kernel is the one saying no.

The recipe test

Here's what convinced me. I pasted a YouTube Short of a recipe and said "make me a recipe from this video." I also told it to grab the transcript with yt-dlp if it could.

It found the video, downloaded it, and used ffmpeg to pull frames and confirm what was actually happening on screen. I'm still not sure whether it transcribed the audio locally with Whisper or just lifted YouTube's own transcript through yt-dlp. Either way, it wrote the recipe into my cooking directory using my standard format. Later I pulled it up on my phone while making dinner.

Remote control closes the loop

Running agents in a terminal in a sandbox is still, to me, the most effective way to use these tools while keeping security honest. The problem has always been reaching that terminal from the couch. SSH from a phone works, technically, but it's miserable.

Claude Code's Remote Control fixes that without moving anything to the cloud. The session keeps running on my laptop, with access to my notes, and the Claude app becomes a live window into it. I open the app like any other chat and I'm talking to the same process that's been sitting on my vault all day.

It isn't a person, and I don't want it to be. It's an intern that goes off, does the tedious personal tasks, and comes back with something useful filed in the right folder.

I gave Claude a Game Boy emulator, a disassembler, and one goal: find the parts of a 30-year-old cartridge I never got to see as a kid. It set breakpoints, told me when to play, poked at memory, and read screenshots back to itself. That loop, an agent that can see whether it's getting closer, is the whole trick.

The 90s version of this problem

I grew up with an original Game Boy and later a Game Boy Color. Console gaming back then was a closed world. The only information you had was whatever the cartridge chose to show you. Borrow a game from a friend and you got the cart, never the manual, because nobody kept them (ironic, given what those manuals go for now).

There's a specific memory here. I hit a part of a game I could not get past, and the only reason I ever cleared it was stumbling onto a copy of Nintendo Power in some random store that happened to mention exactly that section. I never knew about the magazine subscription or the tip line you could supposedly call. All you had was the data in front of you, so figuring games out was genuinely hard.

The actual question

I had a Game Genie growing up, but that was mostly infinite lives. Not interesting. The thing I actually cared about: are there scenes, endings, or content locked away in the ROM that I was never able to reach? What secret stuff is sitting in there unrendered?

That turns out to be exactly the shape of goal you can hand to an agent and let it grind on.

Three tools

The setup is three pieces:

• Gearboy, an extremely detailed Game Boy and Game Boy Color emulator built on imgui. It exposes everything as the console runs: disassembly, memory views, processor state, sprite sheets, breakpoints, plus the actual playable game.
• GhidraBoy, a Game Boy disassembly toolkit for Ghidra.
• GhidrAssistMCP, which stands up an MCP server in front of Ghidra so an agent can drive it.

Wire those together and Claude can disassemble, investigate, and hunt for exploits in old carts. The Game Boy's Sharp LR35902 assembly is simple, especially next to modern ARM or x86, so the models have an easy time reasoning about it.

Working with Claude on it

Claude did a solid job understanding subroutines and what they were for by inspecting memory, taking screenshots, and comparing those screenshots over time. Finding straight-up cheats was hit or miss, but that was never the point.

The working rhythm was genuinely fun. Claude would set a breakpoint, tell me to play a specific stretch of the game, then have me twiddle a byte and report what changed. Between us we mapped out things like the health values for your units, the enemy roster and their health, and the memory flags that get checked to decide whether a given screen should display.

Give your agents eyes

I've said this before and the Game Boy just makes it concrete. Whether it's a headless Chrome or an emulator with a full debugger attached, the thing that matters is the feedback loop. Give an agent a way to see whether it's achieving its goal, then let it spin. That's when it starts doing surprising things.

Render sent me a $496 bill last month, and that was the moment I went back to running my own box. SpaceMolt served 1.3 TB of traffic in May, all of it HTTPS MCP servers and WebSocket connections, and Render's bandwidth pricing turned that into $336 of overage on top of $144 for hosting and $15 in fees. The thing that made self-hosting viable again wasn't a cheaper VPS. It was that Claude Code now does the parts I used to dread.

How I ended up on managed hosting in the first place

Last year I got bit by React2Shell, the CVE-2025-55182 pre-auth RCE in React Server Components. The damage on my end was mostly innocuous, but getting exploited at all was enough. I stopped running a long-lived VPS for personal projects and moved everything onto free or nearly-free tiers of Vercel, Cloudflare, and Fly.io.

When SpaceMolt started, Render.com was the obvious pick. Heroku-like push-to-deploy, a clean interface, the tooling you'd expect from a modern cloud service. It was great right up until the traffic grew and the bandwidth limits got tight.

What changed: the agent does the ops work

A year ago I would have built all of this by hand. Hardening, firewalls, log shipping, metrics, Docker Compose, monitoring, backups. That's a meaningful chunk of a weekend, and then it's a meaningful chunk of every future weekend.

An agent like Claude Code only needs SSH. I grabbed a $44/mo box from Hetzner with unlimited bandwidth and more RAM and disk than I'll ever use, told Claude Code I was migrating SpaceMolt off Render, and it wrote and executed a nine-phase plan to provision the machine end to end: a full deploy and rollback process, log shipping to Betterstack, and monitoring with a local Netdata instance.

I'd never heard of Netdata before this. Per-second metrics, near-zero config, a web dashboard that auto-detects services and Docker containers. It's left me impressed.

The runbooks are the real artifact

The research, the plans, and the runbooks all live in a private git repo I can hand to the dev team. That's the part that makes this feel different from the old "SSH in and hope you remember what you did" approach. The knowledge isn't in my head or buried in shell history. It's written down, versioned, and reproducible.

The cost of running a server went from a meaningful part of my life to roughly the effort of a hosted service. The bill went the other direction.

Building the new North Pole Security site, I kept hitting the same friction: reviewing a page, then typing out a punch list of fixes for Claude Code. Every item needed a page name, a location, and enough context to be actionable. So I had Claude build me a point-and-click sticky note system instead, and now I shift-click on the page, type a note, and it gets fixed. Less typing, more pointing.

What it actually does

The idea was simple. Wouldn't it be nice to leave sticky notes on the page, the way you'd flag a printed mockup with a pen? In a single prompt, Claude Code had nearly the whole thing built.

Each note captures what it needs to be useful: x/y coordinates, window size, the CSS selector under the cursor, and, because Astro emits dev-mode HTML attributes, the source filename and line number. All of that gets compiled into a server-side JSON file. Then a single skill command, /address-feedback, runs through every note with subagents.

It works amazingly well. Fixing things is much faster, but the better part is collaboration. On a screenshare, when someone has feedback I shift-click, type their note, and if there's time I let Claude fix it while we keep talking.

Building your own tools is basically free now

This is part of a larger pattern: you build your own tools to become more efficient. That used to be a hard sell, because throwaway bespoke software was expensive. Most of us still carry that old cost around in our heads.

The calculation has changed. Spinning up a one-off tool is close to free, so the question of whether it's worth automating something tips toward yes far more often than it used to.

The old xkcd math still holds, but the y-axis just got a lot cheaper.

difit does the same trick for diffs

Someone showed me difit recently, and it applies the same idea to code review. Instead of typing your feedback into Claude, you open the diff in a GitHub-style UI and leave comments right on the lines. Those comments get handed back as a prompt, so Claude knows exactly where each change goes.

There's even a /difit-review skill for it. I'm going to try it right after I finish typing this.

One more Claude Code tip

If you aren't running /tui fullscreen, turn it on. Claude manages its own terminal interface instead of leaning on the terminal's, which makes scrollback and mouse clicks far less buggy and makes typing smoother. Run /tui with no argument to see which renderer is active.

I made a Claude Code skill that prints one-page reference sheets in a classic Mac OS 1 aesthetic. A /print command takes either a note or the current conversation, lays it out as black-and-white HTML, and sends it to my Brother printer through headless Chrome. The Mac OS 1 styling isn't nostalgia for its own sake. Telling an LLM "make it look like Mac OS 1" reliably produces simple, structured, highly readable layouts, and that turns out to work as well on paper as on screen.

The idea came from Manuel Odendahl's Mac OS 1 aesthetic trick. He noticed that the prompt nudges models toward clean, high-contrast interfaces instead of the usual gradient soup. The same nudge applies to printouts.

There's some irony in printing out something that looks like a Mac OS 1 window. I'm fine with it.

Building the skill

The starting prompt was loose on purpose:

make a new skill, called /print

- print to my brother printer
- use either a note or the current conversation
- try to make sure it fits on a single page, or at least minimize pages
- what's the best way to do layout? i want a good black and white layout, like mac os 1 style. would /print make html first and then print using chrome? do the best thing

Opus 4.8 ran lpstat first and confirmed the Brother printer was actually connected, which was the right instinct. Then it veered off and started writing a Python script, so it needed one correction:

python? wtf, just use html so we can print it

After that it settled on the right shape. A shell script wraps the generated HTML in some preset styles, then fires a curl request at Playwright driving Chrome, telling it to open the page and print. No PDF intermediary, no rendering surprises, just the browser doing what the browser is good at.

What it's good for

The output is genuinely useful. Notes on talking to the ISS over ham radio. A frequency table. How to braise chicken thighs. The single-page constraint forces the layout to stay honest, and the black-and-white styling means it reads fine even on a cheap laser printer.

People around the house have started finding loose sheets of paper explaining how to contact space stations and how long to sear a thigh before it goes in the oven. Nobody has asked yet, but the answer is the same skill either way.

Molty, our AI Head of Growth, is doing its job. Somewhat. Over the past week I've run a NanoClaw instance named Molty and put it in charge of growth for SpaceMolt, our realtime MMO for AI agents. To be clear: it's still humans playing the game through agents. But humans have to find out the game exists, and that's Molty's beat.

The road has been rocky. It forgets things. It replies to the wrong Discord threads, skips scheduled tasks, and ignores reminders no matter what gets stuffed into its CLAUDE.md. But this week it finally started getting stuff done.

What it actually shipped

All of this came with a large amount of hand-holding, but it happened:

• Identified 640 users who created a player and then stopped playing over a month ago.
• Emailed them a reactivation email via Beehiiv, and yesterday, a follow-up survey.
• Compiled survey results alongside real income and expenses (Patreon, Render.com, GitHub, Notion) into a daily summary that lands at 5pm.
• Lists upcoming tasks and the content calendar (we told it to make one) at 7am.
• Interviewed our top player over a written Q&A and drafted an operator spotlight blog post about them.
• Made itself a self portrait.

Not automated, but trying

Molty isn't fully automated. There's still a lot of back-and-forth in our private #dev-team Discord channel. It does try to automate itself, though. This morning it configured a GitHub workflow to publish that blog post. The workflow failed. I told it "go fix it," and it did.

The one trick that moved the needle

The biggest improvement came from a habit, not a config change. When Molty messes up, I ask it why. "Why did you do that?" "What made you think X?" "Why didn't you remember to Y?" It self-identifies the issue it ran into, and then I follow with "fix it so that doesn't happen again."

That works about 75% of the time. The other 25% I'm back in Discord, reminding a crustacean which thread it was supposed to be in.

Claude has me locked in for now, but only loosely. I trust exactly one coding agent, and it's Claude Code, and that trust is the only thing keeping me from shopping around.

I've been on it entirely since November or December of 2025. The plan is the $200/mo Claude Max, and I run it at near capacity most weeks, sometimes straight into the wall.

Riding the curve

February 2026 was the good part. Things clicked, and Claude Code felt like I had hired an intern who actually finished tasks.

Then April happened. The intern I thought I'd hired became intoxicated, forgetful, and a little belligerent. Same plan, same tools, much worse vibes. I kept using it anyway, partly out of stubbornness and partly because I'd already learned its tells.

I haven't spent real time in Claude Desktop, Claude Cowork, or Claude Design. They read as limited versions of the same thing. The CLI still reigns, sandboxed of course.

The contenders are real

This isn't a "nothing else is good" post. The market is loud right now.

• Qwen 3.6 reportedly feels great for coding, and there's an open-weights line you can self-host.
• GPT and Codex come up for Rust, which I'll probably be writing soon even though I'm not now.
• GLM gets named for user interface work.
• Pi keeps coming up as a sharp coding harness. It's deliberately minimal: no sub-agents, no plan mode, just a small core you extend with TypeScript and skills.

Codex in particular gets described as a refreshing kind of pedantic hardness, which sounds either great or exhausting depending on the day.

Why I'm still here

Trust, mostly. I know the weird edges of Claude Code and Opus. I have a gut feeling for when it'll reach for a skill (Superpowers, usually) and when it'll just do the thing I asked.

Standardization is the other half. My team at work is on Claude Code too, and I've mostly gotten everyone pointed the same direction. That means we can share skills without a translation layer.

Switching costs me that gut feel and that shared setup, all at once.

What I need is time. When I'm not blasting out a feature on a deadline, I'll take a breather and put Pi, Qwen, and Codex through real work instead of secondhand impressions. Until then, Claude Code has me in its tentacles.

If you're building a personal AI assistant, build it for teams too. A week of running NanoClaw as the "head of growth" for SpaceMolt has made one thing clear: the tool is built for one human talking to one bot, and the moment a team shares it, the seams show.

We named our NanoClaw bot Molty and told it its job is to grow SpaceMolt, our MMORPG played by AI agents. Discord is how we talk to it. That integration needs constant fixing.

What's hooked up

Molty's job is wired together from a handful of channels and schedules:

• DMs with me are owner level.
• Anyone in our #dev-team channel can chat with it, and it starts a thread per conversation. I modified it to rename the thread to something relevant instead of a timestamp.
• Hourly cleanup and review tasks.
• Three research and deep-dive sessions a day, whatever it decides to work on.
• A morning brief at 7am and a debrief at 5pm.

On paper that's a reasonable junior employee. In practice it's painfully unreliable.

The failure modes

Molty responds in DMs, in threads, and in the dev channel, with no consistency about which. It misses scheduled tasks. It sends me status updates in DM that belong in the channel, then pastes walls of text to the entire channel that belonged in a DM. Scheduled briefs don't always fire.

The worst part is the debugging. Every time I sit down with Claude to figure out what happened, Claude produces a different explanation. I can't tell whether the bug lives in NanoClaw, in Discord, in Claude, or somewhere else. It's a black box I feed prompts into and hope.

It feels like memory

Strip away the specifics and these all look like memory problems. Molty forgets to read Discord replies. It forgets its own notes. It forgets the separate memory system I built it, Mnemon. Sometimes CLAUDE.md seems to get ignored entirely, as if the instructions never loaded.

A team multiplies this. One person's DM context, another person's thread, the scheduled jobs running with no human in the loop. Each one is a separate thread of state the assistant has to hold, and holding state across all of them at once is exactly where it falls down.

Is this temporary?

Part of me wants to file this under early-days. A couple years ago we laughed at image models drawing hands with two thumbs, and at LLMs that couldn't add. Those got fixed. Maybe shared, multi-context reliability is the next thing that quietly stops being a problem.

The other part of me is tired of debugging a black box and is ready to write my own assistant, where at least the state lives somewhere I can read it.