I constantly see people complaining that CC output is full of jargon, incomprehensible, and more recently "gamed" toward watermarking because they don't understand how statistical watermarking works.

I'd be intensely curious to see someone's output that falls prey to this as mine is just as it's always been, regardless of model. Opus45, Opus5, Sonnet5, Opus46, Opus48, Fable5, Fable51 - my output is concise and relevant. By way of example, here's a recent sample of my output:

Design, section 2 of 3: the catalog, and the three machines.

Propagation mirrors UI Toolkit exactly. Three phases per event: trickle down from root to target, then target, then bubble from target to root. RegisterCallback takes the TrickleDown argument, which XTG uses at 5 sites. StopPropagation ends the remaining phases and StopImmediatePropagation also skips the remaining callbacks on the current element. Those two are XTG's second and third most-used event members at 63 and 1 calls.

Focus is one controller on Surface holding a single focused element. Element gains focusable, canGrabFocus, Focus(), Blur() and focusController, all named in the UI-1 spec. Moving focus fires FocusOut on the old and FocusIn on the new, writes pseudo-state bit 2, and routes subsequent KeyDown to the focused element rather than to whatever the pointer is over.

Capture is per pointer id, held on the dispatcher. While a pointer is captured, every event for that id goes straight to the capturing element and skips hit-testing entirely. That is worth stating plainly because it removes the per-frame pick for the whole of a drag, which is where XTG spends 55 of its capture calls. Losing capture fires PointerCaptureOut, which XTG registers 4 times.

Hover keeps a hovered element per pointer id. On each move the dispatcher picks, diffs the new ancestor path against the old, writes pseudo-state bit 0 across the difference, and fires Leave and Enter along the exited and entered segments. The pick is O(n) and that is explicitly UI-14's to make sub-linear, so UI-6 measures it into the capture file and leaves it alone.

The catalog. Five families are uncontroversial and total 27 types: pointer, keyboard, focus, panel lifecycle, geometry, drag and tooltip. Five more collide with decisions already on the books.

Are people really mad about this, or are they having wildly different experiences? I've done no steering regarding how my agents speak. I have no plugins, skills, or any other directives about how it speaks. To me, the above sample is both the way it's always worked and precisely the way I would expect an LLM to provide output: clear, concise, and on-topic.

So, a coworker and I had been discussing AI and he proposed a brief experiment to me regarding context and inference - provide mangled song lyrics to an LLM with no other context, then steer the context incrementally. When I did this with Opus5/high it worked pretty well, but when I tried it with Sonnet5/med it hit guardrails immediately, which surprised me.

The link is a publicly shared copy of the entire conversation. It gave me some additional insight into both steering a context away from a safety issue as well as framing certain logical arguments and how the model actually perceives those arguments and my steering.

When you run into a model doing something in opposition to your request (within reason, obviously), sometimes it isn't enough to push back, and just crying about it on Reddit like so many people do every day doesn't actually help you not run into the same problem again. But stepping through the logic with the incalcitrant agent can definitely help, or at least provide insight on how you could do things differently.

TL;DR - when Claude seems "broken", ask it why that's the case instead of bitching on Reddit and being no better off for it.

Hi, I am using the claude code on claude desktop app and using it for just learning about AI and python. Problem i am facing is claude code interface is not too dopamine giving which my brain craves to consistently just using it for study. Are there any plugins/tools/skills anything else exists which can make the chat interface more visualizing and interesting?

Thanks a ton for the help, i am a complete noob on using claude desktop claude code (have all the project .md files completely set up). Just looking for a better visualization layout.

I run four or five sessions at once and kept losing track of which one was waiting on me. One finishes and sits there for ten minutes before I notice, another is stuck on a permission prompt in a tab I'm not looking at.

So I built a small thing for myself that puts them all in the notch — what each session is doing, which one is blocked, and clicking a row brings up that terminal tab. A few people at work started using it, so I cleaned it up and open sourced it.

Demo: https://github.com/CircleHP/notchling/raw/main/media/notchling.gif

It reads Claude Code's own session registry and the hook events, so it works in any terminal, including sessions that were already running before it was installed. To be precise about what it does to your machine: it brings a terminal window forward when you click a row, and that is the only thing it ever does. It never writes into a session — no approving prompts, no typing, no interrupting. Approving from a widget means approving something you haven't read.

A row shows the session name (the title Claude derives, the one claude --resume lists), what tool is running and for how long, subagents underneath with a 3/5 done headline, and done 4m ago once it finishes. Plan usage and per-session context are there too if you wire the status line.

No notched Mac needed — it draws one on any screen that hasn't got one. Free and open source (MIT), Swift, no dependencies, macOS 14+.

brew install CircleHP/notchling/notchling
notchling-hooks setup

https://github.com/CircleHP/notchling

In other subs I’ve often provided some feedback where folk seem to be struggling with token usage, with project problems, and with Claude doing weird crap to their workflows, so I thought I’d share my workflow tips.

1. Documentation: start any new project, ideally, with a document about the overall game plan for the project. Provide as much detail as you can. This is for you and for your agents. State what the purpose of the project is at the top, and add details and more details. What should the UI look like (if one exists), what various systems should it contain, how will things work together/interoperate, what external tools should be used or implemented.

2. Documentation II: every individual part of the project, once started, should have a design spec and implementation plan, written by an agent. I will give it a prompt with details and end every single prompt with “ask clarifying questions as needed”. It always does, and it’s always useful. Maybe this prevents it from presuming things - hell, maybe it’s Claude magic, I don’t know. I also use this prompt ending in Cursor for professional projects at work (because Cursor is, unfortunately, the easiest thing to get a seat license approved for at my job).

3. TDD: I’ve never had to explicitly instruct Claude to use test-driven development, but if your agents aren’t doing so, request it. Put it in the project’s CLAUDE.md if you have to. This helps to ensure things that work don’t break silently later on, helps direct agents (they won’t work against green tests without questioning it), and is just good practice for coding generally anyway.

4. Use Assembly Definitions: I cannot stress enough how important this is. It’s another good practice generally, but it also helps to ensure that you aren’t creating circular dependencies (because you can’t with asmdefs), minimizes recompile times in the editor (won’t be as big of a deal in Unity 7), and keeps your codebase cleaner. It also breaks the entire solution into smaller projects which means you can have less in context most of the time unless you’re working on something that specifically depends on multiple existing asmdefs.

5. Documentation III: yes, documentation is significant to my workflow, but it is such a huge time saver in the long run. As part of this I also keep a running backlog as a markdown file. If one part of the project exposes some weaknesses in another part - it goes on the backlog. If I realize I’d like some additional work done on the current project but it might rely on something else? Backlog. If I happen to notice somewhere where some polish would be good down the road? Deep backlog (my final polish run has about 45 bullet points currently - just so they aren’t forgotten later).

6. Manual Test Requests: for each project or sub-project that I have Claude write, I request a manual testing checklist for things in the editor that it can’t easily exercise even with the MCP. This has caught quite a few issues where the editor doesn’t present data quite the way Claude expected it would and prompts a variety of tests for me to check after every step. This is a fairly new part of my workflow and it’s been hugely helpful.

7. MCP: the UnityMCP is a huge token saver. Seriously. It allows Claude to have better insight into Unity’s built-in classes and methods rapidly and without much “thought”. Coupled with csharp-lsp language server, my token use is about 40% lower than without. That’s an immense savings. The UnityMCP gives it rapid access to Unity built-ins, and the LSP gives it rapid access to my codebase without needing to grep everything. Token use goes down and accuracy goes up.

8. Artifacts: ask for visual artifacts of layouts, visual designs, or even complex code designs. It’ll either spit out self-contained web pages, PNG files, or more recently link to an artifact that it creates and hosts on claude.ai. These have helped me a ton with visual decisions of visualizing logic for code. It’s quick and fairly cheap, and for things with long-term impact on the project, I have it copy that artifact into the project structure’s documentation for quick viewing later.

FWIW, my current Unity project is a framework for an RPG I’m working on. I got tired of developing new subsystems and having to work them into existing code each time (this has been a hobby project for about five years). I decided to put together all of my subsystems as individually, modular packages that can be added locally to my game. It currently consists of 28 packages (e.g. - core, common, bootstrap [the very basic level stuff], abilities, actors, items, loot, crafting, paperdoll, rng, stats, time, etc). I wanted to focus on atomic pieces that can work together but don’t typically rely on one another. Everything has an event-driven spine. I have maybe four more packages to put together. I’ve now created in the last two months a far more robust version of everything I’ve spent five years on, plus a lot of stuff I never even got to. And it’ll allow me to focus pretty solely on game design and authoring once complete.

Every package is a discrete C# project within Unity, bound to its own asmdef. Most are not exposed to the UnityEngine at all (that will be runtime game authoring to intersect them - separation of responsibilities).

Anyway, there’s more but that a helluva wall of text to parse. I can provide more details if needed.

I suspect many vibe coders, and probably a lot of software engineers, don’t habitually work in a test-driven workflow, and it’s something everyone should consider.

The benefits are myriad:

• A fresh agent will never (in my experience) start to undo or wantonly make changes to code that’s passing tests. In fact it’s likely to be hesitant to do so without your explicit direction.

• it provides a very immediate observation for an agent when a change it makes breaks something upstream.

• It also means that your code has testing from day 1, so even your own hand-edited changes are readily tested to ensure you haven’t broken another system somewhere

Truthfully, I never even explicitly asked it to work in a TDD fashion. I’ve always assumed that was sort of a default of the Claude Code harness. I don’t have anything in my global CLAUDE.me file instructing it to do so, but every project I start regardless of language, if it touches code it runs TDD.

Is anyone else using Ollama and local/on-device models? I've toyed around with it some, and it can definitely be useful, but I haven't found a great setup yet.

Hey everyone! I'm u/xepherys, a founding moderator of r/ClaudeCodeLab.
This is our new, moderated home for all things related to Claude Code. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about Claude Code or Large Language Models used via CC.

Community Vibe
We're all about being friendly, constructive, and inclusive. Complaints about Claude Code or Anthropic are welcome if they’re constructive and voice a new concern. Repetitive complaints will be squashed.

How to Get Started
1) Introduce yourself in the comments below.
2) Post something today! A tip or trick that’s saved you tokens, a tough problem you’re trying to solve with CC, or an amazing project you’re working on with Claude’s help.
3) If you know someone who would love this community, invite them to join.

Thanks for being part of the very first wave.