They are milking for the IPO.

I usually have three or four Claude Code sessions going in different projects, and I kept losing track of which one was stuck on a permission prompt. So I built Dashbar, a free, open-source macOS menu bar app, mostly with Claude Code itself.

What it does for Claude Code:

• Session status at a glance: working, idle or waiting for you, per project, with running subagents. The menu bar icon turns amber when a session needs you.

• Answer permission prompts without finding the terminal: Allow once or Deny, from the panel or a banner at the notch. It's opt-in (you add the hook in Settings), it never approves anything by itself, and the prompt in your terminal still works.

• Plan limits with pacing: 5-hour and weekly, with "At this rate, lasts until it resets" or a warning when you're on course to run out. It can read them from Claude Code's status line, so no extra sign-in is needed.

• Usage: tokens per day and per project, estimated cost at API prices, and how much went to subagents.

• Several accounts if you switch between personal and work.

It also supports Codex, Gemini CLI and Antigravity, if you use those too.

Privacy: it only reads Claude Code's local session files. The status line and permission hook are the only Claude Code settings it changes, and only when you click Add, after making a backup. Remove puts them back. Nothing is sent anywhere.

Free, MIT, macOS 14+. Site: https://usedashbar.com Code: https://github.com/stevenmckinnon/dashbar

What would you want it to show that it doesn't?

I run Claude Code and Codex all day, often as multi-agent workflows with dozens of subagents. I could see each session but never the whole picture, so I built an open-source tool, coding.sh, and pointed it at my own runs. What it found:

Cache breaks and idle subagents Across 57 workflow runs (666 subagents, ~$2,500 API-equivalent):

• Broken prompt caches cost $106 extra, about 4% of the spend.

• 41 of those breaks were agents sitting idle at a barrier, waiting for siblings, until their cache expired. That's $21 for doing nothing.

• 40 subagents failed outright.

coding.sh workflows stats shows the critical path, how many agents ran at once and idle time at barriers. The viewer draws each run as a timeline, one bar per agent.

Does that plugin help? I A/B tested a popular "be concise" plugin: 10 tasks, 6 runs each, paired, with 95% intervals.

• Replies: 17% shorter

• Output tokens: −8%

• Cost per run: +11% [+7%, +15%]

• Pass rate and clarity: no change

The plugin adds its style guide to every request, and that costs more than the shorter output saves. Most of what a coding agent writes is tool calls and code, not prose. coding.sh compare and exp run your own tasks with and without a change (a rule, a skill, a plugin, a model).

Your own sessions Mining 3,600 of my sessions turned up a find-and-replace typo in my AGENTS.md that sent Codex looking for a folder that doesn't exist, in 92 sessions.

The tool It hooks into Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Aider and more, and stores prompts, tool calls, diffs, tests, tokens and cost in SQLite on your machine. There's an MCP server so your agent can look up its past sessions. Free, MIT, no account, nothing leaves your machine. npx coding.sh to try it. GitHub: https://github.com/jackulau/coding.sh

So has some minor similarities to the other MCP task insights that are out there, but I wanted to make my task manager (?) a bit better than the average bear.

Firstly, I pre-built a bunch of web widgets that may or may not be useful. Then, by exposing these to the llm, the llm can then decide whether it wants to use them. Not just the usual suspects, but stuff like charts, image previews etc etc. For example, here's something I'm working on at the moment:

Now, I haven't told claude to use any of these widgets, it's decided that these ones are the best for the task at hand. However, the smarter thing this process does it then allow suggestions BACK from the llm for better widgets in the future - for examples, see the first comment I've posted.

Anyway, it's not open source yet but if people are interested I'd be happy to publish it. It may be that someone else has done it but I haven't seen anyone do the self-improvement cycle or offer anything but basic widgets.

How has claude helped ? It has been suggesting and designing the widgets based on stuff it wants to show me - hope that makes sense?!!

One prompt to finally make a decent pinball game and get rid of the rubbish I first created..

"Fable's first report has arrived. I checked the teardown, and it removed only what it should have.

Physics decision: a custom solver written in TypeScript, with no new library.

- One Opus agent measured Rapier 3D, Rapier 2D and a custom solver side by side. The custom one passed on energy from a moving flipper as well as Rapier did, and no ball passed through a

wall in 1,000 trials.

- It was 14 times cheaper per step and about 1.8 KB, against roughly 1.5 MB for Rapier. That matters on Intel UHD graphics and phones.

- Rapier 2D stays as a fallback behind the same code interface.

- The table is in metres, 0.514 × 1.067 m, sloped at 6.5°.

Research: a second Opus agent read the Pinball Fantasies manual from archive.org scans, The Web's rulesheet and the Pro Pinball manual, and looked at a few small stills. It found no video

it could watch, and it recorded the sources that failed.

Old pinball removed:

- Gone: the pinball code, the test benches, tools/pinball, the old tests and three obsolete images per art set.

- A placeholder pinball scene keeps the game building.

- Kept as planned: shape.ts, ThreeLayer.ts, DomOver.ts, the three cameo images and the bandit art.

- A new test checks that old pinball records in saves still load.

- 756 tests pass, down from 835 because the old pinball tests went. The build and the art audit pass.

Running now:

- An Opus agent is writing the design package: layout, shots and returns, rules and the first minute of play.

- A Sonnet agent is uninstalling the two packages only the old pinball used.

- Next comes an independent Opus review of the design, then the physics core."

3% Fable usage.. We are strong!

Hi, I'm not here to sell anything, I'm here to ask. Do you use Headroom or any other system that promises to save tokens? If so, which one and why? Thanks

I've been using Opus 5.5 since the last month, enjoying it a lot, but the token usage..... I use the Pro plan cuz the Max costs 2/4 of our minimum wage (Brazil) hahahaha....

This is my dream, affordable models with high intelligence such as Gemini 4 Hydrogen

...and it still tells me when it is time to open the window.

It's a Qingping Air Monitor Lite (air quality monitor with a 160×128 OLED and a touch strip) that shows dog in a beret (Claude) instead of boring sensor numbers.

I've been using Claude Code daily for several months on a large production codebase (Symfony/PHP backend + Angular frontend, multi-tenant, strict quality gates). Every "best practices" article I find says something different, so I'd like to hear what is actually working for you in practice, ideally from people using it on real products rather than toy projects.

My current setup, for context

- Plan mode first for every feature and bug. A planning skill guides it, and a separate reviewer agent checks the plan for gaps, contradictions and untestable acceptance criteria before I approve it. For bugs, the plan has to include a failing test.

- Tests first via dedicated testing subagents (backend/frontend), then implementation in small steps. If the same problem fails twice, Claude has to stop and ask me.

- Hooks run static analysis, lint, type checks on changed files every time Claude stops.

- Hard quality gates: PHPStan level 10, architecture rules enforced by Deptrac, 100% coverage, 100% mutation score on changed code.

- Blind review: an independent Claude process reviews the diff without the session's context. Commit and push are blocked until it passes.

- Draft MR → CI pipeline as the final full check. Claude watches the pipeline, fixes red jobs or retries flaky ones. A human colleague reviews and merges.

- Git worktrees with their own test DB each, so agents can work in parallel. Stacked MRs for epics.

- Retro log: every time I correct Claude, it logs an entry. Once a month I review the log and fold the learnings back into rules and skills.

It works well but I want to take it to the next level.

What I'd like to learn

1. Best Practice: As a Dev I love Best Practices. And I would love to learn what your Claude Code Best Practice is.

2. Large features and epics: How do you split them? One session per ticket? A long-lived spec document the agent works through? Stacked PRs? How do you keep context coherent across many sessions?

3. Autonomy: What's the longest stretch you let Claude run without a human checkpoint, and what made that safe? Which gates did you automate (tests, reviewer agents, CI loops), and which do you deliberately keep human?

4. Quality: What made the biggest difference to result quality for you? Better specs, better tests, reviewer agents, smaller tasks, model or effort choice?

5. What did you try that turned out NOT to be worth it? Too many subagents, huge rule files, elaborate prompt frameworks, ...?

6. Rule and context bloat: How do you keep CLAUDE.md, rules and skills from growing into a monster that costs context and gets half-ignored?

Where it still breaks for me

- Rules keep growing. Every correction becomes a new rule, and at some point it's unclear which ones still matter.

- Maximum automation. I want Claude to work on its own, without a human telling it how to do things. I want to assign Claude a Jira ticket and receive a production-ready PR without any interacti

- Feedback loop speed. With strict gates, a full check takes minutes. Claude either waits a lot or runs targeted checks and misses side effects.

I'd especially appreciate answers that include how big your codebase and team are, and how long you've been running your setup. That context helps separate what scales from what sounds good in a blog post.

Happy to go into detail on any part of my setup in return.

I wanted to get better at chess and couldn't find a place I liked. So I opened Claude Code, just to see how far we'd get. After an hour it already looked fun, so I gave it two more weeks. That got a little out of hand.

Four weeks and 139 commits later it's called Pupilmate: pupil as in student, and pupil as in the eye that watches you play.

The video isn't me playing, by the way. It's a script Claude wrote that opens the site, reads the board, solves the puzzles and gets one wrong on purpose.

My favorite thing on the site is Pupil Frenzy: five minutes of puzzles against the clock. Every tenth puzzle is a boss, a mistake costs you 15 seconds, and in the last 30 seconds everything counts for more while the music speeds up.

You can also play the computer while a trainer explains your moves, or import your own Lichess and Chess.com games and practice the positions where you went wrong.

How we built it: I describe what I want, Claude builds it and takes screenshots of its own work, at phone and desktop size, and I tell it what's off. Then we go again. Along the way it wrote about 70 small scripts that play the site in a headless browser and check what happens. The one in the video is just the prettiest.

What surprised me is where the time went.

The chess itself was the easy part. Analysing positions, deciding what counts as a blunder, getting Stockfish to run in the browser: Claude did all of that faster than I expected.

The opponent was harder. Stockfish turned down doesn't feel like playing a person. It plays perfectly and then suddenly gives away a piece. Letting Maia-2, a network trained on human games, pick the moves made it feel much more like someone sitting across from you.

The UI took the most rounds by far. Claude builds a screen in minutes, but making it obvious where to start, and making it feel natural, took a lot of looking and saying no. The Frenzy start screen alone went through 14 rounds.

It's free, there's no account, and your games stay in your browser.

pupilmate.com

Frenzy: pupilmate.com/pupil-frenzy

Happy to answer anything about how it was built.

Hey everyone,

This is a follow-up to the GitHub Dark theme I posted here: https://www.reddit.com/r/ClaudeCode/comments/1xw8bp9/claudeforge_themes_custom_themes_for_claude/

The themes mod now has four space themes. They keep the GitHub Dark colors and put a moving scene behind the conversation:

• Space Deep Field (space-stars) - Stars in three depths that slide slowly, and a meteor now and then.

• Space Nebula (space-nebula) - The same stars behind blue, purple and pink clouds.

• Space Orbit (space-orbit) - The edge of a planet in the top right corner, with a small moon circling it.

• Space Warp (space-warp) - Streaks running outward from the middle. The busiest one.

Switching works like before:

/themes
/themes space-nebula
/themes github-dark

Each scene is one SVG that the mod builds itself and animates with CSS. No script runs in it and nothing is loaded from the web.

Limits:

• An animated background costs GPU, also when the window is idle. In a small idle window I measured the app's GPU process at about 6% of one core without a scene and 16 to 25% with a scene at 20 steps a second. That's why the three calm scenes move in 10 steps a second and only Warp in 20. GitHub Dark has no animation if that bothers you.

• Motion stops when your system asks for reduced motion.

• In split view the window shows the theme of the left session.

• Tested on Windows 11 only. Dark mode only, and only in the desktop app, the terminal and VS Code draw no themes.

Install:

/plugin marketplace add IT-BAER/claude-forge
/plugin install themes@claude-forge

If you already have the mod, claude plugin update themes@claude-forge in a terminal gets the new themes. Restart Claude Desktop after either one.

GitHub: https://github.com/IT-BAER/claude-forge

Feedback welcome.

After 100+ job applications and repeated rejections with little to no feedback, I decided to build something to understand what recruiters were actually seeing.

I built recruiter-panel, a Claude Code plugin inspired by the hiring-panel skill.

It simulates four perspectives:

• A recruiter scanning your resume in 90 seconds.

• A recruiter evaluating your career story.

• A technical recruiter matching your skills to the job.

• A technical reviewer investigating your GitHub and verifying your claims.

Each gives an Interview, Hold, or Reject verdict, followed by prioritized issues and a remediation plan.

When I tested it on myself, it uncovered:

• Duplicated links in my PDF's underlying text layer.

• Inconsistent career positioning across my resume, LinkedIn, and portfolio.

• Poor project visibility and portfolio UX.

• Gaps in my GitHub's TypeScript portfolio.

These weren't problems with my engineering ability. They were problems with how I presented it.

I built this because I wanted more actionable feedback than another rejection email.

It's free and open source. I'd appreciate technical feedback from anyone willing to try it.

https://github.com/Aashir-Adnan/recruiter-panel

Full disclosure: I'm the author. I made this with Claude, for Claude to help people like me that just wanted some more insight.

I've been building products for about 4 years. This is the first one I've ended up depending on in my own daily work, so I wanted to share it.

The problem: I use coding agents a lot now, and the code they write is fine to review, but the reasoning behind it disappears. Why that approach, what got tried first, which test failed along the way, what the original request actually said. All of that lives in a chat that's gone once the session ends.

And honestly, those sessions are a goldmine. They hold the intent, the decisions, the why, which is exactly what the code can't tell you. Yes, Claude Code keeps its transcripts on your machine, but as raw logs in a global folder that nothing really uses. I wanted them kept with the project, structured, and easy for any agent to read.

So I built Wisdom. You run wisdom connect once in a project, then keep using Claude Code, Codex or Pi as usual. It records each session in the background, every prompt, tool call and file change, tied to the call that made it. Any agent can read it back later, so a fresh session can answer "why is this code like this?" with the exact steps. You can see the rest in the video: handing a session to another agent, cloning, sharing with a teammate, and the dashboard.

Why I think the approach is right:

• No summaries. Everything is recorded as it happened, so you aren't relying on a model's retelling.

• Reads are cheap. An agent opens only the steps it needs: a few KB instead of a full transcript.

• It's local. It runs with your own login, and nothing is sent to me or any service.

• It works across Claude Code, Codex and Pi, so context survives switching tools.

Trust me, my workflow has improved so much. I've stopped re-explaining context to new sessions, because they read what the last one did. The clearest case was with a colleague. He'd spent an afternoon working through a problem with his agent. He shared the session, I imported it, and my agent picked up from what he'd already ruled out.

If you find it useful, a star on GitHub would mean a lot: github.com/Oqura-ai/wisdom

Hey folks! I’ve been playing with agentic coding and wondering if it’s actually worth adding Python-specific skills to my setup.

For those of you using them: which ones are genuinely useful? Any examples where a Python-specific skill noticeably improved the result vs just letting the agent figure things out on its own?

Since I started building with Claude Code, the speed is wild, but so is the number of changes. One session can touch the sign-up, the billing page, the settings and a migration, and the agent says "done, tests pass".

The problem: the tests it wrote check what it just changed, not the rest of the app. Twice now a change that looked fine broke something unrelated: once the sign-up for new users, once a page only admins see. I found out from users, not from tests.

Clicking through everything after each change doesn't scale anymore. Writing Playwright for every flow and every kind of user (visitor, member, admin, paying customer) doesn't either, because the UI changes every day and the tests break with it.

So, for people coding with Claude / Cursor / Codex:

1. What do you do after the agent says "done"?

2. Trust it, click around, a staging check, e2e tests, something else ?

3. Do you let the agent write and maintain e2e tests? Does it hold up, or do you end up fixing tests more than code ?

4. Do you test as each kind of user, or mostly as yourself, signed in as admin ?

5. What's the last thing your agent broke that you didn't catch, and how did you find out ?

I'm trying to figure out what a sane workflow looks like at this pace.
Thanks in advance :)

Update: to be clear, I have CI and unit/integration/e2e tests, all green on every PR. Both bugs shipped with green CI because no test covered that flow as that user type. My question is how you get coverage per role without hand-writing and maintaining it all.

Found this while digging into how Claude Code (2.1.311) loads MEMORY.md and the notes it indexes.

What the docs say: each session loads only your MEMORY.md index: the first 200 lines or 25KB (or to be precise 25000 char length - it counts UTF-16 units: one per ordinary character, two per emoji or other characters outside the basic plane), whichever comes first. Your topic notes stay on disk until Claude opens one with its file tools.

What the 2.1.311 binary also has: an undocumented recall step.

On each turn a selector model is asked to "Select memories relevant to:" your prompt, and up to 5 note files get attached, each cut at 200 lines or 4 KB. It sits behind a server-side feature flag. The flag is off by default. The flag name is `tengu_mill_orange`, recall turns on only when Anthropic's server sends `tengu_mill_orange: true` for your account. There's no local switch.

So if you lean on the default memory: keep the index short, and put anything that must always apply in CLAUDE.md or .claude/rules/, not in a note you hope gets picked.

Disclaimer: found while building a context x-ray for Reporails diagnostics

Select a .pbix file and it runs entirely in your browser. The file is never sent to a server, all information is kept locally.

Features:

- Lists tables, columns and relationships

- Export tables to CSV/XLSX

- Shows all DAX measures with their expressions

- No install and no account

Feedback and suggestions are very welcome!

So idk, I think that I made the code because the ideas are mine, and letting Claude tag itself may make people think you didnt put any effort in, do you see it that way?

I finally improved the unparalleled skillset for agents to improve frontend designs! It now comes with WCAG guidelines, better accessibility, and an intelligent color palette generator that maps to prompts like "Luxurious", "Bespoke", "Calm", "Cyberpunk" etc.

I rigorously tested it with gemini, muse, claude and GPTs, overall it gives much better results! I also benchmarked with impeccable skills and other relevant skills from my opinion both outperforms eachother in some areas. Particularly, I designed it to work with impeccable to get even better results

GitHub:

https://github.com/Phantom-Con-Artist/unparalleled -skillset

I run about ten Claude Code sessions at once on one 64 GB workstation, one per product. Every collision so far was silent. Nothing errored, and I found the damage later. These are the five that cost me the most.

1. A compose file with no name takes its project name from its folder. Several of my products had a deploy folder, so they all claimed the project "deploy". One session ran docker compose up and it recreated another session's containers, including its Postgres. Fix: a name line in every compose file.

2. A bare -j is unlimited. cmake --build build -j with no number started about 300 compiler processes, used 49 GB and hard-hung the machine. Twice. Fix: always a number, nproc at most.

3. A subagent chasing a slow test killed a test run that belonged to another session, at test 185 of 361. That run was the last check before a go-live. Fix: never stop a process you did not start. Find out whose it is and ask.

4. The shared "who is working on what" table lost entries, because two sessions read it, edited it and wrote it back at the same time. Fix: one claim file per session in a folder. You only ever write your own file, so nothing can be lost.

5. "I searched and found nothing" was wrong. The search tool inside a session skips gitignored files, so .env files and build output were never searched. A test with five planted strings found one. Fix: before removing anything on the strength of an empty search, search again with the real grep, and first search for something you know is there.

What these have in common: each session did something reasonable with what it could see. The rules all live in one global CLAUDE.md, with the date and the incident next to each, because a rule with its reason gets followed and a bare rule gets argued with.

What has bitten you when running several sessions on one machine?

Every time I let Claude Code build something, I'd find the same stuff later. A route with no login check. A helper it wrote again even though the repo already had one. Old functions nobody calls.

So I built Attentry. It hooks into Claude Code and checks every edit on my machine. If the edit adds a security hole or something that can crash, Claude hears about it right away and fixes it. Before it writes a helper, it gets pointed to the one that already exists. If the edit is clean, it says nothing.

No AI inside, it's static analysis, so it doesn't eat tokens.

It's free on VS Code and Cursor. I need feedback on what it gets wrong and what it should catch. There's a demo repo if you want to try it fast: https://github.com/Aarv-1o/attentry-demo

https://marketplace.visualstudio.com/items?itemName=attentry.attentry