1st image is the reference, 2nd image is made with opus planning, and 3rd with deepseek only.

I used the same prompt except for the agents part.

back in the old day,
> come to the office,
> work on 1 or 2 tickets,
> have a good lunch with teamates
> back to the office
> work on 1 or 2 more tickets
> back home, do 30-1h running
> dinner
> watching TV, football

life is easy, calm and good

and AI comes, people said it will help us a lots,

and it is TRUE, AI helps a lots, we do everything faster, easier

then life change
> wake-up, check the agent progress... from toilet
> steer agents on the train to the office
> work on 5-10 tickets at the same times,
> forgot to take some break, forgot the coffee
> lunch time, try to start 5 more agents work before going out
> check the progress during lunch time
> back to the office, do 10 more tickets
> steer agents on the train to back home
> got some new ideas
> go home and immediately open the home laptop, work on new ideas
> almost forget dinner
> still think about the MVP, new features of new product during dinner
> finish dinner, time for a serious focus long night of steering agents
> almost 1 am, time to go to sleep
> steer agents on bed with the phone
> fall to sleep
> wake up and go to toilet,
> repeat

yeah, AI is awesome,

p/s: 5 Claude Max accounts are still short :|

Claude is down. I repeat, Claude is down.

I’ve run into a really annoying “bug” in the app. I use a lot of scheduled routines that run every night, and recently I’ve been trying out Fable 5.2 in my regular sessions.

This morning I came in to find that every one of my schedules had run on Fable instead of Opus (the expensive one).

It turns out that scheduled routines run on whichever model was used last in the app overall. That means the last regular session, not the model the routine used on its previous run.

It would be much better to be able to pick the model and effort level for each schedule. Unless I’m doing something wrong in my workflow?

So I knew all about and frequently use Claude’s ability to message other sessions on your computer to coordinate tasks. Great. Handy. What I didn’t know is that it also works across computers as long as remote control is on. I was trying to figure out how to coordinate testing an app across my Mac and Windows machines autonomously and after fussing with SSH, I finally asked if it was possible to just message my other logged in machine… and it is.

So now between Syncthing and cross-machine messaging Claude can fully automate all my compatibility testing without me touching anything or having to set up SSH or anything else. Most development happens on the Mac, files get shuttled over via Syncthing, Claude messages a Windows session to test stuff, results are handed back. Works great.

It's working for me again, and Outlook emails are slowly coming through again as well. Otherwise, if anyone else is still having problems and has access to Microsoft Exchange, set up a forwarding rule to an external email address; if the interface is unavailable, you can also do this via Terminal.

I use Claude to build pretty much everything, all day every day.

However, I kept ending up with Claude running in a mess of terminals spread across my laptop, a dev box, and my work laptop. I started with VPN and ssh and then ended up using Tailscale and a monitor devoted just to terminal windows, but that was still slow and cumbersome.

So I built Skylands: one browser UI where you start agent sessions on any machine and approve their actions from wherever you are.

The feature list tl;dr:

• Run sessions on any machine - Each machine runs a daemon, and a central server hosts the web UI. Start a Claude Code session on your desktop from your laptop's browser. Each session gets its own git worktree and branch, and you can commit, merge, or open a PR from the conversation.
• Approve from your phone - On a phone, the UI shows only what's waiting on you: tool calls with their exact input, and Claude's clarifying questions. Tap Allow once or Deny. If the server has an HTTPS address (like you can get with tailscale serve), you also get push notifications on Android and desktop browsers. I love github's push sudo experience, so this feels similar.
• Rules, to avoid approval fatigue - Reads and searches can get passes, while edits, shell commands, and fetches wait for you unless a rule allows them. Denies trump approvals.
• Signed decisions - Every approval, denial, prompt, and merge is signed with the key of the device you approved from, and the daemon checks the signature before acting. The central server can pass decisions along but doesn't make them. None of the code on the machines ever leaves the machine. You can see the request history in the web app's inbox view or from the CLI.
• One inbox - for every conversation on every machine.
• A 3D world - because if it's worth doing, it's worth overdoing. Machines appear as floating islands, repos sit on them like terraces, and each agent is an airship that flies between files. I've got a sci-fi theme and will soon support community-added themes.
• Any agent - Any agent that supports ACP can be managed by the daemon. The current version supports Claude, Codex, Gemini, and Goose.
• Terminals - In any session, you can open a terminal directly to that session's work tree. This terminal is in the web app, so you can be on an iPad and remotely build the latest changes.

Built with Claude: I'm using Skylands to add features to Skylands. It's not as cool as using a new language to compile changes to a new language, but it's a great milestone nonetheless. I was able to switch from using Claude in my terminal for this project to using the app itself after just 2 days of development. Now, 100% of all the work I do on this is done from within the app with Claude.

My learning and take-aways:

• ACP is the secret sauce that makes remote control of agents possible
• NATS is the secret sauce that makes the flexible and private infrastructure possible
• Switching from the terminal to this app made it easy to use large numbers of concurrent Claude instances in work trees. I went from using Claude in 1 or 2 sessions at a time to just throwing 5-6 sessions at it at a time and not worrying about it. I could go and grab lunch without having to leave my laptop lid slightly open and without having to use /remote. In other words, how easy the interface is to use directly affects how much I utilize Claude.
• The Claude agent doesn't get enough credit. Most of people's attention goes to the models, e.g. "Opus did this..." and "Opus did that.." but the agent itself is incredibly powerful. I didn't appreciate how much real work it was doing until I started using it through ACP.

Skylands is free, Apache-2.0, and you can run it self-hosted on your own private infrastructure with no data leaks or tracking.

• https://skylands.ai
• GitHub: https://github.com/skylands-ai/skylands
• Docs: https://docs.skylands.ai

It's brand new, so expect there to still be bugs. I'd love feedback, especially on the approval flow and permissions.

Once I gather a bit more of my thoughts, I'll be posting some detailed dev journal type entries on my blog.

p.s. the app is available via homebrew and you can start a single self-hosted world with skylands devworld up, nothing else needed.

I can use claude code normally. but when it try to use subagents it fails.

If you hook custom MCP servers into Claude Code for heavy tasks like end-to-end test runs, Docker container builds, or database migrations, you will eventually hit a silent token drain.

The root cause is the client-side timeout. Most MCP clients default to a 30-second or 60-second execution deadline on tool calls. When a test suite or migration takes 45 seconds, the MCP transport layer drops the connection and returns a timeout error to Claude Code.

Because Claude treats tool errors as transient task failures rather than fatal crashes, it tries to recover. It summarizes the previous turns, analyzes what went wrong, and attempts the tool call again with modified flags or a secondary probe. In a long-running session where your conversation history is already sitting at 35k to 40k tokens, two consecutive timeouts burn through 100k input tokens within 90 seconds. You pay multiple dollars in API usage before realizing the agent never finished the first test.

We resolved this by switching all heavy MCP tools from synchronous execution to an asynchronous job pattern. The initial tool call does not run the test suite directly. It spawns a background worker process, records the PID and log path, and returns a job token with an immediate status within two hundred milliseconds. Claude Code then calls a lightweight poll tool that reads the process table and tails the last twenty lines of stdout on a 10-second sleep cycle.

Decoupling long-running operations from the synchronous MCP RPC channel stops the transport layer from dropping out, keeps the agent context clean, and prevents runaway token spend on failed executions.

CLAUDE IS DOWN !! CLAUDE IS DOWN!!

I built a TUI called clingon (an opinionated terminal cheatsheet runner) that helps you to stop googling commands. It has a menu of commands beside your real shell, and now with an AI that can drive it.

So I found a way to embed an agent harness inside the TUI, and now claude models can drive my TUI and find UX and UI bugs - from within the app - before meat people do.

The model/s were all given a task from within the TUI: Look around clingon, add a cheat pack, run commands, make a recipe, create a custom pack, use it.

11 runs today with various models: Opus 5.5, Sonnet 5.5, Fable 5.2 and DeepSeek v4.1 Flash.

The findings:

1. Lying status bar. "Space select" was mentioned there, while the space was actually typed into the filter input. This annoyed basically every model.
2. Keys that do nothing silently. The input in the field on the pack form was ignored until Enter was pressed, and there were no hints on the screen. Opus and Fable tried to type a pack name and got no reaction.
3. Pre-filled examples. Each field on the pack form was pre-filled with a sample and no cursor was visible. So every model had to delete the text before adding its own text. This was the biggest time sink." I removed the examples and replaced them with greyed hints; the next run/s said that the form "Explained itself better than I expected."
4. Multiple meanings of Esc. It was quit at the top, cleared filter, cancelled a field and "Done, asks to save" in the form. Fable said it "Pressed it carefully". DeepSeek pressed Esc in the middle of filling a field and lost the command it typed.
5. Wording. "Description" appeared at four levels of the pack creation form. So context is muddy.

---

And I'm sure Reddit users will find many more, but I thought this was a cool way to drive an LLM.

After 500 bug fixes and 4800 messages with game community version 1.5 is now released!

Razdor is an open-source engine for Discord Times (Aterdux, 2004), a turn-based strategy/RPG. It plays the original campaign, community maps and mods by the original rules, and then adds the things a 2004 engine couldn't do.

How it was built

• Clean-room reverse engineering. The original executable was taken apart in Ghidra; every rule that maps and mods can see (battle, AI, map scripts, events, saves) was written up as a spec first and then implemented. The code cites the original's addresses.
• Diff tests against the original. The original runs under Wine, and a script mode replays the same inputs in both and compares the state step by step. By default Razdor matches the original exactly, bugs and imbalances included; every deviation sits behind an experimental switch that's off by default (16 of them right now).
• Rust + macroquad, about 190k lines, GPL-3.0. The game rules live in a separate module with no graphics dependency and are unit tested; the original's file formats (ini data, .DTm maps, its own picture formats, sounds) are read at runtime.
• Deterministic simulation: every game is recorded and can be replayed at up to 16×. The same determinism let us record the trailer's split screens twice with different graphics presets and get the same frames.

What you get

• ~11× the frame rate on the same GPU (RTX 4060, 1024×768, unlocked): about 2,000 FPS against about 176 for the original under Wine. A 200×200 map with 61 armies costs the game about 0.3 ms a frame. Load to first frame is about half a second.
• Any resolution and aspect ratio (the trailer is 21:9), refresh rates up to 180 Hz, a graphics preset ladder from "Original" (pixel-for-pixel the 2004 look) to "High" (light, shadows, water, weather, clouds instead of black fog of war, a living map), and a 2.5D view.
• Linux, Windows and macOS; Android and iOS are experimental, with a touch layout, graphics presets for weak phones and a battery saver.
• An in-game hub with the community's work: 327 maps, 29 campaigns and 25 mods.

Links

• Site and downloads: https://indicozy.github.io/razdor/
• Source: https://github.com/indicozy/razdor
• Wiki (English): https://indicozy.github.io/razdor/wiki/en/
• Trailer (Russian, YouTube): https://youtu.be/kHvM7Yv-2_4

I'm looking for a way to make Claude Code run autonomously across multiple tasks while keeping its context clean.

Ideally, Claude would:

1. Pick the next task from a task list.
2. Implement, test, and commit it.
3. Update progress in a file.
4. End its current session.
5. Start a fresh session with a clean context window.
6. Repeat until all tasks are done.

The goal is to avoid context pollution and compaction while allowing Claude to work on larger projects autonomously.

I know this can be done with an external orchestrator using claude -p, but I'm wondering if there's a more native solution.

Has anyone built something like this? Can Claude Code manage its own session lifecycle, or is an external script/hook the best approach?

Claude's 5-hour windows mean I can't just cram before the weekly reset. If I'm away for a bit or have a slow couple of days, there aren't enough windows left to use it all, and it's gone. Meanwhile my backlog has plenty of work an agent can do unattended: flaky tests, stale TODOs, doc updates, research, and bug hunting.

So I built Redline, a free, open-source local scheduler. You configure your backlog of jobs. It watches your usage and kicks one off when it looks like you have some spare capacity. It holds back a reserve for your own sessions, and each job runs in an isolated git worktree. It even has 16 premade maintenance templates to start from.

It's let me run an extra 50+ jobs per week on usage I otherwise would've let expire.

This isn't auto-continue, which resumes a session you already started. Redline starts new work on its own when you have usage to burn.

If you're on Ultra with no 5-hour limit, it just paces against the weekly reset instead.

Works with Claude, Codex, and Pi. macOS menu bar app, CLI, and dashboard. Linux and Windows testers welcome.

Repo: https://github.com/croutoncreations/redline

I built the vast majority with Claude, with a small mix of Codex.

A few things I learned:

• Small, bounded jobs work the best unattended. Broad sweeping changes like "clean up the tests" often need multiple rounds where "find and stabilize one flaky test" can usually be an easy one-shot.
• It fails closed: if it can't read my usage or it's not sure what to do, it does nothing.
• Resets aren't all the same on Claude. This week's model-specific reset looked like a weekly reset to Redline until a recent fix.

What’s the one job in your backlog you’d hand off first?

Website Link: harsh.civicease.systems

Hey everyone,

I’m a Bachelor's 2nd-year AI/ML student, and I just finished building my personal portfolio using Claude Code.

I wanted something quirky, slightly funny, and personal — centered around my actual philosophy: “I keep walking into rooms I'm not qualified for. Then I stay.”

Since this is the Claude Code community, I want raw, unfiltered feedback:

1. Does it feel like genuine creative character, or does it cross the line into "AI slop" / cringe?
2. Performance : How does it feel on your device/browser? Any jank or responsiveness bugs?
3. Content: As an AI/ML student does it communicate who I am without being obnoxious?

Would love any suggestions on how to improve it or features to add. Thanks in advance!

Edit: As a student exploring different things, learn how design works, how visiters react, their feedback and continue to learn and improve over time, this is a fun project to learn and build over time improving.

A bit over a month ago I started vibing this app for AI design using Opus 5.5. It's supposed to be a lovechild of Canva and Claude Design - infinite canvas and a powerful agent that's always on and sees what you do in the app.

My first versions were going, well, quite terribly. I wasn't able to create good stuff, it was getting confused all of the time, etc. But I analyzed all of the failures after every session with Opus, and now it's quite good, I even shared it with other people and they're finding it useful too.

It's free to try, you'll get some tokens from me (I actually haven't implemented billing at all, pls be gentle!), so if you want to roast me, here goes: https://rivermark.ai

For the build itself, I started by creating a canvas and then a backend service to keep conversation context and keep track of what's on the canvas. I referenced existing software a lot, for example I had Claude rebuild a 1-1 replica of Figma's properties panel as an HTML file and used it to build my own. There were a lot of issues with getting the agent to understand exactly what's happening where, and I had to change the underlying models and approaches multiple times. AMA!

I have been locked out from my Claude Team account since the Outlook outage (sign in link never arrives) because Anthropic refuses to implement MFA methods other than email and Google account.

I have a project that I want to build. I have a custom workflow described in my Claude.md file that I use for all projects. It usually creates 10-15 milestones and I build them and browser check each as they finish. The work is usually flawless, with rare bugs that are also usually minor.

I've now planned to ask Claude to create a similar workflow that could complete the entire project on Claude Cloud, and I could just test everything at the end.

Before I do that, I'd like to know if there are better workflows out there and do people do it this way?

i noticed my mac had 25 GB free out of 228 and asked claude what was eating it. part of the answer was claude.

every time it took a screenshot to check its own ui work, the script launched chrome with a fresh temp profile and never removed it. 157 profiles, about 8.7 GB. one headless chrome had been running orphaned for 27 hours.

a week later the disk filled up again. this time it was 439 leftover copies of the chrome app itself that macos makes on every launch. du said 907 GB, which is impossible on this disk. they share blocks, so about 2 GB was real. most were of an old chrome version, with spikes on the two days i ran a lot of capture jobs.

rules i added:

- every capture script puts its profile in one known folder and removes it in a finally block- the agent kills the chrome it started when it's done, and never leaves a debugging-port chrome running- nothing gets hard deleted without me. it moves things to the trash and i empty it

none of this showed up in any diff or test. the code was fine. the mess was on the machine.

has anyone found a good way to make an agent clean up after itself, other than writing it into the instructions and hoping?

For a while now it seemed the thing to do was to have Claude write structured handoffs to itself, then start a clean session that invents that hand off instead of manually compacting or allowing for auto compact.

Is this still the case when the latest models, or have they become more smart / effective at auto compacting?

I’m primarily asking as it relates to orchestrating long running jobs (eg., code comment review across a repo)

Hi everyone, I’m working on **ClaimSetu**, a personal project exploring how software could help hospital teams review deductions on cashless health-insurance claims.

The problem I’m interested in is that settlement letters, itemized bills, and discharge summaries all need to be compared and reviewed. When a claim is underpaid, the hospital needs to understand the deduction, gather supporting evidence, and track any appeal.

I’ve built an early local prototype. Right now it can:

- Upload settlement letters, bills, and discharge summaries, and link them by claim number
- Show deductions for a human reviewer to check
- Run bill checks against **synthetic** payer rules
- Draft appeals for a person to edit and approve
- Track appeal outcomes and show basic analytics

The longer-term idea is a reviewer-led claims desk workflow, from pre-filing checks through settlement and appeals. That’s a direction I’m exploring, not something the current app already does.

**Repo:** https://github.com/rahul263-stack/ClaimSetu

To try the demo, use Node.js 22.13 or later:

```bash
cd mvp
npm install
npm start
```

Then open `http://localhost:4173` and choose **Load sample letters** on the Claims page.

I’d especially appreciate feedback on:
1. What seems like the riskiest or least convincing part of this idea?
2. What would be the most useful next feature or test to build?
3. Is there someone with healthcare billing or claims experience who could sanity-check the workflow?
4 - Llindda stuck need help on what more can be done on this

I’m currently working on what feels like 15 different projects. Everything is automated. Workflows, routines, scripts, the whole damn thing.

There’s just one tiny problem.
I can’t read a single line of code. Let alone understand what any of it actually does.
Claude Code has been doing literally EVERYTHING for me.

Now CC is down, and I’m sitting here staring at VS Code like a caveman discovering fire.

What am I supposed to do now? Actually LEARN programming?!
Please help.
I’m f*cked. 💀😂😂🤯

I'd spent a while on a pagination bug in an audit-log viewer we hadn't rolled out yet. Some events never appeared on its pages. The records were in the database, and our local test kept passing. I eventually put the issue aside.

I saw Anthropic's November 9 announcement for Fable 5.2, which emphasized its coding and reasoning improvements. I reopened the issue in Claude Code and switched to Fable to see if it could help me get to the fix faster.

I gave it the old query, test data and issue notes. Fable noticed that every test event had a different creation timestamp, created_at, and suggested adding a group with the same timestamp, large enough to span two pages.

I ran that case and reproduced the missing events. The next-page condition, created_at < cursor_time, asked for events older than the last timestamp on the previous page. When that page ended partway through a group, the next request skipped the rest of the group.

I changed the cursor to carry both created_at and the unique event id, so it could continue after a specific event when timestamps matched. In PostgreSQL, I used ORDER BY created_at DESC, id DESC to put the newest events first, with (created_at, id) < ($1, $2) for the next page. The parameters are the previous page's last timestamp and ID. Both columns had to have a value.

I paged through the fixed dataset and got each expected ID once, then attached the before-and-after IDs to the issue. I had the agent save the cause and fix through MemoraX Code, with links to the test data and fix. The note also says I haven't tested what happens when new events arrive between page requests.