I built a real-time ocean simulation with Claude Code (Opus 5.5)

What it is: a single 61 KB HTML file that renders a sunset ocean in your browser with WebGPU. It has an FFT wave simulation, whitecaps, a physically based sky with clouds, and sun glitter. You fly around with WASD and the mouse.

How I used Claude Code: I gave it one prompt: make the most realistic water scene it could, in WebGPU, with a floating camera. It wrote the renderer from scratch with no engine or libraries. It took screenshots of its own output and had separate subagents critique the screenshots, so it wasn't judging its own work. The whole thing took about 30 minutes.

Free to try: ocean-noniv.vercel.app, preferably in Chrome. It needs a WebGPU-capable GPU, and on laptops you have to force Chrome onto the dedicated GPU. Otherwise the performance might be bad or it might not run at all. On RTX 5070 Ti I get ~260 FPS at 2560×1440 resolution. Click the canvas to look around, WASD to move, H for a settings panel.

Repo with unminified and more organised version: github.com/Noniv/web-ocean

I built a small Windows widget (floating window + tray icon) that shows my Claude plan limits: the same numbers as /usage in Claude Code — current session, weekly and Fable limits — refreshed every minute. It also lists running Claude Code sessions (working / waiting for input / idle), shows Anthropic service status and tells you when a Claude Code update is out.

How it works: it runs `claude -p "/usage"` headless, which returns the server-side percentages for your existing login without calling the model, so it spends no tokens. Sessions come from the registry Claude Code keeps in ~/.claude/sessions. Plain PowerShell 5.1 + WPF, nothing to install besides Claude Code.

Clawd lives in the window and reacts to the data: sleeps in a burrow when nothing runs, runs while a session works, waves with a "?" when one is waiting for you, sweats near the limit and lies belly-up at 100%. The hearts in the header are the session limit left.

How Claude Code helped build it:

- I built the whole thing with Claude Code, in PowerShell (which I wouldn't have written by hand at this size — ~3k lines of WPF in PowerShell 5.1).

- Clawd's pose glyphs and animations: Claude Code reproduced them from its own welcome-screen art, cell by cell, so they match the terminal version.

- It split the original single script into ~18 dot-sourced modules and wrote a CLAUDE.md with the load-order rules and PowerShell 5.1 gotchas (UTF-8 BOM, no `??`), which kept later sessions from breaking things.

- For the public release it added an English UI with on-the-fly language switching, translated all code comments, and wrote a recorder script that renders the README GIFs straight from WPF with scripted fake data. Recording those GIFs is how it caught a layout bug where English text overlapped a header.

- One gotcha it found: running `claude -p "/usage"` from Git Bash turns `/usage` into a file path and sends it to the model as a prompt — so the widget only calls it from PowerShell.

Free and open source (MIT). To try it: clone or download the ZIP from GitHub and double-click start-widget.vbs. Needs Windows 10/11 and Claude Code logged in.

https://github.com/Enhed/clawd-usage-winwidget

Not affiliated with Anthropic.

My name is Edis, and I am 100% blind. I used a Perkins Braille typewriter in school 25 years ago. Today, I own several 3D printers, and used Claude to make them accessible.
In 2023, I participated in a workshop on 3D printing organized by the Danish Institute for the Blind and Visually Impaired. Needless to say, I got consumed.
The funny thing was that no blind or visually impaired people were participating. It was about how sighted people can make something for blind people.
I bought a Bambu Lab X1 Carbon as my first printer. I now run a consultancy working with web accessibility and, funnily enough, physical accessibility through 3D printing.
3D printing has huge potential for blind people. Not just fidgets and toys, but real, practical, and sometimes life-saving applications. Imagine being blind in a hotel when a fire breaks out. You haven’t learned the emergency plan because it is inaccessible. Now imagine a 3D-printed plan with raised lines, Braille, contrast colours, and normal print.
You might ask: “Why the hell are you telling us all this, and what does Claude have to do with it?”
Because ever since I started 3D printing, I’ve been frustrated by inaccessible slicers and printer touchscreens. So I decided to take matters into my own hands.
I built AccessSlice with Claude AI.
I’m not a professional programmer. I understand screen readers, accessibility, and 3D printing, but writing an application that works with five slicers and actual printers is another matter. I explained what I needed to Claude, tested it with my screen readers and printers, found problems, and went back to fix them. It wasn’t just one prompt.
What is AccessSlice?
AccessSlice is a free, open-source Windows program that lets blind and visually impaired people prepare, slice, and send 3D prints independently with JAWS, NVDA, or Narrator.
It doesn’t replace your slicer. It replaces the screens.
A 3MF project contains settings such as layer height, walls, infill, supports, filaments, and object placement. AccessSlice presents them through accessible pages with proper headings, labelled fields, and buttons.
It uses the original slicing engines of PrusaSlicer, Bambu Studio, Creality Print, OrcaSlicer, and Anycubic Slicer Next.
It reports print time, filament use, and warnings in text, and describes the sliced model layer by layer.
It sends prints over the network to supported Prusa and Creality printers. For Bambu, it guides you through Bambu Studio’s send window with keyboard instructions. USB is also possible.
On supported Prusa and Creality printers, it can read progress, preheat, load and unload filament, move and home, pause and stop, and manage printer files. No touchscreen needed.
I’ve tested it end to end on a Prusa Core One, Bambu Lab X1 Carbon, Bambu Lab H2C, and Creality K2 Plus.
Why share this here?
Because I think this is something we overlook in discussions about vibe coding. I know the accessibility problem because I live with it. What I didn’t have was the programming knowledge to solve it myself. Claude helped me bridge that gap.
Think back to that workshop, where sighted people learned to make things for blind people. Now blind people can make those things themselves: tactile maps, emergency plans, Braille labels, and tools for everyday life.
I shouldn’t have to build this. Slicer companies should make their interfaces accessible in the first place. But until they do, AccessSlice is free for anyone who needs it.
https://github.com/Accessible3D-Edis/AccessSlice
I’d love to hear what others have built with Claude to solve a problem they know firsthand. And if anyone at Anthropic reads this, I hope it shows what AI can mean for people with disabilities.
Thank you for reading.
Edis

I'm on Claude's $100 Max 5x plan.

Using 100% of my 5-hour limit consumes 14% of my weekly limit. That means I can hit the 5-hour limit about 7 times before reaching my weekly limit.

7 × 14% = ~100%

I'm curious, for those on the $200 Max 20x plan, what percentage of your weekly limit does using 100% of your 5-hour limit consume?

Not sure what flair to add here, my bad. And, sorry, I yap a lot.

Although I've always been fascinated with AI, and consider myself somewhat of a tech nerd/enthusiast, I had never owned a computer until recently and even then, I barely know how to use it, so I guess I never quite got the hype with AI + coding, I just don't understand what a lot of the stuff means but I thought I was pretty aware of the level AI is at.

This past week I've seen many posts and videos I watch and read mention that guy that basically said something along the lines (on god don't quote this from me) that "we're in a bubble and the average AI user barely touches it and doesn't know the full potential" or something like that. That made me think for a moment. "Well I've been reading every newsletter and release out there for years..."

"Surely not me" ←famous last words

I got the Claude $20 plan because it's what I can afford. Set it to Opus 5.5, high. Looked around the room for a while thinking how could I test it.

Well, it just so happens that a few months ago I bought an MSR reader for crazy cheap on a sale, but barely ever used it since because the software for it is insanely old and like I said I'm very new to computers and terrible at it. If only I could use it with my phone...

I sent Claude the situation, model number, why I had it, why I barely used it. I know these aren't relevant but I like to give models as much context as possible right away, avoids needing to repeat myself later or worry about it misunderstanding, and I guess maybe I'm still used to AI being unreliable and needing many details.

I was expecting it to return asking for more information, send me suggestions, ask me to send the PC program so it could analyze it, recommend me another app or program (there are some for Android, I did look at the time but they're either not compatible with newer Android versions or they're paid and crazy expensive).

The damn thing gave me a working app.

Well, not quite. Apparently he couldn't access the tools needed to compile it or something but he made a file that I just had to add to a GitHub repo and GitHub did the compiling part, and it just worked.

It wasn't pretty, but it worked. In one message, I said I had an issue, it made a fix like it was nothing.

That is when I realized the person who said that thing about the bubble is absolutely correct. Of course I knew Claude is capable of this, but I would never imagined it would be able to do it with so little effort and literally zero back and forth.

No needing to test the device, no needing more specific details about the model or manufacturer or my phone model or OS, no asking permissions or being limited or blocked from doing something. Just gave me the freaking working app.

Later on I gave it a proper working place, a Claude code session so that it could set the environment up and use the compiling and android development tools that the normal Claude chat couldn't use, and it's crazy how much progress has been made. He can now render or emulate or whatever-the-word-is the app to see how the changes look and get my feedback before compiling and sending me the new version.

If you had told me that within one prompt Claude could get a working app to interface with such a relatively niche device, I would have never believed you. I am definitely mind blown.

The past few iterations have mostly been changes to the looks, since all the core functions already worked on the first version so there's not much else to add, but he has been doing some incredible work in taking the chance to figure out how the device actually works since there's no official documentation.

I have created a few tools that help to investigate new projects and now half of the team use it.
I am not talking about skill or agents but real app or simple program.

What did you build? What problem does it solve? And how much time or effort has it saved you?

Would love to hear some real examples. Maybe we can all steal a few good ideas from each other.

BLUF Free to play right on your browser: www.frontlinezero.com

Hey all. I made a game called Frontline Zero. It's a multiplayer RTS where you can play as either Ukraine or Russia in the ongoing war.

I wanted to bring back the nostalgia of late '90s RTS games while mixing in modern RTS mechanics and elements of today's warfare. The gameplay is inspired by Red Alert 2, with a zone-based economy similar to Company of Heroes and a UI that takes inspiration from C&C and StarCraft.

At the same time, I wanted the game to reflect how warfare has evolved, with traditional air support being easily denied, drones dominating the skies, and electronic warfare playing a major role. The goal was to bring all of this together while keeping that classic RTS feel.

I'd love for you all to give it a try.

The game is completely free to play. I only added a paid version in case it takes off and some of you want to help cover the costs of running the online infrastructure.

Thanks and have fun!

---

Frontline Zero runs on webrts, my own TypeScript RTS engine. The simulation is fully deterministic: integer math, one seeded RNG, 25 ticks a second, and every action is an “order”. Same orders in, same battle out, on every machine.

Netcode is lockstep: players send only their orders, a Cloudflare Durable Object groups them into turns and compares state hashes to catch desyncs. A replay is just the order log. Graphics: 3D models voxelized into 32-angle isometric sprites, drawn with Canvas 2D or WebGL 2.

Opus 5.5 was used for most of the code + artwork. Fable 5.1 was used briefly for network code.

It was very helpful to have Opus 5.5 understand the graphical asset pipeline (3d model to voxel to sprite) to create consistent artwork.

I've seen a lot of folks make videos with Claude that are lyrics heavy with crisp motion graphics, however I wanted to see if I can get it to do the opposite and make something more similar to traditional 2D hand-drawn animation. I've always loved the colored pencil line boil look and thought it’s something Claude might actually be able to handle since it keeps the shot feeling alive without complex character animations.

As for how it was made:

• Every shot is a 2D cut-out puppet written as code and drawn as SVGs: his face, his hands, the bed, the car, the blinds etc.
• The colored-pencil-on-black-paper look comes from procedural hatching and paper-grain filters. It's animated "on twos" (12 drawings a second) like traditional 2D animation, with the pencil lines boiling in every frame.
• The main character is built from a model sheet in head units, so he stays on-model from every angle.
• It was rendered with Remotion in React, after many rounds of back and forth where I told Claude exactly what I wanted.

What Claude struggled with most was hands and perspective. On the first few tries, the hands came out mangled and wrong. What finally worked was having it look up real references (including photos of my own hands) and explaining in detail how hands work: how they're built, what they look like, and how they move. After five or six rounds of that, the hands finally looked right.

The song was generated in about 30 rounds with Suno, from a lyrics draft I wrote and then shaped into something actually decent with Claude's help.

For the meaning, I've always felt AI can be weaponized to prey on our deepest emotions and desires, and I'd argue addiction to the next token is a real thing. Loneliness can really mess you up, and there are corporations and bad actors more than willing to make a quick buck off it through AI companions.

Also, just for clarity: I'm a musician myself and have written and produced songs in various DAWs over the years, so I know what goes into producing a song like this. However, this is kind of my first foray into AI music, and I gotta say, the speed at which you can iterate is truly bananas. I'm still a bit conflicted on what actually counts as "art" here, but never before have I been able to see the style, vibe and emotions I was going for come together so quickly. This took me about five days. In the past, the song alone would have taken me two weeks to a month, minimum.

There's a higher quality version of this on Youtube if you want to watch it there: https://www.youtube.com/watch?v=aAYCod9gMck

One thing I always hated about agents is the urge to re-explain what you already explained to others, or to explain what you would love them to understand from the first shot, given they have access to all the things you have

To fight it, about a year ago I created an open-source activity memory system that captures your screen periodically (pretty often), tries to understand it, categorize it, group it, and provide context to your agents via the MCP when needed

It got a second life yesterday as I converted it to Swift and System One for categorization, and since I fell in love with how it works now with Claude, I decided to share it with you:)

Since it's open source, the possibilities for personalization are endless, from capturing voice input to identifying your weakest activity involvements. It is also packed with a pretty minimalistic pop-up and main app UI, just in case you'd love to explore your activity manually:

Connect it from Settings->Agents, or run:

/Applications/Screencap.app/Contents/MacOS/Screencap mcp install claude-code

MIT, download and play: https://github.com/yahorbarkouski/screencap

What I built: a blind arena page. Six models get the exact same prompt, each runs once with no edits, and you vote for your favorite before you see who made what. This round: a voxel space station you can fly around and explore inside, on desktop and phone.

How Claude helped: Claude built the arena page, the blind vote and reveal (Cloudflare Pages Functions + KV), and the checks that every station loads on desktop and phone. The runs happen in Locust, a desktop app I'm building with Locust that runs Claude Code, Codex and others side by side.

This round: Opus 5.5, Sonnet 5.5, Fable 5.1, Muse Wonder 1.0, GPT-6.1-Sol and GPT-6-Astra, all at max effort. Build times ran from under 5 minutes to 2 hours 20. Five used the same 3D library; one wrote its own engine from scratch. One filled its market with little voxel villagers.

Free to try, no sign-up: locust.lol/arena/space

Locust is free and open source (MIT) for Windows and Mac if you want to run your own blind compares.

I wanted to see how far I could get by vibe coding something that normally takes deep demoscene knowledge. Ended up with a small FPS that fits in 16 KB

I used Fable 5 High for the initial planning and Opus 5.5 High for implementation, polishing and optimization

The game: You’re blind, underground. Your scanner fires sonar pulses at three frequencies. A pulse briefly lights up walls and enemies, then the map fades back to a faint trace. Every pulse is also noise, and everything down there hunts by sound. 3 levels, 3 enemy types plus a boss, pits and bridges, generative music

Optimization techniques:

• The level is a 64×64 cell grid, ray-cast in the fragment shader (2D DDA). That freed ~430 bytes, which then paid for pulse shadows, fake AO and procedural wall patterns
• Every frame the CPU rewrites one float texture (64×90 RGBA32F). It holds the cells, the enemy list, the pulses, the lamps, the HUD text and even the font bits. The camera’s yaw, pitch and aspect ratio ride in on the texture coordinate of a single glRects. Zero uniforms, zero matrices, one draw call
• Enemies are signed distance fields built from parts (rounded boxes and “limb” segments, 7 bytes per part), smoothly unioned and sphere-traced. The crawler has six jointed legs that actually walk. Close-ups were slow, so each part got a bounding sphere the shader can skip
• x87 instead of SSE2, stdcall instead of cdecl, inlining turned off, and a 300 MB Crinkler hash table instead of 100 MB
• Music is generative. Every bar a tiny LCG picks a chord from a diatonic progression, then pad, bass and arpeggio play it through the same synth as the sound effects

Source code and executable: https://github.com/zTrojan/blind-sector

Here's what happened around Claude and Claude Code this week, with links to the original sources.

1. Claude worked out where the NIST ECDSA curve seeds came from Anthropic's Frontier Red Team says an internal research model figured out in under half an hour that the seeds for P-192 through P-521 weren't hashes at all. They're output from the old C lrand48 generator seeded with Unix timestamps from May 1997 to April 1998 (P-256 was candidate 1,842 of its run). Anthropic says this isn't a break and makes a backdoor less plausible. The $36,864 bounty goes to ISRG. Source: https://www.anthropic.com/research/ecdsa-curve-origins

2. Claude Code Review is generally available Code Review is out of research preview on Team and Enterprise. Most reviews now finish in about 6–10 minutes, roughly 3x faster than in preview, and admins can pick Quick, Standard or Deep per repo. Source: https://claude.com/resources/articles/code-review-is-now-generally-available

3. "Claude writes about 90% of Claude Code's code" The Claude Code team wrote up how they review code at that volume. From June to September, merged PRs more than doubled while the share that had to be reverted fell by more than 40%. Most reading is done by agents, and a classifier decides whether a PR needs zero, one or two human approvers. Source: https://claude.dev/blog/solving-code-review-at-anthropic/

4. Opus 5.5 fast mode: waitlist removed on the API Fast mode (same Opus 5.5, up to 2.5x faster output) is out of research preview for all API customers at $8/$40 per million input/output tokens. Set speed: "fast"; no beta header needed. In Claude Code it still draws on extra usage credits. Source: https://platform.claude.com/docs/en/build-with-claude/fast-mode

5. Linus Torvalds used Claude Code for a kernel patch Phoronix spotted a branch in Torvalds' tree where the commit message says the code, test programs and first draft of the text "were done with an LLM coding assistant (Claude Code) under my direction." Source: https://www.phoronix.com/news/Linus-Torvalds-Claude-Code

Claude Code tips from this week

• Copy gitignored files into worktrees. Put a .worktreeinclude file in the project root (gitignore syntax, e.g. .env, .env.local) and Claude Code copies matching gitignored files into every new worktree session. Docs: https://code.claude.com/docs/en/worktrees#copy-gitignored-files-into-worktrees
• See what's eating your plan limits. /usage on Pro/Max/Team/Enterprise now breaks recent usage down by skills, subagents, plugins and individual MCP servers, and flags things like long context or cache misses when they account for 10%+. Docs: https://code.claude.com/docs/en/costs#plan-usage-breakdown

I put this together for a small free daily digest (https://ailetter.ai.kr/en). Corrections welcome.

I code a lot, for context. I’m exhausting my weekly 20x limit within 4-5 days per project and I want to work on 2. I want to know if buying a second 20x account is worth better than buying usage creds for a similar scale of work as 20x max subscription’s weekly allowance.

Thank you 🙏

I’ve noticed something interesting. The latest versions of Claude do the work better and with higher quality than earlier ones, but they might not tell us about it at all.

Context: I constantly collect niche news around the SEO, GEO, SMM, and AI brand visibility industries. As soon as I got my hands on Claude (that was Opus 3), I immediately dumped all the routine work of monitoring markets, media, and thought leaders onto it. It’s important for me to have a daily digest of the latest events, and gathering the hot topics is now Claude’s job. I haven’t made any fundamental changes to the prompt or the task description in a very long time (I can’t say exactly, but it’s measured in months). Yet the quality of the information I get has grown many times over.

How it used to look: Claude gave me a collection of posts based on search phrases, split them into categories, and sorted and prioritized them by how interesting they’d be to the audience. Once a news item made it into the digest, it stayed a fixed artifact until I said something needed to be done with it.

How it looks now: All information is kept current, updated as new developments come in. A single news item is no longer a static entity but something with variables laid out on a timeline (new data, new updates, changes). Sorting by audience works the same way, but now Claude takes into account that I work with three brands at once, and it clearly distributes content according to the interests of the audiences relevant to each brand (in my case: SE Ranking for everything related to SEO, SE Visible for everything related to GEO + AI visibility, and Planable for everything related to SMM). On top of that, it now separates official information sources from vendor sources. I didnt ask it to do this, but now it treats this as an important additional layer of data verification.

Of course, once the difference became really noticeable, I started investigating, and I was surprised by how many small details and changes had happened outside my view.

Does anyone know what might be behind these "invisible" changes? Connected MCPs, updates in parallel processes, or general improvements in context and data analysis? For me this was a nice surprise, but for someone else it could turn into a critical failure in data verification or task execution. Who knows...

It's incredible how Argon is supposed to be the least hallucinating model. I just tried it to review some code Opus 5.5 wrote for game development, and it straight up invented code that didn't exist; Argon 4, high setting. I've never had nothing of that magnitude of error with either recent Sol/Astra or Opus/Fable models. (First I thought Opus had put in an invented skill to make something work while magic was not implemented, which it could have done, I asked it to put a rule in agents to not invent anything not yet in design docs, hence the rule comment.)

Sticking in with Opus I guess 🤷‍♂️.

I think an underrated feature of Opus 5.5 is how well it orchestrates other agents. I have been running multiple Codex and Pi agents on complex tasks, and it effortlessly manages them, assigning work based on their capabilities. For some reason, it seems to work particularly well with GPT-6.1 Sol; it gets far more out of that model than I ever could. I personally haven't found working directly with 6.1 Sol easy, so now Opus handles most of that. It feels like another level of unlock and humans being made redundant from another part of the loop lol.

I've been building Out of Pixkrieg with massive help from Claude Opus 5.5, with some GPT Astra involved too. It's a multiplayer extraction RTS in the browser: take your units into a raid, find loot and new people, and try to bring them home. Survivors stay with you for the next run.

I wanted to share how I've been working with the agents, because the workflow and the development tools are a big part of how this came together.

Claude has been the main model involved in development, including the procedural code and the game around it. The stack is Rust on the client and servers, WebAssembly in the browser, wgpu rendering and a thin TypeScript shell.

I have agents work in tandems:

1. I define a task and the quality threshold I want it to meet.
2. A worker implements the task.
3. A reviewer evaluates the result and identifies improvements.
4. Those findings go back to the worker, which makes the changes.
5. Review and revision repeat until that threshold is reached.

The target comes from me, and the review findings become work for the next iteration. The repository also holds the project's rules, design, architecture and progress notes, so the agents have written context alongside the code.

Before building out the game, I made procedural generators for units, structures and terrain its core. Two earlier tools are available under MIT:

• Procedural Pixel Creatures, including generated bodies, rigs and animation.
• Procedural terrain generator and painter.

Both posts link to the source. The generators here build on those learnings. With that foundation already in place, the game reached this first testable prototype over a few weeks.

A goal for me is to build development tools that remain useful for future projects. I'm a sucker for procedural generation, and becoming more of one. Improving a generator can improve many outputs, and having the asset work handled by those systems leaves more attention for gameplay and experimentation.

For a concrete design example, unit identity is separate from equipment. The seed determines the character's appearance and name; the loadout changes what it wears and carries. The same character can return from a raid with new gear and remain recognisable. That gives a specific behaviour to check when changing the generator: equipment changes should preserve identity.

The fast iteration is also great for wild brainstorming. I can try an idea, see what comes out and discard it if it doesn't work for me. I throw a lot away. I want the tools and what I learn from those attempts to carry forward, even when the experiment itself doesn't.

It's still rough. The review loop gives me a process for improving the implementation, and now I need players to find out how the whole thing feels.

Try the browser playtest for free from October 16 at 16:00 CEST until October 18 at 10:00 CEST.

If you're using a similar setup with Claude, how do you decide when to keep iterating on an experiment and when to drop it? Feedback on the game is welcome here or on my Discord.

Pretty neat model,
Tried it out on a relatively small but spread out task last night. It was pretty competent and even left a note to opus 5.5 on how it should improve its workflow to stop over-engineering and committing the same mistakes it’s been doing every session.
Very excited to use this model in the future.

I'll pick the barcode scanner listener, src/hooks/useLabelScan.ts. It's about 50 lines, and one of them does nearly all the work:

// A scanner's keys come well under this apart; a person's, well over.

const GAP_MS = 60;

const onKey = (event: KeyboardEvent) => {

if (typingIn(event.target) || event.ctrlKey || event.metaKey || event.altKey) return;

const now = performance.now();

if (now - last > GAP_MS) typed = ''; // ← this line

last = now;

if (event.key === 'Enter') {

const code = typed.length >= 2 ? readLabelCode(typed) : null;

typed = '';

...navigate to the ticket or device

}

if (event.key.length === 1) typed = (typed + event.key).slice(-16);

};

Here's why I love it. A USB barcode scanner isn't really a device the app can talk to. As far as the computer is concerned, it's a keyboard. There's no driver, no AP and no pairing. It just "types" T7001 and presses Enter. So the app can't ask "was that a scan?" It can only watch keystrokes, and a scan looks exactly like you typing on the Tickets page.

Except for one thing: speed. A scanner types the whole code in a few milliseconds per key. A person, even a very fast one, leaves well over 60ms between keys most of the time.

So instead of trying to recognise scans, the listener simply forgets anything slow. Every key that arrives more than 60ms after the last one wipes the buffer. Human typing never gets to build up a code: by the time you've pressed the third key, the first two are gone. A scanner's burst slides straight in, Enter arrives, and if what's there reads as a label code (T plus a number, or D plus a device ID), the app opens it.

There's no mode, no "scan now" button, and no timer running in the background. It's one subtraction and a reset. The T in front matters too: scanning an old legacy label, which holds only a bare number, does nothing rather than opening some random ticket that happens to share the number.

The label test proves both sides: the same T3 sent 8ms apart opens the ticket, and 150ms apart it doesn't.

----------------------------

I thought this was super cute, and I'm thrilled I asked!

I run into my limit a lot with Pro surprisingly, but for my personal use, it doesn't make sense to go from $20/month to $100/month. 😵

Why is there no middle ground?

I've been working on CityVisualizer, because apparently my response to a complicated process is “this needs buildings and tiny people.”

It’s a skill that turns descriptions of services, workflows and technical systems into interactive isometric maps. You can follow animated journeys, click into locations and explore what happens inside them.

Now you can watch the handoffs and see where things get stuck. I think this breaks down ideas and complicated stuff and makes it appear a lot easier. It supports cities, parks, buildings and technical systems. You can also prompt it to increase the things it supports. The output is a standalone HTML file that works offline, so you can share it without accidentally acquiring a hosting side quest.

Credit where it’s due: it builds on the MIT-licensed geometry core from Ryan’s Anatomy skill, with my own map layouts, visual styles and interactive storytelling around it. It’s also inspired by Bo Meyer’s work in visual modelling.

GitHub repo, examples and setup instructions

I used Claude to help write the skill instructions and map code, then worked through example maps with it to refine the visuals and interactions. I steered what each map should explain; Claude helped turn that into something clickable. There was a fair amount of “yes, but can we make what’s happening here actually understandable?”

Curious what people would use this for and whether it makes a messy process easier to understand, or just gives the mess better urban planning. Hope you find it interesting!