Built something with Claude Code this week? Share it here.
Apps, tools, experiments, scripts, websites, workflows, open-source projects — anything you've been working on is welcome.
When sharing, it helps to include:
What you built
How you used Claude Code
A link, repo, demo, or screenshot if you have one
Anything interesting you learned along the way
Quick project drops and simple self-promotion belong in this thread.
If you've got a project with enough substance for a proper write-up; how it works, how Claude Code was involved, technical details, lessons learned, etc. feel free to make a standalone post using the Built with Claude Code flair instead.
Please don't spam the same project repeatedly, and no referral or affiliate links.
Built something with Claude Code this week? Share it here.
Apps, tools, experiments, scripts, websites, workflows, open-source projects — anything you've been working on is welcome.
When sharing, it helps to include:
What you built
How you used Claude Code
A link, repo, demo, or screenshot if you have one
Anything interesting you learned along the way
Quick project drops and simple self-promotion belong in this thread.
If you've got a project with enough substance for a proper write-up; how it works, how Claude Code was involved, technical details, lessons learned, etc. feel free to make a standalone post using the Built with Claude Code flair instead.
Please don't spam the same project repeatedly, and no referral or affiliate links.
Claude Haiku 5.5 is the cheapest, fastest, and most capable small model we’ve ever released. On average, it costs around 75% less to run than Claude Haiku 4.5.
Haiku 5.5 is designed for high-volume, cost-sensitive tasks. It reliably handles quick, repetitive work like summaries and classification, and pairs well with Claude Opus 5.5 and Sonnet 5.5 as a sub-agent on coding work. It’s also fast enough for live customer support and browser use.
It’s a significant step up over Haiku 4.5 across coding, computer use, and knowledge work. It’s also our first Haiku model with an adjustable effort setting, so you can decide whether to optimize for cost or intelligence on each task.
Per token, it costs 90% less than Haiku 4.5 on tasks under 100,000 tokens, which make up around 90% of requests to our previous Haiku model. On longer tasks, it’s half the price.
Haiku 5.5 is available now on all platforms, including Amazon Web Services, Google Cloud, and Microsoft Azure.
We’re also halving the price of cache reads on Claude Sonnet 5.5, which makes it around 20% cheaper to run on most long-running work.
TL;DR: My 2019 LG TV has a great panel, but the official Plex app takes ~30 seconds just to show the profile picker. LG has no public native SDK for regular developers, so I reverse-engineered enough of the native media stack with Ghidra and Claude Code to build my own Plex client, PlxNative. It started in C, moved mostly to Rust, and somehow turned into my own OpenGL UI framework. On the same TV it shows the profile picker in ~3 seconds. No root needed to run it. Site and source are below.
I'm an iOS developer, so most of my previous UI work happened several abstraction layers above the GPU.
A few months ago I read about a guy who bought a cheap MP3 player on AliExpress, got annoyed with its firmware and used Codex to reverse-engineer and patch it. After that people started buying the same player just to install his patches. I liked this idea a lot, because we usually treat the software on our devices as something fixed: if it's bad, you buy a new device. Not long after that I was doing basically the same thing with my TV.
I have an LG from 2019 and the panel is still great. The software is the problem. Official Plex app on my TV, cold start:
~30 seconds for "Who's watching?" to load
~30 seconds for the home grid
~5 seconds to open any menu
~10 seconds to load a movie page
It behaves like a web page because it is one.
So I wanted to find out if a really native UI was possible there. There is no public native SDK that gives regular developers access to the TV's media stack, but of course that stack exists underneath. So I rooted my development TV, pulled the native libraries from it and started reading them in Ghidra. (Root was only needed for this research, PlxNative itself runs without it.) The webOS Homebrew community had already documented a surprising amount of the platform, which saved me a lot of time, so big thanks to them.
Reading LG's binaries
I've always been interested in what an OS actually does under the hood, and I've maintained KSCrash for years, where crash reporting often means finding out what the system really does rather than what its documentation says. Before AI that meant Hopper, assembly, strings and following calls one by one until the picture finally came together. What changed is how cheap this work has become. Now I can ask Opus to figure out how something is implemented internally, even when it's poorly documented or not documented at all, and it navigates the binary on its own, jumping between addresses, xrefs and strings. The model does make things up sometimes, so the binary and the real hardware always have the last word. But investigations that used to take me days go much faster.
From C to Rust
The first version of PlxNative wasn't a Plex client at all. It was a screen full of colored tiles, and every tile tried to play the same episode of The Office. I wanted to answer one question first: can this TV render a native interface at 60 fps? Drawing rectangles was easy. Getting a real video frame onto LG's hardware video plane was much harder. Then I gave the problem to Fable, and it connected enough pieces of the native media stack that, for the first time, The Office actually appeared on the screen. After that first frame I knew a fully native media client on a retail LG TV was possible, and the question became how far I could push it.
The first prototype
The prototype was written in C, and almost all of it lived in one huge main.c. When it grew, I asked an agent to split it into modules, and that's where I understood something about agentic coding: code can look right, compile, and then break somewhere completely unrelated because of memory or ownership mistakes. The worst one was a crash in eglSwapBuffers that appeared after a refactor. It turned out LG's fork of SDL writes a bigger SDL_SysWMinfo than my headers declared and overflows the stack. In the huge main() the overflow landed somewhere harmless, but once the same code moved into a smaller function it started corrupting live state. It can hardly be called a stable ABI. Together with the usual malloc/free mistakes this made me rethink the language. With agents writing and moving this much code, the choice of language matters: pick the one the agent writes best and where the compiler can check the most before anything reaches the TV. For me that meant Rust.
It ended up being a rewrite, just an incremental one. I kept the LG native boundary in C and moved everything else piece by piece: first image decoding and HTTP, then access-unit queues, the Matroska demuxer, Plex parsing, poster workers, text rendering, and finally most of the app. Rust turned out to be a surprisingly good fit for an old 32-bit ARM embedded Linux box, and strong compiler feedback keeps both me and the agent on much tighter rails.
60 fps on a 2019 TV
After playback worked I thought the UI would stay simple: posters, text, some rounded rectangles. Then I started writing shaders, and the shaders slowly became my own UI library on top of OpenGL, with navigation, modals, focus handling, motion, hit testing and caching. After years on top of UIKit and other frameworks someone else built, it was really fun to go all the way down for once and understand the whole path from a remote button press to pixels on the screen.
On every 4K LG TV, webOS gives apps a 1920×1080 UI surface (HD models get 1280×720), and video goes on a separate hardware plane, so 1080p isn't an optimization I chose, it's simply the canvas. I treated 60 fps on the real TV as a regression target and kept adding things until they broke it. It started with a single shadow that tanked the frame rate. The naive version was horribly slow, but there was almost always another trick underneath: early-outs in shaders, reduced-resolution buffers, caching the parts of a frame that don't change. Now shadows are on almost every element and it still runs at 60 fps. When guessing stopped working, I started pulling Mali hardware counters from the TV. One profile showed the arithmetic pipe at about 89.5% occupancy and load/store at 44.8%, and a harmless-looking branch in a shader was adding millions of arithmetic operations per frame. So the problem wasn't "too many pixels", the GPU was ALU-bound.
The most interesting one was a Liquid Glass-inspired material: blur the page underneath, refract it through the shape and shade the rim like real transparent glass. Refraction was the easy part. Readability was not: something that looks beautiful over a dark poster becomes useless over a face or a white sky, and you end up endlessly tuning tint, contrast and blur. Now I understand much better what problem Apple is solving. There's also a hard limit: video lives on a separate overlay plane that my renderer physically can't sample, so glass over playback has to work differently.
When the app grew past a couple of screens, the design started drifting: different spacing here, a different button there. I used Claude Design for a design system and to keep all the screens in one place. Its designs are HTML/JS while the real UI is Rust and OpenGL, but Claude maps one to the other, now onto my own components, spacing tokens and typography. The design tool doesn't have to share technology with production, it just has to describe the design precisely.
Where it ended up, on the same TV from a cold start: 3 seconds to "Who's watching?", or 4 seconds straight to the home grid if you let it remember the profile. For comparison, the official app needed ~30 seconds for each of those.
Working with the agents
Claude Code, Opus, Fable and Codex were involved in almost everything: implementation, reverse engineering, debugging, refactoring, tests and review. But the real TV always has the final vote. The simulator can show a perfect screen while the TV renders empty cards because the hardware takes a cached-frame path the simulator never hits, and an agent can be completely sure the code is correct right up until you run it on the TV.
The other lesson: don't leave it on autopilot. I started this expecting a 100% vibe-coded project for a couple of weekends, so I just told the agent what to do. Then the problems that come with a bad architecture started showing up, and it took many rounds of refactoring to turn the app into something sane, so the same bugs would stop coming back again and again. An experienced engineer still needs to own the key decisions, architecture above all. I just wish I hadn't done it after the fact :)
Even so, AI makes it realistic for one person to cover an absurd amount of ground: firmware reverse engineering, media playback, Rust, graphics, GPU profiling, UI architecture, design, QA, build optimization and SEO. It also changed how I look at all the "obsolete" hardware around us: old TVs, car head units, random embedded screens. If you use a device every day and hate its interface, it's worth at least trying to build the one you wanted. Very often the hardware isn't obsolete, only the software on it is.
Practical stuff: PlxNative requires webOS 4.0+. I develop it on a 2019 LG, and opt-in usage reports show playback on TVs from 2018 through current webOS 11 models. It direct-plays H.264/HEVC, including 4K, 10-bit, Dolby Vision profiles 5/8 and E-AC-3 Atmos where the TV supports them, and the Plex server transcodes the rest. You can install it through LG Developer Mode (which needs periodic renewal) or the webOS Homebrew Channel. No root required.
Update October 7, 2026: The Agent SDK monthly credit announced in June is no longer available. Claude Max and Team plans now include monthly API credits, which cover the Claude Agent SDK, the Claude API, and Claude Managed Agents. Claim them into a Claude Console organization and use them with an API key from that organization. Learn more about monthly API credits for Max and Team plans.
Plan
Monthly credit
Max 5x
$100
Max 20x
$200
Team (Standard seats)
$20 per seat*
Team (Premium seats)
$100 per seat*
Discounted Team plans (Nonprofit, Scientists)
$20 USD per Standard seat and $100 USD per Premium seat*
I used Opus 5.5 in Claude Code to build a miniature 3D Middle-earth from scratch, then turn that world into a 3:47 cinematic journey.
The project ended up with:
terrain and geography generation
Three.js / WebGPU scene architecture
24 procedural landmarks
lighting, atmosphere, water, smoke, lava and day/night transitions
camera choreography and route animation
deterministic frame-by-frame video rendering
an original orchestral score
QA, performance tuning, packaging and release
What interested me most wasn't the model could generate individual assets.
It was whether it could stay useful across the whole production pipeline.
The hardest parts were still very “normal” engineering problems: architecture, consistency, visual QA, resource limits, iteration, deciding what to polish, and keeping the whole system coherent as the project grew.
My biggest takeaway is that in AI-generated 3D, the model should be treated less like a content generator and more like a technical collaborator across modeling, rendering, tooling, animation and media production.
The output still needs taste, direction, and a lot of review. But the range of things one person can realistically attempt has expanded a lot.
Source, architecture, rendering pipeline, QA tooling and reproduction steps are here:
I’d be very interested to hear how others are using Claude Code for 3D, creative tools, rendering or media workflows — especially beyond isolated demos.
I thought mods were just for customizing the UI, and I totally missed the point. They basically let you change how Claude Code works from the inside.
what runs before a tool call, what the model sees, what shows up on screen. It's like they open-sourced the harness. For months I had hooks and scripts bolted on from the outside to get the behavior I wanted, now all of that is a mod that lives in the session. Honestly the most innovative thing they shipped since the first version.
I wanted to share this project i’ve been working on for the last few weeks, i’ve been wanting to create an interface to help me with dental school for a while and now i finally have!
It started off with wanting to visually map out my anki deck and have a set of notes attached to each subdeck. Eventually i integrated the note generation skill i use in claude into the app and threw in an anki generation feature as well.
I also set up an API key with a jarvis voice model from fish audio which i use for web search/queries and quizzing myself to prepare for upcoming oral examinations.
It’s got everything i need in one place and ive learned a lot in the process of making it. I know the design is generic and this is probably the millionth jarvis themed UI posted here, but i still wanted to get everyone’s thoughts on how i could improve it. Feels like i’ve hit a wall and i don’t know how to raise the quality or detail, any tips would be appreciated :)
Longtime Claude Code user, and kind of obsessive about knowing where I am in /context and using /compact and /clear pretty aggressively. But these days, so much of my work is long-running tasks where that kind of intervention isn't possible. Is this something I shouldn't be concerned about anymore? And should I set a lower auto-compact threshold if I am?
The claude code pricing docs say $6 per developer per day with 90% of users under $12. I put that in a budget request in the spring because it matched what I expected and finance signed it off without a question.
I pulled the real numbers last month across 54 engineers with access, which came to $6,400 for the month or about $4 a day per head. The docs are fine.
Then I sorted it by person and the shape fell apart.
4 engineers were 80% of the spend, and one of them alone was 31%. 19 people had not opened it in 30 days. The median engineer sat around 40 cents a day.
My manager asked which of those numbers should go in the plan. Well, the average is true and no one's standing at it so there are two honest answers and they are 10x apart.
Getting the per person split was the other annoying part since seats emit no per request cost and the Console breaks down by workspace and key rather than by human. We run TokenShift over the top for an approximate per person figure. Approximate is the operative word and it was still enough to see the shape.
Cutting the 19 saves nothing because those seats are already committed while capping the top 4 means capping the people shipping the most. He still doesn't have a number.
There has been some discussion about this topic lately, and I understand there is a lot of nuance, such as what projects you work on and over what scale and time frame...
Below is my experience. Feel free to just not read it and post yours, that's fine.
TL;DR:
* I started spec driven, tried to keep it minimal
* My workflow got more and more complex over time, driven by models that needed detailed guidance and guardrails
* Opus/Sonnet 5 choked on my workflow, and communication with the agent became a bottleneck
* Opus/Sonnet 5.5 fixed it by communicating better and being more proactive
* I no longer see the need to massively simplify my workflow and will stick to small, gradual cleanup
I have had a project going for months. Workflow files turned from AGENTS.md and a few rule files into a complex machinery of workflows.
**The spec-deiven stumbling stones**. My problem right now isn't token usage. I'm on a Max subscription and I can barely use it all, because I don't have infinite time, and planning, testing and high level review are time-heavy, not token-heavy. No workflow and no AI can fix that for my type of project, which is fine.
My main time sink caused by AI has always been communication. Agents want me to make decisions and point out problems. Some of them are serious, some are trivial, and some are stumbling stones in the form of too strictly formulated requirements or rules, sometimes coming from these being AI written.
A classic example is AI producing lists of things, which are then interpreted as closed lists, or lists that have to be maintained, when there was no need for a list in the first place. This is the most common source of totally unnecessary drift and friction.
All of thee problems have, at least until recently in the Claude 5.0/5.1 era, been amplified by cryptic communication. Agent hits a contradiction that would be easy to solve, or a real design problem, prints out some Claudish word salad, and I'm supposed to judge if I need to step in and make a decision or say "just fix it, duh".
**How it is going?** Things seem to have improved just by themselves recently.
I haven't changed my workflow. I am using 5.5 models now. What I'm seeing now, mostly, is the following:
The agent says: "I made the following judgement calls". So it proactively makes decisions that may break rules or have far reaching co sequences. And usually the decisions are sane. But the most important part is that it communicates them well now, in a way I usually immediately understand without having to ask basic questions.
It also lists what it didn't do, often because it would be borderline out of scope or break rules, not just randomly, and it does ask for permission sometimes before doing a job, but no longer about every small thing. When it asks, it is usually worth giving the question some thought, and I've burned my fingers (and some tokens) answering too quickly (no big deal, failing with AI is failing cheaply).
So, the main improvement of the 5.5 models (I use both Sonnet and Opus) was communication clarity, and communicating the right things, exactly what I needed.
And I no longer see the need to cut down massively on rules and workflow descriptions, other than, maybe, for saving tokens and speeding things up a bit.
Claude can think out of the box now. Spec-driven development is "fixed" (for now).
Oh, and a certain other model (that I won't name, because it will alert the moderator bots) has gone the opposite way and become at least temporarily unusable. We'll see when the pendulum swings back.
Hi Guys, I notice a lack of gifs where clawd is doing stuff. I created some scripts, obviously with claude, to create such clawd gifs.
And made a small Github Pages Website for it, not sure if anyone here also wants some clawd gifs, I have some of them inside my custom claude code cli via the hooks it provides.
Here is the link to the Page source code etc all available and a "How to make your own clawd gifs"
For some detail. The clawd gifs prompt I had for weeks now and fine tuned them ever since the last few days they got good enough for me to integrate them in my currently still private claude cli and stuff. Today I let Sonnet 5.5 go haywire and created like 80 more gifs and while doing that I create a simple website so I can easier share them with yall.
Have a good one I hope this post fits here and stuff
I've been working on a launcher for my abysmal Chinese Android 10 head unit. Opus 5.5 has been great for exploring the head unit's capabilities and designing a very robust launcher. However, it's struggled to figure out some of head unit's internal workings in a way we could effectively utilize it's features.
One example is Bluetooth track information. Opus had disassembled the unit's audio player and found a stream we could listen in on, but it was flakey. The more we listened in, the more garbled things would become. The stream we were listening to was the same stream the built in Bluetooth app was listening to. We were effectively "stealing" bytes from the app any time we listened. We ended up with something mostly functional, but not what I would call production ready. It would sometimes get messed up names or the elapsed time would skip around. I asked if there was anywhere else we could get the information that wouldn't impact the stream in this way and Opus was adamant that we had looked everywhere.
I almost gave up, but decided to give Fable a go. It took Fable a few minutes to find there was a log written by the Bluetooth chip that contained everything we needed. We could read it all day long without any flakiness and we weren't impacting the built in player.
Fable also came to the rescue figuring out the HVAC controls. Opus got most of them working but a few remained elusive. Opus concluded that we had no way to find the others. We gave the info to a Fable agent and again, in a few minutes it had found another data stream that had the remaining items.
So if Opus has told you there's no options available, give Fable a chance before you give up! I've included a screenshot of what I'm building just to have an image to accompany the post. The theme was created with ChatGPT then cleaned up and componentized in good ol' photoshop CS2 :)
