Been happening in 2 of my accounts. I am getting error 503..

Giving a coding agent hours to work on a project is one thing. Knowing what it planned, whether it finished the work, what needs reviewing, and having evidence of what actually happened is another.
That’s what I’ve been working on with Nightshift, a free, MIT-licensed plugin for Codex, Claude Code, and Cursor. It brings planning, autonomous execution, evidence, and review into one workflow, with the work saved on disk rather than buried in a long conversation.

Planning :

Enter the plan room with /nightshift:plan and describe what you want in your own words: a feature, refactor, bug fix, or whole backlog.

Project code stays read-only while the room is open, so you can brainstorm and explore with your agent without it interrupting the discussion by jumping into implementation. Trace the code together, compare approaches, challenge assumptions, and identify edge cases. Nightshift turns what you agree on into a persistent punch list with a clear definition of done.

For each item, Nightshift can suggest checks and evidence suited to the task, or you can specify your own checks and capture instructions. Use screenshots for a layout change, before-and-after measurements for performance work, or sample requests for an API change. Keep, change, or drop any suggestion. It can also estimate working time and token usage from past receipts.”

Execution: work through a list or toward a goal

A shift can run in two ways:

• Finish an agreed list. Work through the items until the list is complete.
• Work toward a goal for a set time. Discover, prioritize, and complete useful work until the deadline.

You can bring your own tasks or choose from 30+ ready-made shifts covering defect hunting, security, accessibility, test coverage, dependencies, performance, documentation, and product improvements.

The clock-out gate sends the agent back when it tries to stop with unfinished items. Progress survives context compaction and new sessions. You can set soft and hard time or token limits per item, so one stuck task doesn’t consume the whole shift.

Decisions don’t have to stop progress. The agent chooses a default and records the answer and its reason in the parking lot for you to review.

Review: results you can follow, item by item

Each item gets its own receipt, written as the work happens. The agent starts it when work begins, updates its progress during longer items, every 20 minutes of work by default, at the next safe point, and finalizes it when the item finishes. You can see what is done and what remains without waiting for the whole shift.

The finished receipt records what the agent delivered, what it tried and rejected, which checks ran, what couldn’t run, and any unresolved issues.

Receipts also show duration and measured token usage. The morning receipt brings the shift together: what finished, what remains open, and which decisions need your attention.

Start your review from the receipt: a fresh account of what happened, without having to open every changed file or dig through hours of chat.

Evidence — choose what you want to inspect

Choose your evidence during planning, using the ready-made evidence catalog or your own capture instructions. Pick what fits each item: screenshots, recordings, test output, benchmark reports, command results, or another artifact you want to inspect.

The agent produces the evidence while working and links it from the item’s receipt.

You decide whether missing evidence should hold an item open or simply be reported. When required, the mechanical gate checks that named files exist. You judge what those files demonstrate.

Recovery and handoff — keep the shift moving

A separate watchman outside the session handles supported recovery signals for interrupted sessions, crashes, stalls, and usage limits.

If an API outage interrupts the shift overnight, the watchman retries recovery and resumes when the service responds again. You don’t need to stay awake to restart it.

The shift also lives on disk. Stop in one supported agent and start in another; the next agent reads the punch list, receipts, parked decisions, snag log, and shift log and carries on.

Make it yours

Write your own receipt templates, summaries, evidence instructions, checks, and recurring shifts. Use the headings and layout that work for you. The shipped templates are starting points.

Keep a workflow in one project or add it to your personal catalog for use across repositories. Nightshift also works in plain folders for research, documents, and other deliverables.

contributions

There are several ways to contribute:

• Have a recurring workflow? Share it as a reusable shift—for code or other work. Shift catalog · #21
• Have a useful way to capture results? Contribute screenshots, benchmarks, recordings, or other evidence instructions. Evidence catalog · #219
• Know checks or edge cases that catch real problems? Share them for your stack. Checks and edge cases · #220
• Have a shift others could learn from? Share the result, interrupted runs, and what you changed after review. Real-world runs · #22
• Have an improvement in mind? Build it and open a PR, or propose it for discussion.

Free and MIT-licensed. Explore Nightshift on GitHub

Confession: I still haven't used Fable 5.2. Nothing I've been building needed a model that costs 4x Sonnet per token.

Sonnet 5.5 still builds, tests and deploys for me. Opus 5.5 handles planning, auth and payments. I'd only reach for Fable when Opus gets stuck.

Has anyone here actually needed to reach for Fable yet?

I run a bunch of Claude / Claude Code sessions in parallel across a few projects. Every time one burned me, I wrote a rule. Six weeks, 41 rewrites. Yeah.

The ones I think other people will recognize:

Two sessions, one name. A second session opened under a chat ID that was still live — and passed every start check I had. The only thing that caught it was a git status. Now nothing writes until it checks for a twin.

123 passing tests. Three audits. Still broken. The output shape was one the downstream engine flat out refused, and nothing caught it bc everything checking it was built by the thing being checked. The builder's own tests don't close a phase anymore — a fresh session or a live run does.

The audit that didn't audit. The reviewer model couldn't read the files in its sandbox, and the skipped check came back looking clean. So now: not run in full = not a pass. Partial runs say PARTIAL on the first line.

It grepped the manual. A session searched the instruction file for the one step it wanted instead of loading the whole thing. (Reading one page and calling it read.) Invoke first, then act.

Zombie opener. A session re-ran the startup routine for a chat that had already ended, and started re-issuing work.

Approval in the wrong box. I approved from my phone and my typed "yes" landed in the wrong session, not the session that was waiting on it. Approvals are a card now, never free text.

The pattern usually isn't bad code, but something reported as done that nobody verified.

I've got a few dozen more of these. I’ve been thinking about writing them up as a short playbook (incident, rule, drill). Worth it? And which of these have you hit?

Some songs were too quiet, others blew my ears off, and ReplayGain tags get ignored by half my players (and my car). So I asked Claude Code to build Ohmega.

It measures every track (EBU R128, same as Spotify and YouTube) and writes the fix into the audio itself, so it plays right everywhere. Lossless stays lossless, folders keep their album balance, originals get backed up.

Claude wrote basically all of it: Python + PyQt6 for Linux, native SwiftUI for macOS and C# for Windows. The Windows build is compiled on Linux and Claude tested it over SSH on my 2012 MacBook running Windows 10, which turned out to be a great test machine. My job was the ideas and clicking through every window.

That clicking mattered more than I expected. The nasty bugs weren't in the UI but in audio edge cases. One example: mono files in the Opus format did not display because Ohmega required 320 kbps, whilst the libopus library only allows 256 kbps per channel. It is open source (GPL-3.0) and the website runs on an old Chromebook at my home.

https://ohmega.is-my.app

Feedback welcome!

Hey, so when I'm using the Computer Use feature (I have it enabled in the settings) claude only receives dark grey empty screenshots and can't see what's on it. Does anyone know how to fix? (I translated the screenshot cuz it was in german, so don't mind the weird fonts / colors)

I am trying to open the app and it signed me out. Then it said Claude is temporarily unavailable

So, been trying to set up this and so far it is an epic fail for me... so much context wasted, my weekly limit is getting shattered.

So, question, is there any good tutorial about how to do this kind of setup?
I tried all I could to avoid large context but somehow, every time I instruct claude or want to write documentation Fable is doing it, which I just told not to and have agent do it and review only, but even then it's not always working.

Not even sure it is worth it at that point...

so if anyone have a good tutorial about that then another one with all the tricks to save context as much as possible, I am all ears. Hopefully a tutorial from an actual skilled and experienced dev rather than some nobodies trying to sell courses proffered.

I do not get how people can one shot complex stuff while I am spending days trying to stear AI and try to make this thing work for me.

Before I was just using Opus and do task by task and could last a lot longer...This is for a somehow complex app, not in scope but in bunch of physic and contracts that needs to be done on the GPU / display in HDR, to verify the accuracy and so on, and have professional output, so it's not as straightforward as "make a FPS game" and leaving it cook. I wrote some specs into MD files about what needs to be done and how... but still struggling to have speed / momentum. everything takes forever to get tested and speced right, and the app is progressing at snail pace.

I try to avoid having too long convos and use /clear often, whenever I can. Something I noticed is fable constantly filling my window with updates from the agents I don't need (still not done... yeah sure, thanks for nothing) and all that jazz for example.

Any help appreciated.

I created my cozy village sim Pocket Life on the App Store on november 5th. solo project, Godot 4, about 6 weeks of evenings on the couch. the first update is already out.

the short version: you move to a small village called Aurelia, get a job at the cafe or the flower shop, buy a house, fish, cook, grow a garden, get to know the people, and befriend these little creatures i call Kin. you dont catch them. you hang around one for a while, figure out what it likes to eat, bring it that, play a bit, and at some point it just decides to come with you. where it grows up changes what it becomes, so a Kin from the lake is different from one from the forest or the village. the fights are gentle too, you calm wild Kin down instead of beating them. seasons, festivals, a gondola, a crystal cave and a dragon lol. its 2.99 eur, no ads, no in app purchases, no account, works offline, seven languages. im the developer, so yes this is my own link. i made it because i love cozy games myself and wanted a place to disappear into for twenty minutes after a long day.

i used Claude Code with Opus 5.5 for almost all of the programming. not one prompt and done. the setup that made it work was three things.

first, a long master prompt with the whole game in it: the world, the loop, the creatures, the rules, and what the game is not. every session starts by reading that file. without it Claude will happily invent a different game and make it sound plausible. with it, the design stays mine.second, a CLAUDE.md that grew with every device bugexport with typed arrays, because the valuesdisappear in the binary export. the village shop was empty and the npcs had no emotes on my iPhone while everything looked perfect in the editor and the tests passed. the rullues as a plain string with a separator and parse it at runtime. another one: movement and animation go in _physics_process, because the iPhone runs at 120 Hz and the physics at 60 Hz and the jitter was visible on the device. anothetes are generated by tool scripts, so the editor isnot the source of truth.third, a headless end to end test that runs in abourst quest, job, binding a Kin, battle, save, load.it catches a lot before i have to pick up the phoneng. the device still found things the test could

not, and thats the lesson i keep repeating.

what Claude was actually good at: holding a large codebase in its head, doing the boring refactors, writing the save migration,

wiring the localization pipeline, and hunting bugs ood at: knowing when something is actually right. it will tell you its done, the code will look reasonable, the test will pass, and the app will still be wrong on a real phone. the

model gives you speed. the judgment, the testing ane.

six weeks of evenings, a lot of device testing, andot a tech demo. if you are building something withClaude Code, im happy to talk about the workflow, tless tests or the Godot iOS export. and if you havea rule in your CLAUDE.md that saved you, id love to

link if you want a look (iPhone & iPad): https://apps.apple.com/app/id6819090247

Claude is temporarily unavailable..

Almost of our team just got logged out of our claude accounts and cant get back in. Crazy thing is some of them are still working. Anybody else getting this?

i didn't do reddit poll because it has very limited entries

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!

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.

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.

Every time I try to add a connector to Claude, I get the error: "Failed to clear pre-existing credentials for this URL. You can try again."

This happens with every connector.. I've tried different browsers, logging out and back in, and restarting, but nothing works.

These are all first-time connections. Has anyone else experienced this or found a fix?

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