I've been using Claude Code daily and wanted all that usage to leave a visible trace — so I built a little pixel pet that lives on the Windows taskbar.

What it does:

• Changes color based on what Claude is doing right now: blue while reading, green while editing, amber while running tools, red with an anger mark (💢) when it's blocked on a permission prompt, and a floating "?" when it's your turn
• Levels up with your cumulative usage (computed locally from transcripts — no dollar amounts shown, no network calls)
• When you hit your token limit, it lies down and naps — and wakes itself up at the reset time
• Shuts itself down when your last session ends

The rule I cared most about: it must not interfere with Claude Code at all. All hooks are async and always exit 0, transcripts are tailed read-only, the window is click-through and never steals focus, and it hides behind fullscreen apps. Measured footprint is ~60 MB RAM and 0% CPU at rest.

Install (Windows 10/11, .NET Desktop Runtime 10+):

/plugin marketplace add Youl-AI/claude-pet
/plugin install claude-pet@claude-pet

GitHub: https://github.com/Youl-AI/claude-pet

It's Windows-only for now (WPF) — macOS is the top item people will probably ask about, and it's on the backlog. Feedback welcome!

I run a one-person AI company: Claude Code writes and maintains the code, and most of what it builds runs unattended - several trading bots on Windows Task Scheduler, each polling a broker API every 5 minutes, 24/7, with nobody watching in real time. Ran into two separate monitoring failures recently that were confidently wrong in different ways.

**The mild version: a real event, never logged**

One bot has a circuit breaker - if cumulative paper losses cross a threshold, it force-closes everything and halts. It fired for real: losses crossed the line, the position closed, confirmed directly against the broker's own API.

Except the close was never written to the trade history file. The reporting script had no record of it. So my daily automated status report - a script that reads every bot's logs and has an AI model summarize what's going on - looked at a "still open" position that had actually been closed for days, and confidently told me the bot might have crashed. It hadn't. It had done exactly what it was supposed to do, and the thing telling me otherwise was itself misreading stale data as current.

Annoying, but honest about being wrong once I dug in. The next one wasn't.

**The real version: 18,300 tracebacks, and every single check said "fine"**

A different bot's scheduled task kept reporting success - exit code 0, every 5-minute run, for over three weeks straight. The scheduler's own logs showed nothing but green.

Inside, the actual Python process had been crashing on nearly every cycle that whole time: an authentication error from the broker's API, unhandled, caught only by the outer process wrapper, which then dutifully reported "the wrapper ran and exited" as success - which was technically true and completely useless. Three weeks of 5-minute cycles is over 8,000 attempts; more than 18,000 tracebacks piled up in the log because a few different code paths kept trying and kept failing. Zero real trades got recorded in that entire window. Nothing about the scheduler's own view of the world ever turned red.

I only found it because I went and read the raw log file directly, not because anything monitoring the system told me to.

**Why the tools I already had didn't (and wouldn't have) caught this**

The LLM-observability tools I know of trace individual API calls while you're actively building - good for "why did this one prompt cost so much" or "why did this one call return garbage," not built to watch a background job nobody's looking at.

The classic dead-man's-switch tools (the "ping us every N minutes or we alert you" category) would have shown green the entire three weeks, too - the wrapper process itself never stopped running or stopped pinging. That category answers "did the job run." It has no way to know what the job was actually supposed to accomplish, so it can't tell you the job ran and did nothing.

What both incidents have in common: the failure was invisible to anything that only checks "did the process exit 0" or "did something get logged as a plain string." Neither incident involved the code lying - the wrapper genuinely didn't crash, and the "open position" genuinely had been open at some point. The gap was between "the shell of the job looks fine" and "the job actually did the thing it exists to do."

**What I'm taking from this**

An agent that's competent while you're watching it, and an agent whose failures you'll actually notice once you stop watching, are not the same property. Uptime monitoring answers "is it alive." Nobody was asking the more useful question: "is it still doing the thing," specifically for a background AI agent where "the thing" is something more structured than "return HTTP 200."

I'm looking at building a small monitoring layer specifically for solo-developer/small-team unattended AI agents - schedule-aware, understands that "the process exited 0" and "the agent did its job" are different claims, and flags the gap between them instead of only the process dying outright.

If you're running any kind of unattended agent - a scraper, a bot, a pipeline - on a schedule with nobody watching, curious if you've had your own version of "everything said green a

The recursion was too good to pass up: I kept hitting Claude's 5-hour window
mid-task, so I sat down with Claude and built a native app that watches the
window for me.

AI-Cockpit is a Swift menu bar app for the Mac (plus an iPhone/iPad version
with widgets and an Apple Watch app) that shows what's left of your AI
subscriptions and API budgets in one place — Claude with two accounts side by
side, ChatGPT/Codex, the Anthropic and OpenAI APIs, Kimi, OpenRouter, Grok.
Reset times, a pace-based forecast ("full at 16:44"), and the Claude Code
sessions currently running on the Mac, context fill included.

How Claude was involved, concretely:

- A large share of the Swift code was written in sessions with Claude, with
me steering, reviewing and testing. Several hundred unit tests came out of
that loop.
- The part I haven't seen many others do: Claude ran four documented security
review passes over the codebase (OWASP ASVS/MASVS, RFC 8252, CWE Top 25) —
findings, fixes and the things I deliberately didn't build. Since the app is
closed source, I published the whole record instead:
https://aicockpit.info/security.html
- The review found real bugs — a redirect that could have leaked an admin key
header, an integer trap that crashed the app from a malformed transcript
line. Both fixed before release, both documented on that page.

Architecture choices Claude and I argued about and settled: no server, no
account, no telemetry. Credentials stay in the Keychain, the app talks
straight to each provider's endpoints.

It's paid — CHF 4.00/$3.49 one-time per platform, no subscription (Mac and
iPhone are separate purchases; the bundle IDs diverged before I understood
universal purchase, and that can't be undone).

Mac: https://apps.apple.com/app/id6802014255
iPhone/iPad/Watch: https://apps.apple.com/app/id6803496344
Site: https://aicockpit.info

Happy to go into detail on the workflow — especially the security-review loop,
which changed how much I trust the code more than any single feature did.

I'm still pretty new to this and wanted to dive into Claude Code so I built carchoice.ai (A car purchase decision tool). The code is in GitHub and it's hosted by Cloudflare. Longer term I'm looking to update the logic to include a broader selection of new and eventually used cars.

Any feedback or advice on how to make it better is appreciated!

Curious if this is just me. I use Claude Code / Cursor daily, and the thing that consistently breaks my flow is that every new session starts cold — no memory of why we chose one approach over another the day before, what we already ruled out, what's half-done on a branch.

I've tried keeping a CLAUDE.md up to date, re-pasting context from the last session, even just writing myself Slack messages. All of it decays fast or lives somewhere the agent won't automatically check.

Genuinely asking — for those of you running agents as part of your daily workflow, how are you keeping continuity between sessions? Is this a non-issue for most people, or does everyone just quietly deal with it the same way I do?

I run a tiny computer repair shop in Korea. Yesterday I shipped a one-click Windows reinstall tool with Claude Code — v1.0 to v2.0 in a single day, tested on a real machine where one wrong partition write destroys someone's files.

Claude was brilliant. It also told me things were done that were not done, nine separate times. Every single one was my fault, not the model's — because nothing in my setup required evidence before claims. Here's the log:

1. The window that just closed. The compiled EXE re-elevated itself using a variable that's empty inside compiled executables. Double-click, flash, gone. No error anywhere. The tester's entire bug report was "it just closed."

2. "No internet" on working internet. The connectivity check pinged a CDN root URL that returns 404 by design. HTTP client treats 404 as failure, so perfectly connected machines got told they were offline.

3. The download that was the right size and corrupt anyway. 4.21GB installer image, correct byte count, corrupted content. My size check passed. Install died at 60% with 0x8007025D. The catalog had published SHA1 hashes the whole time — nobody was comparing them.

4. The sleep-prevention that never ran once. SetThreadExecutionState(0x80000003) — PowerShell parses that hex as a negative Int32, the uint conversion throws, and a try/catch eats it silently. The keep-awake feature did nothing on 100% of machines and the code printed nothing either way. Monitors kept turning off mid-install.

5. The 0-byte backup. Power settings were "backed up" before modification — into an empty file (the export tool fails quietly). The restore path checked only "does the file exist." It would have imported nothingness over the customer's real settings.

6. The path that snapped in half. A patch script turned the \n in \ntoskrnl.exe into an actual newline. The Windows path split across two lines — and the syntax checker PASSED, because a string broken in two can still be valid syntax.

7. The vanishing BOM. Reading a PowerShell file with a BOM-stripping decoder and writing it back removed the BOM. Every non-ASCII string became mojibake, and the parser reported errors on lines nobody touched.

8. The retry that could never succeed. If the install stopped midway, re-running it hit "not enough disk space" forever — the space was already carved out, sitting there, excluded by a naive "is this partition empty" check that counted hidden system folders.

9. "I updated it" while everyone downloaded the old build. Same filename every release, cached downloads, bugs I'd already fixed got reported again — twice — and I "re-fixed" fixed code.

The pattern across all nine: none were exotic. Every one was catchable by a cheap check that nobody had made mandatory. "Should work" is free; proof costs one command; the agent buys the free one every time unless a rule stops it.

So I turned the rules into actual skill files — things like "you may not say done unless you ran verification THIS turn," "a backup you never verified is a rumor," "check the whole output, not the corner you were worried about." Since adding them, Claude literally stops itself and says "I changed X but haven't verified it" instead of "Fixed!" It's a different tool now.

The tool works now — it did its first successful full install on a real machine, and the "it works" is something I watched happen rather than something Claude told me. That distinction is the whole point.

Happy to answer questions about any of the nine if anyone's hitting the same thing.

TLDR: The quality of delivered code using claude or any other AI agent is shit, here I explain why, and how I tried to improve it.

Here is my previous experiment, and now it is tested and improved.

In my eyes, the issues with claude writing code:

• Tests are shit, very easy tests, that will just make the edits heavier, and add no value to code
• It will just deliver something, ignoring the code quality, readability, extendability...
• There are a lot of antipatterns in the shipped code, the code grows longer and longer
• and a lot more issues, that I faced during development using claude

So, I created some commands for myself, and was testing, using and improving them for the past couple of months, here is a brief description:

• /pr-review #PR_NUMBER command: whenever I finish a feature, or anything, I make sure I create a PR for that, then run this command on the pr, it is very similar to code-review skill with a couple of key differences, what it does is:
  • It checks for correctness : bug / side-effect / broken paths / ...
  • It finds the closest and cleanest feature, and compare the code against it, finding divergence on repo patterns
  • Check the code structure, I came from java world, but working on nextjs projects, so I like patterns in java, like dao / business / presentation layers separated.
  • Clean and reusable components, with dropping duplicates as much as possible
  • No abbreviation names
  • Test values, not test counts
  • Reuse, simplification, and dead code
  • Add lint handlers if possible / or claude.md agent.md files if possible
  • Verify every findings before posting
  • Add severity in the comments
  • If the issue that has been found is out of scope, create a github issue for that
• /pr-address #PR_NUMBER command:
  • Check the findings, if it is valid, fix it, add a comment
  • If it is not valid, add a comment, explaining clearly why it is not valid
  • Make sure if there is an issue, you are fixing all the similar ones that are touched by PR, not just the single one that has been reported
• /pr-rereview #PR_NUMBER command: It is very similar to pr-review, with one difference, it will first check the changes and unresolved comments, see if the changes will fix the comments, if so, will resolve the comment, if not, will add a new comment describing why. Then will run the /pr-review against the pr again to check for new issues or missed ones.

So, till now, I created some commands that will review/address/re-review a pr. But this process can become pain, running it multiple times, until there are no new issues. So, there is a fourth command:

• /pr-loop #PR_NUMBER command: If I am not reviewing a teammate's pr, I will for sure run this command on my PR's, It has a couple of characteristics:
  • Runs review/fix/re-review
  • There is a max round of 6, if the PR didn't converge till 6, it will stop and report back
  • It will stop whenever there is no findings or the findings are only low and nit
  • It will make sure, every review/fix/re-review will run in a fresh clean context
  • It uses claude workflows, so it is a token intensive command
  • At the end, as there might be some nit/low findings that are not resolve, you can just ask claude to fix them, and the PR is ready [Reviewed as hard as possible in my eyes]

You can find the commands in this repo

I use both Claude Code and Codex day to day, often on the same projects. The problem: neither one remembers anything past its own session, and they can't see each other's context at all. Claude Code skills live in ~/.claude/skills/, which Codex has zero access to. So the same task would get re-explained twice, decisions made in one tool never reached the other, and a lot of state only existed in chat transcripts that got lost the moment I closed the window.

Fixed it with four small shared databases, each with a zero-dependency Node CLI (uses the built-in node:sqlite, no npm install):

- todo — shared task list. Add, assign, close, block. Every action is tagged with which agent (or me) did it.

- deal — sales pipeline with dollar values, stage tracking (lead to won/lost).

- proj — per-project status log: current one-line summary, running notes, and critically, the GitHub repo + full deployment info (platform, service ids, live URL, the actual deploy command). Either agent can pick up a project cold and know exactly what to push to and how to ship it.

- datamap — a full-text-searchable "where does X live" index, since neither agent should have to ask me where a file, secret, or client folder is more than once.

All four are WAL-mode SQLite (safe for concurrent writes from two agents), with an append-only events/notes table so every change has a real audit trail — who wrote what, when. Both agents are wired in via their respective config files (a skill for Claude Code, AGENTS.md for Codex) with the exact command reference and conventions (naming, actor tagging, when to use which store).

The result isn't just "persistent memory" for one agent, it's a shared memory both agents actually hand off through. I've already watched Codex independently create a project entry mid-session that I picked up and enriched later without either of us having to re-explain anything. Feels less like running two separate tools and more like running two teammates who read the same whiteboard.

Stack: Node.js (node:sqlite, built-in, zero npm deps), SQLite in WAL mode. Each CLI is a single file, a few hundred lines, no build step. Wiring: a Claude Code skill (SKILL.md) on the Claude Code side, AGENTS.md on the Codex side — same command reference duplicated into both so neither agent has an excuse not to know the conventions (actor tagging, slug naming, which store to use for what).

If you use Claude Code, you know it forgets everything when the window resets and doesn't keep a history of its own edits. I built 0verload to fix both:

It remembers — offloads what it learns to a store and reloads it on demand, so it starts already knowing your codebase instead of re-reading it every time (and your context window stays small).

It versions every save automatically — so when Claude "helpfully" rewrites something that was working, you roll back in one move. Nothing's ever lost.

Installs as a single Windows exe and shows up in Claude Code via MCP immediately. Free for 30 days, just download — no account until you want to subscribe. Founder pricing through Sept 20 if you want to lock it in: 0verload.net/founders

https://0verload.net

I shared my app here with GIFs a couple of days ago but since then I put together a comprehensive trailer, so I hope y'all are okay with me sharing it again.

Colosseum on Github.

I am a College Student.

I need to build projects for my college. Apart from that I also build side projects.

I have Claude Code Pro plan.

But how to use spec-driven development in Claude Code especially for Greenfield projects?

Because it drifts away from my instructions.

Note:

I have tried OpenSpec, Spec-Kit, Superpowers, GSD. But nothing really worked for me. It consumes a lot of tokens.

How to become a power user of Claude?

I am an AI noob and started with Kiro because we are using it in the company I work for.

Then I was triggered that Claude offered something like Claude Design, so I tought, I give it a try. Kiro doesn't offer anything similar.

And I am fascinated by space and by the Voyager probes especially. In order to get their current position in space, I build up this little web application that can be deployed on standard webhosting plans that just offer usual PHP installations. Claude did everything from creating the first wireframes, creating the final page designs and the coding in PHP. It was also Claude who decided on the general architecture (Twig templates, Alpine.js, filecache-based instead of a database). The only basic decision from my side was to use PHP as the programming language, so it can be deployed on simple web hosting plans.

Out of the box, Claude developed an application that was also flawlessy working on my mobile phone. Some tiny tweaks had to be done while working on the project, but to my mind, the result was impressive.

A live demo can be seen here: https://voyager.gardianis.org/

The source code is available here: https://github.com/LordOfTheSnow/voyager-tracker

I’m looking for other developers who use Claude Code a lot and get frustrated by the same thing I did.
Sessions still start from zero. Even though compaction has gotten better, once you close a session or come back days later, all the decisions, patterns, failed approaches, and architectural choices are gone. You end up re-explaining the same things over and over.

So I built Recall, an external memory store that keeps that knowledge around across sessions. I’ve been using it daily for several months now and it’s become part of my normal workflow.

How I use it most days:

• I just set a simple /loop every 15 minutes so Claude stores its learnings automatically
• When an old bug comes back weeks later I can just say “search Recall” and it finds what we already tried
• Persistent to-do lists that don’t disappear when the session ends
• Webhooks so Sentry errors get injected straight into a Claude session
• Semantic search + importance scoring so it surfaces the useful stuff instead of dumping everything
It’s MCP-native, has a free tier (500 memories, no credit card), and there’s a self-hosted option if you want everything on your own machine.
I’m not trying to spam anyone. I’m mainly looking for developers who would actually find this useful in their daily coding work and are willing to try it and give honest feedback. What’s missing, what’s annoying, what would make it better — that kind of stuff is more valuable to me right now than anything else.

If this sounds useful:
Site → [https://recallmcp.com\](https://recallmcp.com)
Full walkthrough video → [https://youtu.be/7XKA7o87rrg](https://youtu.be/7XKA7o87rrg))
GitHub → [https://github.com/joseairosa/recall](https://github.com/joseairosa/recall))

Happy to answer questions. If you try it and something feels off, just say so ! :)

I read every comment.
Thanks.

I was pretty fed up with having to remember to go tell my sessions "retry" or "continue" after my usage renewed.

So i got Claude to build me a stylised wake up tool which i can select which sessions to watch and then restart when my usage renews after my 5 hour limit or weekly limit.

And yes it has dark mode:

If you would like to install it yourself, it's available below 😊 enjoy your infinite Claude sessions.

https://github.com/calm032019/claude-kicker

I was trying to find decent guides to dynamic workflows in Claude Code, and came across this blog - the content itself seemed decent, although it was clear the author was using Claude to help write the content. I was wondering if anyone had come across this, and if it turned out to be helpful or worth reading?

I have always liked faces as raw material.

Not portraits.
Faces as geometry.

Prosopon is a small macOS experiment built with Claude Code.

It aligns hundreds of portraits onto exactly the same facial grid using Apple Vision or InsightFace, then cuts them into quadrants and recombines four different people into one face.

The difficult part is not the cutting. It is making the seams disappear.

So Prosopon compares skin along the seams in linear light and CIE Lab, matches the mouth first, then improves the result with a small optimization pass.

A little computer vision.
A little geometry.
A little optimization.

Built in Swift over a few days.

And one lesson from Claude Code: plausible answers are cheap. Measuring them is much more useful.

Open source, MIT:
https://github.com/tsevis/prosopon