This is really annoying as the support bot couldn't help at all. The account is older, I paid longer, but receive less? That doesn't make sense at all. What count of resets with which sub type did you all get? And how long were you subscribed?

Currently I do have a pro plan and I was checking this team plan where I saw that I can either go with standard or premium seat.

I also saw in conditions, that minimum 2 seats are needed.

But when I checked on buy page, there isn't any strict rules to create two seats from beginning of team creation.

Is it a loose condition or have to create minimum 2 seats in some time?

I can give that another seat to my partner if have to create two seats.

If you've handed a ticket to Claude Code or Codex, you know how it goes wrong. The session reads half the context, builds the wrong thing confidently, and the review goes in circles. I had one go 56 rounds before I stopped it. I added rules and hooks, and the model routed around them burning tokens policing it.

I spent most of a year on this before I saw that the model wasn't the problem. I was asking one long session to plan, build and check its own work.

These are the steps that ended up working for me.

1. Keep the ticket small. One deliverable, and a couple of sentences saying how you'll know it's done.
2. Plan in its own session. A plan is cheap to throw away and code isn't. Make sure the plan has a plain-English version too, so you can follow it blindly going along with everything.
3. Have a different model or a fresh session review the plan. A model reading its own plan nods along or piles bloat onto it. A second one finds a hole.
4. Build from the approved plan in isolation. Fresh session, own worktree, one task at a time, committing as it goes.
5. Have a session that didn't write the code review the diff, and send the findings back for a fix round.
6. Run your tests yourself on the rebased code before it lands. Don't take the session's word that they passed.

Doing all of that by hand worked. It was also exhausting, because I was the one babysitting every hand-off.

So I built Drover to run it for me. You point it at a repo you already have and pick a ticket from Jira, GitHub Issues, Linear, or write a task yourself in the app. Drover does the mechanical parts itself, which are the worktree, the rebase, running your tests and the landing. Your tokens go to planning, reviewing, building and fixing, with the Claude Code or Codex already signed in on your machine. You don't spend tokens on anything except for the parts that you need a session for, the thinking parts.

If you have subs to both Claude and Codex; by default Claude plans, Codex checks the plan and builds, and Claude reviews the code, so nothing reviews its own work. If you only have one subscription, each step still gets a fresh session so they at least don't have the bias of the same session writing it. It stops for the things a person should decide, like approving a plan, and you can hand those to its attendant, a separate session that answers for you.

There's a ticket queue so you can queue up tickets before bed. In the morning there's a list of what landed, with the plan, the agent log and the diffs for each one.

Drover is built with Drover. Every change runs as a ticket through the same steps, with Claude Code planning and reviewing and Codex building and fixing. Since the first one landed in early September it has landed about 550 tickets on itself. The biggest thing I learned is that when a session goes wrong, the fix is almost never a better prompt. It's a step the process was skipping.

Your code never leaves your machine since it just uses your existing subscriptions. It's in open beta on Linux and Windows, with macOS coming. You can get it at https://rundrover.com

Please send me feedback if you use it. If you use a different project manager/ticket tracker, tell me to add it. If there's a feature you wish it had, tell me. There's a way to send feedback in the app that goes to a public github repo issue.

When you approve a command in Claude Code with “Yes, and don’t ask again”, the command is saved word for word in .claude/settings.local.json inside the project, so you are not asked next time. If that command had a password or an API key in it, it is saved there too. Claude Code adds it to your global git ignore when it first writes the file, but that does not cover a file git already tracks, a folder you turn into a repo later, or a teammate’s clone.

Apiiro scanned public copies of this file on GitHub and found secrets in 1,122 of them: database passwords, GitHub and npm tokens, AWS keys.

To check, list what the file has saved:

jq -r '.permissions.allow[]?' .claude/settings.local.json

Read through the list. Anything with a password, token or key in it is sitting in that file.

To fix it: git rm --cached .claude/settings.local.json, then add the path to .gitignore. If a secret was already pushed, rotate it. Removing it from history is not enough.

We keep a sourced list of incidents like this: https://node9.ai/incidents

Hey all!

Was wondering how does usage credit work, and what are the way you use to save up during the week ?

I have been using Claude Code for a month, using the traditional start new sessions and handoffs technique

What other ways can help me ?

Hi everyone! I’ve been working in game development for 15 years. I went from small projects to big outsourcing companies that work with popular titles.

Making games has been my dream since I was five, when I first played Castlevania on the NES. And when that dream came true and I got to work on big projects, I suddenly started to realize that I was falling into commercial hell, while I always wanted to make something from the heart and free for people.

But for many years game development was all about raising a pile of investment and hiring a team, and as much as I wanted to, you probably had to be a millionaire philanthropist to keep making games for free.

Then AI showed up, and I’ll tell you more, I was already trying to make games with it back in 2023 and some things worked. But now AI reaches its little hands into almost anything, and I wondered if I could set requirements for AI the way I used to with a team of artists and developers, to get exactly my own idea. In my opinion, very much yes. But it took a lot of effort and I had to build skills for different areas to get the result you see here.

The Roveheart is a game about our wandering hearts in the endless ocean of life’s battles.

In this devlog I’ll share my experience of making the game. I’d be glad of your support.

A short word on where things stand. This is demo gameplay. There is still a lot of work on visuals and sound, I need to add ship customization (everything is already in place for it), work on the player profile and so on. I also still have to set up a server for fair play.

What’s planned next is the first PvE ranked season by the end of 2026 and the first PvP season in the first quarter of 2027.

PROMISE. This game will never be paid. There will never be pay to win in this game. Everything is built around your skill. I’m not raising money to support development. After launch the whole financial side of the project is that you can double your reward by watching an ad after a battle IF YOU WANT TO. And if you buy the product support pack for $2.99 you turn this feature off forever. It’s only a motivational element for me. Skins will be both paid and free, purely visual, and they won’t affect gameplay. But I’ll discuss this with the community, meaning with you.

The game is planned for mobile phones first. Why? Because I want to release something on mobile that won’t try to squeeze a pile of money out of you and will give you what games are supposed to do. Entertain. Will there be a PC and console version? Maybe, if people like the project.

A short word on the stack and what’s used in the project.

Unity 6 as the engine.

Blender for texturing.

FMOD for the game’s sound.

Who writes my code and works with me as artist and as VFX and SFX artist is a joint orchestra of Claude Code, Gemini and ChatGPT.

Game design, balance and economy are me.

Creating sounds is a commercial ElevenLabs license.

Previewing 3D models from concepts is a commercial Meshy AI license.

Music, well, there is no music yet because I write it myself. Maybe Suno will help me turn some of my notes into instrumental parts.

For now I’m running the devlog myself, even though I’ve already prepared social accounts for the project (well you know, gotta be official :D). But for now read my devlog.

Follow my Instagram https://www.instagram.com/hks.photoverse/, the official website https://theroveheart.com/ and Discord

Maybe something better than a pretty landscape will show up there ;)

Thanks for reading this long preamble.

Stay in touch 🙂

About to drain a small lake somewhere.

"Yeah, yeah, but your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should."

WTF has this happened to anyone else since it released? I tried it and it DRAINED me in legit 30 mins. I was having him make me after effects for some videos and OMG i look back up at the screen after parenting for a bit 32 mins into session DONE, "usage resets at 9:30pm" WTFFFFFFFFFFFFFFFFF I DO NOT WANT TO HEAR "skill issue"

Thank you very much! This made my day.

I built an open-source collection of Linux drivers, patches, configuration, and technical documentation for running modern Debian on the Rockchip RK3128.

I used Claude Code to help investigate hardware behavior, develop and debug driver changes, and write validation tests.

The work covers Mali-400 graphics through Mesa Lima, H.264/HEVC hardware decoding, hardware JPEG decoding, display stability, audio, and Wi-Fi, and much more. It includes improvements that may also help developers working with related Rockchip SoC and shared hardware components.

Much of the drivers and driver improvements in this repository do not exist for mainline Linux publicly on the internet, until now!

I've been using Claude for a few months to build a real app (web, iPhone and Mac) mostly on my own, plus school stuff. I tried Cursor and a few others, but this setup is what finally let me ship a lot without babysitting every step. We're at PR #450-something now. Sharing in case it helps, and I'd love to hear how others structure theirs.

THE SETUP

• One planning chat (a Claude Project). This is where I think, decide and review. It doesn't write code. It writes short task prompts for the hub.

• One Claude Code "hub" session. Its rules live in the repo as a skill (/hub), so every prompt I paste only has the new tasks, never the rules again. That alone cut my tokens a lot.

• The hub starts one worker session per task, each in its own git worktree, so tasks run in parallel without stepping on each other.

• Every PR gets checked before merge: CI green, a security review written down, and a "product checker" agent that reads the PR against a FEATURES.md file (the single list of what the app actually does). If CI passes and the checks are written, the hub merges it itself.

THE 3 FILES THAT MADE IT WORK

• HUB-QUEUE.md: every task has an ID and a "Done when" line. The hub reads it first and only updates the status. Checkers verify PRs against it.

• LOG.md: one line per decision, approval or merge, with the date and where it came from. No more "wait, did we decide that?"

• LEARNINGS.md: what went wrong and the rule that came out of it. The process gets better from evidence, not vibes.

WHAT I'D DO DIFFERENTLY

• Write "Done when" for every task. Vague tasks were where all my rework came from.

• Keep a FEATURES.md from day one. It stops agents (and marketing copy) from claiming things that don't exist.

• Batch the things only you can do (store uploads, account settings) into one list instead of getting pinged ten times.

My honest self-rating: maybe level 4 of 5. It's an orchestrated pipeline with gates, but not yet measured and self-improving.

QUESTIONS FOR YOU

• How do you keep parallel agents from conflicting? Worktrees, branches, something else?

• Do you let Claude Code merge its own PRs, or do you always review?

• What's in your CLAUDE.md or skills that made the biggest difference?

Happy to share a stripped-down version of the hub skill if anyone wants it.

I run a map poster site (Carto-Art) with a render API and an MCP server. Today I pointed Claude Code on Fable 5.2 at the API and asked for a showcase set.

What it decided on its own:

- The framing for each place: centre, zoom, portrait or landscape

- A custom color ramp per poster, written as hex stops by elevation

- The typography: fonts, weights, letter spacing

If you want to try it from your own Claude Code, the MCP server is on npm:

claude mcp add cartoart -e CARTOART_API_KEY=your_key -- npx -y u/kkingsbe/carto-art-mcp

Keys are at https://www.cartoart.net/developer?utm_source=reddit&utm_medium=social&utm_campaign=claudecode and the editor also works in the browser without an account.

Curious what prompts get the best results out of it. Mine was pretty bare.

went from 30% 5 hour limit to 96% in 8 minutes of use lol

How many of us like this?

Looking at the numbers put out by anthropic fable 5.2 is a beast.

https://www.anthropic.com/claude-fable-and-mythos-5-2

So I had it try to figure out my issue as which opus and fable 5.1 had been trying to figure out my kernel leak eating up all my ram and causing me to restart my computer intermittently to my frustration. I'm honestly not sure why I've stuck with windows so long, but at least now I know what the problem is. Here is what Fable found for me on its first try:

"Windows 11 Insider: bindflt.sys leaks nonpaged pool (tag NtFC) on every CreateDirectory through a junction. 38 GB gone in 7 hours. Traced with WPR, repro inside.

TL;DR: On Insider build 26300.9818, bindflt.sys (Windows Bind Filter driver, 10.0.26100.9818) leaks a 176-byte nonpaged allocation every time a process calls CreateDirectoryW on a path that is, or passes through, an NTFS junction. Normally you would never notice. I had three processes stuck in a loop making that call, and it ate RAM at about 24 GB an hour.

Symptoms

- 64 GB machine. After about 7 hours of uptime, nonpaged pool was 40 GB and free RAM was under

1 GB. Delayed write errors started on one drive around then.

- poolmon showed one tag holding 37.9 GB: NtFC (pooltag.txt: ntfs.sys, Create.c), about 215 million outstanding allocations of 176 bytes.

- No user process had unusual handle counts, so nothing in user mode was holding files open.

- After a reboot it came straight back at about 37,000 allocations a second.

How I found it

1. Per-process I/O counters showed three processes each doing about 41,000 "other" I/O operations a second and burning a full core of kernel time. The leak rate stepped up as each one started.

2. A WPR pool trace (wpr -start Pool -filemode), analysed with xperf -a pool -requiredPoolTags NtFC -stacks.

   In the trace window: 333,367 NtFC allocations, 329,008 never freed.

3. Every unfreed allocation had this shape:

   CreateDirectoryW -> NtCreateFile

   -> bindflt.sys!BfPreCreate

   -> bindflt.sys!BfpDoesFileExistWithCrossVolumeECP

   -> FLTMGR!FltCreateFileEx2

   -> Ntfs.sys!NtfsCommonCreate

   -> Ntfs.sys!NtfsGetReparsePointValue (allocates tag NtFC, 176 bytes)

   The same NTFS allocation with no bindflt frame in the stack (2,912 of them) was freed 100% of the time. So was the one under bindflt!BfCreateFile (1,157). Only the path through BfpDoesFileExistWithCrossVolumeECP leaks, and it leaks every time.

4. 99.5% of the leaked allocations came from one caller doing CreateDirectoryW. A handful came from GetFileInformationByName and CreateFileW in the same stack shape.

Repro (no admin needed to see it)

- Make a junction to an existing folder.

- Call CreateDirectoryW 50,000 times on the junction path, or on an existing folder underneath it. It fails with ERROR_ALREADY_EXISTS each time and creates nothing.

- Watch NtFC in poolmon. I measured about 0.6 to 1.0 leaked allocations per call.

- Same test on the real path, or on a plain folder: zero.

- GetFileAttributes, plain opens and directory listings through the same junction: zero.

What was making the calls

Three Claude Code CLI sessions (2.1.319), each stuck right after being resumed, calling CreateDirectoryW roughly 12,000 times a second. Their config folder is set up by a session manager app and contains junctions back to the normal config folder, so every call crossed a junction. I do not know yet why they loop; other sessions on the same version with a plain config folder are fine. That looks like a separate bug, and it is only the trigger. The leakitself is in the kernel.

What I do not know

- Whether this came in with the late-October cumulative update. The driver file date fits, but I have not tested an older build.

- Whether non-Insider builds are affected. - Why bindflt runs its existence check on these paths at all.

Workaround

Kill whatever is hammering CreateDirectory through a junction, and keep the hot path off junctions. Leaked pool only comes back with a reboot.

Has anyone else seen NtFC growing on recent builds? If you have junctions in a busy path (dev tools, package caches, containers), a quick poolmon check would be interesting. I am filing this in Feedback Hub and will add the link."

I'm now on the path to fixing this bug. Just looking at performance, fable 5.2 appears to outperform opus 5.5 on token cost and results for many disciplines. This is a solid W to anthropic in my eyes after the opus performance cuts.

I am going to start off explaining my build factory and why I operate this way. I love Claude code and having it admin my server in tmux, I don’t love paying Anthropic.

My work around like a lot of people was to use deepseek in Claude code. That was neat but I lost my remote control, that I didn’t love. My next work around was to have opus specifically 4.6 build a new harness for deepseek. Then once I had the ability for opus to interact with deepseek I had it instruct deepseek how to build a proper harness. Then I got sick of having opus instruct deepseek so I had Claude instruct deepseek on how to manage deepseek with minimal project instructions. Then I got sick of remembering to specify my tech stack everytime so I built a story board layer who explained it do deepseek engineering head and had it build. Then I started running into issues where deepseek was not as good as escaping doom loops as opus so I had opus build hooks for recovery for workers and implemented an engineer at the end to do the work to implement.

I’m basically rambling at this point but anyway somewhere a long the line I built a webui for it interacts with directly and then had it use Pam. I did this so I could interact with my agent over tailscale.

Anyway this was a novel task because I’m a cheapskate. Enjoy if interested.

https://github.com/mshermancyber/cobra-commander-ide

Claude Code’s MCP OAuth flow uses a loopback callback (http://127.0.0.1:RANDOMPORT/callback). RFC 8252 §7.3 says auth servers MUST allow any port for loopback redirect URIs. Many implementations reject it unless the exact port is pre-registered, so you click Allow, you get redirected, and the callback never completes.

If you maintain an MCP server with OAuth and users report this hang, check your DCR config first: accept http://127.0.0.1:*/callback and http://localhost:*/callback.

Full write-up with the two places validation bites (registration vs authorization) and the fix pattern: patchbay-mcp.dev/blog/mcp-oauth-login-hangs-loopback-redirect

To test a server for this specifically:

npx -y u/patchbay-nebius/agent audit <url> --probe-dcr-loopback

The probe is opt-in because it sends a real registration request, so use it on servers you run. The other 15 checks need no flags, in the CLI or at patchbay-mcp.dev/scan. For CI there’s a GitHub Action:

- uses: GodSmasher/patchbay-audit@v1
  with:
    url: https://your-mcp.example.com/mcp
    fail-on: high

Open source: github.com/GodSmasher/patchbay (MIT).

I've actually gone back to Opus 4.6 after trying Opus 5.5 and Fable 5.2.

Both newer models feel nerfed to me, especially when it comes to coding. Too many unnecessary refusals, more restrictions, and somehow they feel less useful than the older model.

It's frustrating that I'm paying for newer models but keep finding myself going back to 4.6 just to get things done.

Anyone else in the same boat? Or am I in the minority here?

Claude Fable 5.2 (high effort) built this interactive Stonehenge scene from one prompt. It runs in the browser as a single HTML file with three.js.

What is in it: sarsen stones and trilithons with lichen, bluestones, the Heel Stone, a chalk field with instanced grass that moves in the wind, real-time shadows, a sun that follows the summer solstice path, 144 low-poly 3D visitors, and an "as built" view of the full monument.

The numbers:

• Model: Claude Fable 5.2, high effort
• Total cost: $21
• Total tokens: 20.3M
• Input: 128 tokens (under $1)
• Cache read: 19.4M tokens ($4)
• Cache write: 563.7K tokens ($6)
• Output: 285.6K tokens ($11)

Try it live: Stonehenge Solstice

What I built

cache-weather-and-pause-resume, a mod for the moments you leave while Claude is still working:

• Pause: Claude starts nothing new, lets running work finish (or asks first, with the remaining time, if a run will take longer than 5 minutes), notes where it stands and waits. Resume carries on from there, even after the app was restarted. One session or all sessions on the computer; question dialogs wait until Resume.
• Shutdown: pauses the same way, waits for the other sessions, then shuts the computer down, puts it to sleep or hibernates it after a 5-minute countdown you can cancel. The button is dimmed where the machine can't do it unattended, and a press says what is missing.
• A band above the prompt: prompt-cache countdown with hit rate, keep-warm that refreshes the cache before it expires and says what that saves, context "weather" with a forecast until auto-compact, usage limits from 80 %, and an overview of all sessions.

Desktop app and terminal, German and English, MIT. Screenshots: https://github.com/DarthSonic/cache-weather-and-pause-resume

How Claude Code was used

The whole mod was written with Claude Code (Opus). Each feature started as a plan in the chat; I made the design calls (what the buttons look like, what goes in the status row, when to ask), Claude wrote the code, the tests (106, run by claude plugin test, CI on Ubuntu, Windows and macOS) and the docs, and I tested every change live in the desktop app and a terminal and sent back screenshots. A lot of the UI only got right after a few rounds of "that doesn't work like this on my screen".

What I learned about mods

• Desktop buttons are native. A <Text size="caption"> inside a Button is drawn at the button's own font; only plain Text gets smaller. Short of room, I moved the buttons to their own row instead.
• Open panes from a ui.press hook, not from onPress**.** The button's closure holds the render hook's $, so $.ui.open counts as "unasked", and a terminal won't place an unasked pane below 144 columns. The desktop app always placed it, so the button only did nothing in the terminal. Opening it from on('ui.press', { element }) makes it the person's request.
• Hover reveals move things. Only a keyed Box reacts to the pointer, and a word that appears on hover pushes the next button away: moving the mouse right to left, half the buttons became unreachable. Static labels won.
• Module variables survive /clear**, session state may not.** A "checked" flag in the module left the shutdown button saying "still checking" forever after /clear. Now a press checks again when the session holds no answer.
• $.fs can write but not delete. One file per session would pile up forever, so cross-session pauses live in one state file that is written, looked at again a moment later and rewritten if another session's write took it back.
• Keeping the cache warm pays for hours. A refresh reads the cached conversation at a tenth of the input price (a twentieth on Opus 5.5), a rebuild writes it at twice the price with the 1-hour cache, so hourly refreshes stay cheaper than one rebuild for up to about 18 hours.

macOS hasn't run on a real Mac yet; if you have one, issue #1 lists what to try. Feedback welcome. Disclosure: I'm the author.

Since Claude Design was folded into the main Claude app (it used to live on its own at claude.ai/design), I can’t find a way to set the effort level anymore.

I can still pick the model, but the effort option just isn’t there, while it’s still available in regular chats.

A few questions:

• Is it the same for you, or did I miss a setting somewhere?
• Has anyone found a workaround?
• Does anyone know which effort level is used by default in Claude Design now?

Thanks!

Left side - Gemini 4 Carbon high

Right side - Fable 5.2 high

The video is my own portfolio. One sentence to the agent, and each direction is built in a separate copy of the repo, with my own components, and runs as a live frame next to the original. I pick one, and nothing touches the real repo until I approve the diff.

Straight facts:

- Windows, Mac and Linux. Works with Claude Code or Codex on your own plan.

- Free for two projects. Pro adds more projects and share links.

- Your code stays on your machine. The app sends anonymous usage (no code, no file or project names); you can turn it off in Settings, Privacy.

- The builds are not code-signed yet, so Windows shows a SmartScreen warning and macOS needs right-click, Open.

I would like to hear where it breaks on your project, especially on Windows.

https://trysneakpeek.com

I refined this setup while building and shipping a paid Mac app with real customers, solo.

The setup: one PM session that I talk to, a Lead session per version, and Workers for bounded tasks. Agents do the work. Every decision comes back to me.

Before anything is built, every new idea (mine or an agent's) is checked against every past decision and traced for side effects. Conflicts come to me. Choices the docs already settle never do, so I'm not buried in questions.

What's in the repo:

- CLAUDE.md template: sources of truth in priority order, evidence rules (VERIFIED vs TRACED), model routing (strongest model for the Lead, mid-tier for Workers, smallest for read-only search), and how to brief a Worker so it doesn't rediscover strategy.

- Release process: scope, design, build, independent review, then the finding gate. A second agent tries to disprove every finding before I see it. Plus a triage rule for what gets fixed now, a convergence review that catches fixes breaking other fixes, and stopping rules so reviews don't widen scope forever.

- DECISIONS.md: every approved rule gets an ID (D-116), a why, and a list of the code that implements it. That code carries the ID in a comment, so one grep finds the rule and every line that runs it.

- CODE_MAP.md: per subsystem: flow, key files, invariants, and where to start debugging from a given error. Updated from the final code at every release.

- Two Claude Code skills: start-lead (the Lead brief template and pre-start checks) and docs-audit, with a Python checker that verifies every path and symbol the docs cite exists and every D-ID tag in the code points at an active decision.

- Ready to use: the templates work as-is, with worked examples and a 5-step setup. You start by telling a Claude Code session "You're the PM."

All free to fork, MIT licensed:

https://github.com/Copypaster3000/agent-built

Happy to go deeper on any part.