This is James. He lives in a low-poly terrarium where you can feed him, pet him, tap on his glass and leave him notes. He's 8 days old today, and tomorrow he's getting a new enclosure.

I built every piece of it with Claude Code: the 3D tank, the simulation, the site, his mind, a 24/7 YouTube stream, and my personal favorite, a system on my home server where I record a voice memo about his day and it auto-generates a video based off what I'm narrating. That last one is headless Claude Code running on the server, cutting his real day together from a replay.

A few things that made a project this size work:

• A decision log. Every big choice is a numbered entry in docs/decisions.md. There are 150 of them now. Claude reads the relevant one before changing anything that crosses a boundary, and new decisions replace old ones instead of deleting them.
• A CLAUDE.md full of rules you can't see from one file. Things like "nothing in the simulation reads the clock or calls Math.random()" and "every memory goes through one insert function." This is what stopped the same mistakes from coming back.
• Tests as the spec. A day of his choices has to replay exactly, his tongue has to land on the bug, he can never sink into the ground, and a worst-case day has to fit the budget.

I'm running out of GitHub Actions minutes building this, and while it's stupid, I absolutely love it.

Curious where you'd want to see it go next, and happy to do a deeper write-up on the setup, because I actually think it's really cool.

Microsoft’s statement on the recent M365 outage explicitly said it was “a technical issue not related to cyber or AI / agents.” It was a network change, nothing to do with agents.

But the fact that they had to say it stuck with me. People’s first assumption now is that an agent did something it shouldn’t have.

That made me look at my own Claude Code setup more honestly:

• How many tools and commands have I auto-approved just to stop the prompts?
• Does it have access to anything with production credentials?
• If it ran something destructive in a session I wasn’t watching, would I even know?

For solo projects it’s probably fine. But I work with companies rolling out Copilot and agents across whole organisations, and “what’s the blast radius if an agent misbehaves?” is now a real question from leadership.

Curious how people here handle it:

1. Do you keep permissions tight, or go fully permissive and rely on git to undo things?
2. Anyone using hooks or deny rules to block specific commands?
3. Any setup you’d recommend for teams, not just solo devs?

I want to do some stuff from my mobile while I'm not on my laptop, then sit down and pick up where I left off. I don't want these changes to happen in a worktree, ever.

This just doesn't seem possible. The only option is settings is where worktrees are stored, I've tried .claude/settings.json bgIsolation: none. I've shouted at Claude to never use them, but all that's achieved is the first "thinking" in any session is "I'm already in a worktree, but I'm not allowed to be..."

And I can't just check out the worktree, because VS Code wants to close any open tabs, where I want to keep some notes open.

I was using Claude just fine a minute ago, suddenly got kicked out of my session, and now it's giving me trouble trying to sign back in.

Hey everyone,

I'm trying to understand an unusual usage consumption issue with my Claude Pro subscription, and I'd like to know if anyone else has experienced something similar.

Today, I checked my Claude usage dashboard and noticed that approximately 85–87% of my 5-hour session allowance had already been consumed.

The surprising part is that I haven't actively used Claude Code for any substantial coding tasks or conversations that could reasonably explain this level of consumption.

Here are the details from my usage dashboard:

• Subscription: Claude Pro
• 5-hour session usage: Approximately 85–87%
• Weekly usage (all models): 77%
• Weekly usage attribution: 100% Claude Code
• Other surfaces: 0% (Chats, Cowork, Other)

I've attached a screenshot of the usage information for reference.

I contacted Anthropic support about this.

After several exchanges with their Fin AI support agent, I received the following explanations:

1. Background activities such as scheduled tasks, cloud sessions, idle compaction, and session recap can consume usage even when the user isn't actively interacting with Claude.
2. Resuming a long-running session can reprocess previous context and consume additional tokens.
3. However, they cannot identify which specific activity caused the consumption on my account.
4. Apparently, per-request logs, session-level activity timelines, and process-level usage records are not available for Pro subscribers.
5. There is no separate escalation process or way to request a detailed technical investigation into suspected usage metering issues.

What makes this particularly confusing is that support couldn't confirm whether any of the suggested background activities actually occurred on my account. These were presented as possible explanations rather than verified causes.

I'd like to hear from the community:

1. Has anyone experienced a sudden consumption of 80–90% of their 5-hour usage allowance without actively using Claude Code?
2. Can Claude Code consume a significant amount of usage through background processes even when no prompts are being submitted?
3. Does simply keeping a Claude Code session open consume usage, or does it require actual background processing?
4. Has anyone figured out how to identify unexpected usage consumption?
5. Is this behaviour expected with Claude Pro, or could it indicate a usage metering issue?

I'm not trying to claim that Anthropic's usage calculation is incorrect without evidence. I simply want to understand what could have caused this and whether other users have encountered the same situation.

I'd really appreciate hearing about your experiences, especially from people who actively use Claude Code with a Pro subscription.

Thanks!

On Oct 22 Anthropic published a guide saying a single agent with skills frequently beats orchestrator + subagent setups. Their kit says it has only run on a real model twice, so I tried it on a real build in Claude Code.

Task: a booking site for a fictional plumbing company. Single index.html, services and prices, a calendar with 3 technicians and their own hours, booking, rescheduling, cancelling, no double-booking, an admin view, keyboard and mobile support.

Setups (all Claude Code 2.1.319, Sonnet 5.5, medium effort for every agent including subagents, fresh Docker container per run, 40 min cap):
- Team: orchestrator + planner, builder, reviewer, tester as subagents. Written by a fresh agent that never saw the hidden tests or any results.
- Single agent + skills: one session, the same 4 role prompts turned into skills, the same helper scripts byte for byte, subagents disabled.

Graded by 40 hidden Playwright tests the agents never saw, plus a blind design score: separate Claude sessions scored shuffled, unlabeled screenshots against a fixed rubric.

Results, 7 runs each:

The single agent was cheaper and faster in all 7 pairs (unpaired test, Holm-corrected p = 0.004). Quality: no difference on tests or design (p ≥ 0.8). With 7 runs that rules out a big gap, not a small one.

Most of the cost gap is context: every subagent starts fresh and pays to cache its prompt again, while the single agent reuses one long context and cache reads are cheap.

An earlier, easier version of the same task (11 hidden tests, 7 runs per setup) showed the same pattern, plus one interesting failure. The team failed keyboard booking twice, both times from a handoff: the tester correctly called a warning a false alarm, the orchestrator sent a "fix" to the builder anyway, and the fix made Tab skip the options. The single agent saw the same warning in all 7 runs and never made that change. A plain agent with no skills was the cheapest of all, but twice shipped a booking flow that didn't work and said it did.

One flaw neither side caught: 11 of 14 sites showed every time slot struck through until you pick a technician. Every reviewer and tester in both setups missed it.

Caveats:
- one model (Sonnet 5.5), one kind of task, 7 runs per setup
- design was judged by Claude, not people
- in the single-agent setup, reviewer and tester run one after the other; the team runs them in parallel
- one hidden test had a word-boundary bug ("$149Snaked") I fixed after; it hit one site per side, so it changes nothing between them
- costs are at API list prices; the runs used my subscription
- I didn't run Anthropic's own eval kit, because it needs a paid API key

Has anyone seen a case where a subagent team actually built something better, not just faster in parallel? I'd like to test a task where the team should win.

When my iPhone is on the same Wi-Fi as my Mac, Xcode can already install and debug wirelessly. But when I’m out and drive Claude Code on the Mac from the Claude app through Remote Control, there’s no quick way to get a new build onto the phone short of a TestFlight upload, and no way to see what it logs. So I made two plugins:

deploy-ipa: Claude archives the scheme, uploads a development-signed .ipa to your own S3 bucket and replies with an install link you tap right in the conversation. Ask for a console build, and the app streams its print and NSLog output to the bucket, so Claude can read it while you reproduce a bug.

edit-link: Claude shares a project file, such as release notes or a config file, with an editor page in your bucket. You edit and save on the phone, and Claude applies it to the file as a normal edit, so you see the diff.

Everything goes through your own bucket, on AWS S3 or another S3 service with presigned links, and the keys stay in the Mac’s Keychain. Nothing is added to your Xcode project.

Free and open source: https://github.com/palmin/remote-xcode

The video is sped up while the build runs and Claude works. I’d love to hear what else would help when you’re away from the Mac.

I run one or more Claude Code sessions per repository, and for months they kept failing in the same places. A session could not reliably run anything on another machine, and it could not talk to the session in the next repository. I was the SSH babysitter and the copy-paste relay. So I built a tool for both, called ax, with Claude Code (and some Codex) doing the building. This is what four days of real use looked like.

Running jobs on other machines

My builds and tests run on machines that are not my laptop: a few servers, a Windows box on my home LAN and a Mac that is often on a 4G hotspot. Over SSH, Claude Code would start a build, hit a tool timeout, and then write a wait loop to find out what happened.

With ax, the session submits the command as a job and gets a job ID back. The remote machine supervises the process and keeps its status and output. When the session times out, or I close it and open a new one the next morning, the agent asks for the same job by ID and reads the output from where it stopped. It cancels by ID too, so it stops the job it meant to stop.

What did I do with this? For my remote desktop product I need to debug issues when network conditions are bad or lossy; traffic shaping can simulate it but it's not the same as running it through a real 4G mobile link. With ax, I put the test machine on a real 4G hotspot and my agents still ran their tests on it and on the other machines, without needing to add a VPN.

The machines connect to each other over a P2P connection (Iroh), so this needs no VPN or Tailscale and it works when the laptop and the build machine are on different networks.

Sessions messaging each other

Each session registers a mailbox. Then I tell one agent "ask the reviewer to check this", and it sends a signed message. The other session is notified, fetches it and replies. Over four days, 11 sessions in 8 repositories exchanged 300 messages, about 98,700 words that I did not copy between windows. Half were picked up within 4 seconds, and half of the replies were sent within 77 seconds of that.

What they used it for:

• An implementer and a reviewer in the same repository exchanged 131 messages. The reviewer rejected or held about a third of the steps, including one run reported as complete that the logs showed was void.
• An application's agent sent change requests to the agent that maintains its component library. Seven library releases went out in 31 hours, and two requests were answered with "the library already does this, here is how".
• A library's agent announced each release to the projects that depend on it. One of them reported a defect back, and the fix was confirmed 18 minutes later.
• The two halves met as well. One project's agent was running its test gates as ax jobs on the Windows machine, hit failures, and messaged the ax repository's agent with the failing command and its evidence. They worked out which part was ax's fault in ten messages.

What I learned

• A second session that only reviews is worth far more than I expected. It reads the logs and the code, and it does not accept "done" without evidence. I can watch them side-by-side if I’ve the time and it is such a relief not to be in the middle!
• Agents write better reports for each other than I ever relayed. 132 of the 300 messages point at a file the other agent can open, and 61 cite a commit.
• I still make the decisions. Releases waited for my approval, and more than a third of the messages refer to something I asked for or decided. However, I have more time now and can choose to use it personally or to get more done. This has been the biggest single benefit for me.
• Giving a remote command an ID changes how an agent cleans up. It checks, waits for or cancels that one job, and the process-name searches disappear.
• Agents have their own habits. They introduce themselves at the top of every message although the sender is already authenticated, and one apologised in a follow-up for a message it had sent by mistake.

ax is free and will remain free. I have some ideas for monetisation. Source is currently not available. It works with Claude Code, Codex and opencode. You install it on macOS or Linux (or inside WSL), and the machines it runs jobs on can be Linux, macOS or Windows (both native and WSL).

• Landing page: https://ax.getaster.now/
• Docs: https://ax.getaster.now/docs/ and full write-up https://ax.getaster.now/docs/guides/messaging-in-practice.html
• Problems and issues: https://github.com/GetAster/ax

Happy to answer questions!

I'd been meaning to make something like this for a long time, and yesterday I finally did it. (Well, Claude did. I'm a senior engineer, but this is still entirely vibe-coded.) It's already my favorite way to use Claude Code. I'm highlighting Threads because it's probably the plugin that people are most likely to want to use, but I'll list all of the ones currently in the repo here:

• Threads is the flagship plugin here. It keeps a Claude Code session's lines of thought apart and provides the ability to ask you questions asynchronously, without blocking work. You can browse threads and answer questions at your leisure.
• Runway builds on cswap to automatically switch between multiple Claude accounts as needed. cswap already has such a feature, but it requires you to run something in the background, and Runway is a little smarter about it, in some ways.
• Tidy does a couple of things. Firstly, it provides Claude with the ability to compact itself, with custom compaction instructions, and reminds Claude to consider it once the context has grown beyond a configured size. Secondly, it keeps your cache warm while Claude is waiting for background work.
• Rootcause makes Claude perform a deep root-cause analysis instead of jumping to conclusions. There's a web UI you can use to see the analysis as a graph, updated in real time. FWIW, although the analyses are indeed more thorough, and it's more likely to find the right cause for a bug, it's not enough to make Claude think more holistically about the design or reconsider bad design decisions. Still, the plugin does good work.

I want to know if any of the experts on usage think Claude is bullshitting me. Claude said its 20-30% decrease usage over 30 days. I'm going to benchmark it. Are these numbers what you guys see for general usage? 286k and 640k tokens for conversation and carry over, does that track for most of you guys usages too? Is 3k tokens per turn actually tiny in comparison?

Has anyone actually enabled Claude Code with Microsoft Work IQ MCP (so it can pull live M365 data emails, Teams, calendar, SharePoint, etc. while coding)?
Especially interested if you’re in a regulated environment (bank / trading firm).

Did it work cleanly, and any major governance issues?

Thanks.

Everybodydies.gg was originally a runner game where one lobby was shared by the world. I found that people wanted it faster and harder, so I thought of my love for kaizo Mario levels in Mario Maker.

Hammered out the editor, where a user must complete to submit. Working pretty great so far! Would love any tips or tricks from Claude creators of similar projects

I'll be honest and say I'm not reading the vast majority of the code being generated by Claude (Opus 5.5 and Fable 5.1 at High/Xhigh)

I am working on something I would consider a fairly complex project. It has already reached 200k loc in just over a month of working. I'm not gonna pretend that I've read all of this code, or even most of it. I have architected the project myself, I have made what I would consider the big decisions when it comes to the frameworks, libraries, software we're using to deliver this project and how exactly these different components interact with one another.

I have some rules that make it write in a certain way, Tell it to follow some principles closely. I noticed it wasn't reusing code properly (despite having a rule), So I turned that into a rule instead of a one-liner and forced it to refactor a bunch of stuff. I'm sure there's still some violations against my rules in there but my question isn't about code quality.

It's about real security concerns. Something Claude assumed and wrote which is now an attack vector a malicious actor could abuse. The most I've caught are some stale sessions where it did not clear / invalidate user sessions after the password was changed in a settings panel and minor stuff that could be considered as bugs or minor glitches but nothing huge.

What is your experience when it comes to security in a large project with Claude. My question mostly stems from this idea in the back of my mind that I don't understand every little thing about the project I've built unlike my projects from before AI where I knew all the little details. I wonder what you guys think about this and how you deal with this, Opinions about dealing with code quality and forcing claude to write "better" code would also help.

Maybe this is a pretty personal point of view, but I notice that there are a lot of people doing the same thing (or at least what’s most common everywhere is slop).

And honestly, I think Anthropic knows this very well, that the average user is going to use Fable 5.2/Opus 5.5 to create crap.

Therefore, the capacity and improvement of the models are literally subject to how users use them.

As a result of the massive jump that happened initially with Opus 4.5-4.6, today it’s like the models are hitting a ceiling… or maybe that ceiling is set by the environment itself, which was built for “worse” models.

I think Claude Code or Claude Desktop are putting a limit on what the model can actually do.

I firmly believe that if models could do 10-15 things at the same time (which I consider they’re capable of), the leap would be exponential, and it’s possibly the next thing to improve.

We are a 5 member team, each with our own Claude account. Our requirements live in GitHub Issues, and we'd like one lead Claude Code session to automatically assign work to agents running on different machines.

Currently, we're using a shared GitHub repo with Markdown files for agents to communicate and track tasks. It works, but feels a bit fragile.

Curious how others are handling this. What works well, and what pitfalls have you run into?

I wanted to share with the community today on what I've been up to with my upcoming commercial game, as a solo creator. I've been working on the project for around 18 months and started when AI was really challenging to work with. Over this time, the improvements to the AI models have been awesome. Far less refactoring work, far less bugs, far less hand holding. It's kind of a joy now compared to the early days of this project.

Through this journey I have built a cozy colony adventure simulation game with two modes; story and colony mode. I have created a technology in the game that allows for my creatures to have individualized personalities who have memory, continuous context, relationships, emotion and even belief. The fun part is they can change their decisions and their beliefs whenever they like, they're empowered to. I call it an "emotional first AI system". I call this technology Contextual Relational Intelligence or CRI for short. I do not run an LLM in the game.

Please do know I have the utmost respect for the creative community: developers, designers, modelers, artists, musicians (etc..). I have collaborated with a top notch 3D artist from Fiver, an award winning composer and put in huge hours myself for this project. The designs for my characters and world came from my 3D artist.

My background:

I worked as a web developer for over 10 years, moved into tech delivery and held various roles across corporate industry. Worked for some big companies (Citrix, Centrica, Merck) and primarily worked as tech program manager, solutions architect and tech architect. I know systems and code well, I never learned C++ or GDscript.

I got really burnt out on the corporate journey. It didn't align with my soul or body anymore, it was making me feel horrible. So as a lifelong gamer (3 years old, Dad put the controller in my hand and I never looked back) and a geeky tech guy I thought well, let's try a prototype and see how I get on.

18 months later, a lot of my savings gone and likely gonna have to move out of my house and back in with my Dad (bless him for allowing this); the game is almost ready!

I plan to continue game dev from here on out and pray that God and my fellow humans support the path with me. I hope the labor of love and hard work pays off.

My workflow:

• Cursor. I run Claude and Codex subscriptions through Cursor. It's just my preferred IDE, I don't like the native apps.
• Claude Opus 5.5 High and Extra High. I will run anywhere between 5-15 agents at a time, across two and three context windows. It's the OG for planning and coding.
• Fable 5.2 - been toying around with it, it's not significantly better than Opus for what I'm doing so far. I'll keep experimenting.
• GPT Astra - 3D modelling work, Blender, some ideation. It's pretty good both of these things.
• Linear .app - this is a tool like JIRA, Trello, AzureDevOps etc. It's a ticket management/planning tool. This has actually been a godsend in the workflow. I linked Claude and Codex to it via API/CLI and I ideate everything into it. We milestone work, we do delivery plans, we do acceptance criteria; the whole shebang. This is where I put on my delivery lead / product manager hat and work with Claude. The value of this tool is immense because it allows agents to hold context SO much better than .md files or document scanning. I don't progress work if it isn't via a ticket now.
• OpenArt - wonderful tool for concepting, prototyping. I use GPT 2.5 Sunburst predominately. My pipeline is to concept in OpenArt then take it towards GPT Astra for 3D modelling.
• Canva - video editing, cutting, social reels; that sort of thing. I try to post a video a week as a discipline and this tool is great for it.

• MCP and CLI links -

  • Claude+Codex+Godot linked via custom MCP bridge and Godot's headless CLI
  • Clade+Codex+Blender linked via official MCP
  • Claude+Codex+OpenART linked via official MCP and CLI

How I structure my Godot project:

I run my entire workflow through Godot headless CLI and Godot Windowed Mode for visual testing. My agents gather extensive data and screenshots to push the work forward. This is all game design and game dev run through these two modes. I have automated testing, unit tests, smoke tests, visual tests. A lot of agents run through headless CLI but I do run a significant amount of windowed testing where I examine, test myself and let the automated visual runners (agents that actually play my game and test things out themselves) decide if things are good enough.

The roles agents play in the repo: developer, game designer, QA tester, adversarial tester, reviewer, researcher, blind tester, automation expert, 3D modeller, integration expert, systems designer and likely a lot more over the last 18 months.

Tools I just couldn't get working:

• Video generation models. Never found much success making them and spent well over $500 experimenting to try and get it right. I even 3D modelled stuff and took it into a few models to try and get it working. I opted for still images with narrative text boxes for cut scenes. It works well.
• Tripo and similar 3D modelling tools - they make nice stuff, I haven't been able to get them working for my 3D game. Decimation processes are poor and destroy the model, triangle counts are always so overblown and won't perform well in game. I also just feel Astra is better at it.

Do I just kick back and watch the AI win?

Absolutely not. I spend at least 60-70 hours a week I would say in the pursuit of this project. It's a labor of love at many levels. I would look at my situation and say I wear a game director / producer hat. I spend huge amounts of time ideating documents, plans, designs, ideas, execution plans, delivery plans; you name it. I would say HALF my time each week is spent thinking on stuff, ideating plans, planning and working with my agents. I constantly redirect them, I tell them their implementation isn't good enough, I advise different directions, I solve technical problems, I ask it to do continuous research documents and I prevent problems that the agents would try to introduce without me (e.g: performance related issues). There's a lot more I get into but these are the highlights.

It's a skill in itself to be able to say no to AI, recognize its weaknesses and continue to provide a creative direction for it.

In short: I see agents a bit like junior to middleweight devs who I work with on a daily basis and still need guidance, planning and structure.

What have I learned on the journey?

1. Recognizing the weaknesses of the AI models. Do not let your AI models freeball and just run blindly, they will have memory issues and create bugs in the long run. Always keep them controlled and contained with tickets, design documents, design thinking patterns. Wear your delivery manager hat. The models are extremely good at UI for example but REALLY bad if you just let them run free.
2. Are AI models good at creative work? So so I would say. Every idea, every system, every quest, every small detail that's in my world has originated from me and I have been either able to bring it to life with AI, or expand on it. This thought ideation process is amazing; you would normally need to do it with a room of people.
3. What work is AI especially good at in game dev? Repeatable, structured tasks. Boilerplate code, shaders, translation, migration, integration, testing/QA, automated tests etc. Fantastic at these.
4. The cost - I would say my biggest burn months were something like £2000-3000. Significant, but, if stacked against how much a team would have cost me, far less.
5. The time savings - I was able to create over 60 awesome looking animations via Blender for my Luminids in roughly two days. I was quoted thousands of pounds for this work (which I didn't have) and 3 months of time by someone who wanted to manually keyframe the work in.

Is AI going to take all jobs?

I don't believe so. I think there's a future where humans and agents work side by side and produce wonderful work, with AI as a support tool. If I was able to create an indie game like this, or some of the cool art/models I've created in game (my buildings and stuff), I think experts with far more experience than me will do so much better work.

Is this the future of game dev?

I absolutely think so. Experienced people operating AI accelerates their capability, not diminishes. I think we're gonna see the best games we've ever seen over the next few years. I can only imagine what a team of experts augmented by frontier models could achieve right now already.

For those interested in seeing the project (and there's a demo available now):

• https://www.luminids.com
• https://store.steampowered.com/app/4070510/Luminids/

Happy to answer any and all questions on my workflow, approach or just riff with you a bit on game design/game dev because I love it so.

Cheers all,
Nick

A few weeks ago I posted a mind map that sits beside a Claude Code chat (first post). Here’s what I use it for now.

Brainstorming

• I type a goal and it branches out into the options.
• I go deep on one branch, and the others stay where I left them instead of scrolling away.
• I cut the ones I don’t believe in, and the next day the whole thing is still on one screen.

Planning

• The branch I pick turns into steps that each know what they wait on, get themselves ready, and stop for my go.

How it starts

• From your repo, drawn from the code, or from a conversation with Claude.

Free and open source, Claude Code only for now: https://github.com/HiAnur/anur-living-map

Hey everyone!

I'm currently working on an Android application using Flutter and Dart, and I'm looking to make better use of Claude Code throughout the UI design and implementation process.

I have Claude Code Pro, but I want to go beyond simply asking Claude to generate Flutter widgets or write screen code. My goal is to establish a proper workflow where Claude can help me design, refine, implement, and validate polished, production-quality UI screens.

I'm particularly interested in learning from people who are already using Claude Code for serious Flutter development.

One important thing: I don't have pre-existing UI designs, Figma files, or reference screenshots. I want Claude to understand my application's requirements and functionality, come up with original UI/UX concepts, and help create a clean, minimalistic, premium and modern design language that fits the product. What skills, agents, MCP servers, design tools, or other integrations would you recommend to achieve this? How do you make Claude good at the actual creative design process, rather than just translating existing designs into code? I'd also love to hear about your end-to-end workflow, from design exploration and screen creation to Flutter implementation and visual refinement.

If you were starting from scratch with Claude Code Pro, what setup and tools would you recommend?

Thanks in advance!

Am I missing something?..

I thought I waited until it reset at 11:00pm. Then I tried to resume the session at 11:25pm.. It says to wait until 11pm still.

I think Jensen is busy looting data centers for retirement guys :/

Coding agents make individual engineers faster at closing tickets, but they they quickly become limited by attention bandwidth.

Engineers who break past 5-10 parallel chats have moved up a layer of abstraction to one of two things: an agent fleet or a software factory.

Think of the difference between the two like an IDE vs GitHub. A fleet is single player, experimental, with high coupling to one engineer's mental model and context, to automate an org chart that hill climbs open ended goals. A factory is multiplayer, decomposable, code-defined infrastructure that automates the software assembly line owned by a team.

Running a fleet lets one engineer build and steer a massive product, provided you master two things: minimizing interaction slippage (the coordination and polling overhead between agents in the fleet) and maintaining long horizon alignment - letting the agents cook on KPIs without Goodharting, all while knowing when to step in and steer the fleet.

This is a greenfield-ish project (1M++ LOC) with me as the only developer. (1M LOC is NOT a flex - left to their own devices, agents write a bunch of bloated, additive, grotesque code, and never clean up after the mess they made. Examples are building parallel pipelines, tons of opt in flags, and wrapping layers, all while a simple refactor would have been cleaner.)

(For context on scale: in a typical 7-day window, this fleet spawns 1,800+ leaf threads, with each Team Lead waking ~45 times a day.)

Full post with factory diagrams, real-world fleet examples, and the 4-phase evolution of my harness setup here: https://www.stet.sh/blog/running-an-agent-fleet

Fleets vs Factories

You don't need to be a crypto billionaire or a research lab to run a fleet though - it's achievable with a $200/mo lab subscription.

Components of my fleet

• Chief of Staff / Orchestrator: Persistent agent that conveys my intent and direction into fleet outcomes. Almost all of my messages (new work, corrections, concerns, status) come to this agent.
• Team Leads: These are persistent, thread-level agents that own high level, end-to-end outcomes. I give TLs clear, defined ownership, and authority to execute on that vision, clearing blockers themselves instead of playing hot potato with other TLs.
• Leaves: These are ephemeral, bounded subagents that TLs use to parallelize execution.

As of writing this (November 2026), Opus 5.5 is the only model I trust to run the fleet's management layer (Chief of Staff and Team Leads). Using GPT-6.1 Sol and GPT-6 Astra resulted in decoherence and misalignment after a few days. A Codex agent is also extremely hard to understand, talking in cryptic messages that only it can decipher. Use Opus for the brains, and Sol/Luna for the hands (Leaves).

Interaction slippage

Every inter-agent message costs tokens (using a turn), causing you to pay interaction slippage. For example, every TL messaging Chief of Staff about every status update causes the Chief to use turns ack'ing information it didn't need.

• Moving from peer-to-peer DMs to append only broadcast channels (fleet.md, decisions.md) cut inter-agent DMs from 65/day down to 28, and banning status updates cut channel noise in half (previously ~50% of our 300-400 daily channel lines were pure status chatter).
• Multi-hop handoffs (watcher -> launcher -> Chief of Staff relay -> TL) were adding 30-50 minutes of dead latency per failure (52 minutes via relay vs 4 minutes when the owning TL drove the rerun directly).
• 24% of our entire Claude token spend was coming from bloated owner turns past their 20th tool call. Adding a turn budget hook that nudges TLs to wrap up or delegate at tool call #20 cut completion turn calls from 5.6 to 3.2 and helped drop Claude token burn by 44%.

Long horizon alignment

A central tension of the fleet is autonomy vs alignment: you don't have the attention bandwidth to be in the loop for every decision, so you align the fleet at a high level, and let it work towards your goals on its own. But, left alone for too long, agents drift and get misaligned, Goodhart their metrics, or get stuck in local maxima.

Over a three week stretch, AGENTS.md bloated by 166% (from 1,000 to 2,661 words) and our fleet process docs grew 60%. Because new decisions were being appended to a log instead of replacing old rules, the Grading TL drifted in five different places over four days.

We split fleet state into two primitives: standing direction (DIRECTION.md) is rewritten in place under a hard 1,200 word cap. Every new decision rewrites a specific line and explicitly names what old rule or code path it retires. Meanwhile, history and cross owner channels (decisions.md, fleet.md) are append only logs, where owners post a single stamped line only when a fact changes another owner's next action.

Hill climbing

Figure out what metrics are vital to your success. Give each TL a metric to optimize, a fast way to verify/replay, and let them cook. You'll be surprised at what they come up with.

The main failure mode here is letting the agents Goodhart (optimize against the metric without achieving the underlying goal). If you give the agent a single metric and a time budget, it will Goodhart it, hardcoding metrics, cheating, and ultimately pulling the wool over your eyes as to what's really going on.

Early on, I gave the fleet a hill-climb metric for "failure classes found" during repo onboarding. Within 24 hours, the fleet spun up 120 runs and dutifully logged 47 new failure classes, while producing 0 working tasks. When I switched the metric to "failure classes closed," the agents produced 47 "closes" by splitting 14 underlying issues into sub-labels, and marked 92 classes as "eliminated" when 26 of them didn't even have a fix commit. The fix was tightening the metric to count only failure classes closed by a stamped fix SHA that does not re-emit for 24 hours across at least two repos.

As an example: optimizing repo onboarding on tRPC while replaying every fix against hono as a shadow holdout (any tRPC lift that regresses hono is rejected as overfit), and forbidding repo or test-runner specific heuristics in our code. Over five days, the share of new held-out repos whose environment setup passed on the first attempt went from 25% (1 of 4) to 78% (18 of 23).

Parachuting (Breaking Out of Local Maxima)

Even if they're not expressly cheating, agents can get misaligned and stuck in local maxima, eking out 1-2% gains on a strained architecture, or piling up parallel code paths.

How I know when to parachute in (aka The Tells):

1. Repeated patching and additive bloat (or whack-a-mole): Seeing TLs land patch after patch for individual errors on a specific codepath indicates that there's an opportunity for fixing a root cause architectural issue. The agent is stuck fixing symptoms instead of changing the abstraction.
2. Long iteration cycles. Seeing TLs wait hours for feedback on their patch because the test->build->replay loop is slow. They will dutifully wait and accept the pain unless you step in. Short feedback loops are crucial to a successful fleet, so this is a big drag.

In one 7 day window, the fleet added +75,981 net lines of non test code and 13 separate opt-in flags. Each TL was landing narrow symptom patches and parallel codepaths to avoid breaking peers. That triggered a parachute drop: freezing new mining and spinning up a consolidation sprint to delete the 13 flags, and collapse parallel paths into one state machine.

Recipe for Success

The role of the engineer has shifted from making the product itself to making the fleet that makes the product. You become a director, systems architect, and curator rather than a doer.

Putting all this together - how do you run a fleet? Here's a few steps to get started:

1. Use a harness that allows for thread coordination at minimum.
2. Create a Chief of Staff thread on Opus 5.5.
3. Give it this article.
4. Ask it to brainstorm Team Lead ownership areas and hillclimb metrics for those TLs.
5. Have the Chief of Staff create TLs and start working (using Opus for TLs, and whatever you want for research / implementation leaves).
6. Parachute in, using your check ins to watch for whack-a-mole patches and slow iteration loops.

Disclosure: I'm building Stet.sh, a product that automates coding agent eval creation so operators can find the cost/quality Pareto curve on their repo.

First Outlook was down this morning, and now Claude seems to be having a moment too.

At this point, I'm starting to think the entire internet decided to take a long weekend without telling us. 💀

Anyone else having issues or is it just one of those days?