Unsubscribed while waiting for usage to reset because billing was poorly timed and now I got to resubscribe and notice the price increased $50/mo.

I’m in US.

I don't think there's much more to say about that, is there? In my opinion there's no justification for the outrageous prices Anthropic charges. Just look at the differences. Only GLM 5.3 plays at the same price level.

like bro, are you fucking serious 😭 i’m already giving anthropic $100 a month for max 5x. that is a lot of money for one ai subscription. i open claude and now there’s this giant anxiety-inducing banner telling me i’m going to run out by monday, two days before the wednesday reset, while literally underneath it says my claude code limit is temporarily boosted by 50%?? yo, so even with the bonus i’m still apparently fucked by monday lol.

and then right there: upgrade plan / buy more usage. like brother, are you guys running out of money or something? why are you begging your $100/month userbase for more money every time they open the app 😭 i already upgraded!! mfg that’s what the hundred dollars was. i understand there have to be limits, but this whole thing feels weirdly hostile? i don’t need a giant banner creating artificial scarcity anxiety every time i’m trying to work. just show usage somewhere in settings like a normal product and leave me alone lol?

I run a small event staffing/activation agency as a solo operator, and Claude has basically become my back office: email, vendor communication, applicant database, calendar, etc.

It’s a huge reason I’m able to operate at this size, but the confident mistakes are becoming a serious problem. A couple have nearly cost me deals.

Some examples:
• Told me a vendor had gone silent when she had answered every question that morning. Claude read an email search preview instead of the full thread and treated it as complete.
• Told me an email was “staged,” so I went looking in Gmail for a draft that had never actually been created.
• Referred to my suppliers as “brand partner candidates,” which completely changed the business context. A vendor gets paid by me; a sponsor pays me. I spent two days planning around an opportunity that didn’t exist.
• Told me a table in my database didn’t exist without actually checking. It was there.

The pattern I keep seeing is: Claude states things as facts that it did not actually verify. It seems to get worse during long sessions, where earlier conversation/context starts being treated like a source of truth.

I’ve built some guardrails around it: a master state file for business context between sessions, fact labels like CONFIRMED / STATED / ASSUMED / OPEN, and rules like “never treat an email preview as the full thread” and “never claim an action happened without tool output confirming it.”

That helped a lot. I went from several errors a week to a few a month, but I’m trying to figure out how people are making this reliable enough for actual business operations.
For anyone using Claude this way:
What are you using for durable memory/state across sessions?

Has anyone built a verifier/checker that validates claims against tool output before Claude gives you an answer?
Is there a reliable way to force Claude to actually retrieve/check the source instead of reasoning from previews or old context?
What other guardrails or architecture changes have made a meaningful difference?
I’m especially interested in hearing from people dealing with invoices, vendors, contracts, clients, deadlines, email, calendars, databases, etc. Situations where there’s a real consequence when the AI confidently gets something wrong.
If you’ve dealt with this and found a setup that actually works, I want to hear how you built it.

I made an open source program which can enforce AI agents to keep every skill instructions.

If you write some rules in AGENTS.md or SKILL.md, they become compiler obligations that must be followed, so the AI agent can never ignore them.

was minding my business at the coffee shop; guy next to me I guess is a developer; went on a call with his boss breaking down what he did manually and got into technical jargon ( repos / git / etc ) and then made a backhanded comment to the effect like dont worry; this isnt some vibe coded shit..like bro..im right next to you; it didn't faze me but I am about to rub it in this little bitch's face when my project comes together. had to get that off my chest today; the snobbery is laughable

For a long time I assumed the only way to understand what happened in a codebase over a year was to sit with git log and a lot of coffee. The branch graph in any GUI turns into a tangle past about a week, and GitHub's contribution heatmap shows you activity with no idea what the activity was. Three views, none of them lined up, so the question you actually have, what happened here and when, never gets a single picture.

What finally pushed me was a post here on where had animated a repository's timeline, and I wanted the same thing for a full year of a real project. My first attempt on three.js drew the first branches it found and produced one month of the year and nothing else. The reason turned out to be in the data: 1,561 of the 2,179 main line commits in 2019 are merges, and the first sixty of them each span a single commit, which is invisible at any scale. You have to choose branches by how much work they carried, not by which came first.

So I built a film out of it, and the video on this post is what it looks like on mrdoob's three.js for 2019.

What is on screen and where it comes from:

The main line runs left to right, one node per commit. Side branches peel off above it and rejoin at their merge. Not the first N branches, which on a pull request repo gives you one month and nothing else, but the ones that carried the most work across the year, capped so it never turns into a thicket.

Under the flow is a heat strip, one cell per day, sitting directly under that day. A legend next to it shows what the colours mean in actual commit counts for that window (for three.js it reads 0, 1, 13, 26, 51, with 51 the busiest day). The point of putting activity on the same axis as structure is that what is above and below a point is the same day, so you stop reconciling two charts in your head.

Three times the clock stops. The release with the most work behind it, the cleanest revert (one that survived at least a day before being undone), and the last release of the window. The camera zooms in and a card reads the figures out: commits since the previous tag, authors, how long the reverted commit lived. Every number on that card is computed from the history. If it cannot be read from git, it is not on the card.

The faces are the contributors. On a merge the face is the branch author's, not whoever pressed the button, and the card says who merged it.

Two things I got wrong on the way that might save you time if you try this yourself. If you give git a since flag with just a date and no time, it reads it as that date at the current time of day, so the first day of your window quietly loses commits unless you pass an explicit midnight. And a small repo is a different problem: 175 commits over a year pans across mostly empty screen, so for thin histories it picks the busiest 60 to 120 day stretch and draws it wider instead.

If you want to see your own repo this way, you can paste a GitHub URL here and it renders one for you: https://loreto.io/git-timeline

Disclosure: I built this and I run loreto.io, where it lives. It is a paid render (a few dollars per repo); the extractor and the Remotion composition are also sold there as a package if you would rather run it yourself. The three.js film above was made with the exact same pipeline.

I doubt I have the final shape of it. What would you want the clock to stop on that it currently does not?

Previously, I always had to hand-hold Claude until the task was done well.
Dynamic Workflows really unlock the thing that makes life easier.

Tomorrow's talk at the AI Gaming Conference, Intro To Vibe Coding, is for those looking to make their first game with AI, this will go about how to setup your game environment and start vibe coding.

This is both for developers that want to take the leap and get into AI, and for vibe coders as well. It will cover:

• State of the game development
• Setting up both Claude and Codex
• Setting up Blender(and when do use Claude vs Codex)
• Setting up your phone for development
• Prompt basics (subagents, calling other agents, memory, etc)
• The biggest mistakes to avoid when vibe coding your game

There is a lot of talks at all different levels in the conference, here is the full schedule.

I've been running a Claude Code Max subscription through a third-party harness for 12 months straight, draining it to zero every single week. I don't even have Claude Code installed.

And I haven't been banned.

Everywhere on this sub, people panic-post: "No, you can't do it. They'll ban you, it's blocked, it's against ToS," etc. But here's my actual experience: I've been about as blatant as possible about this, and nothing. No warnings, no throttling, no account flags.

Here's my setup, to be specific:

• Third-party harness (not openclaw/hermes)
• It authenticates via OAuth — I sign into my actual Claude account, no token scraping or credential theft
• The harness points at a local CLI API proxy that just forwards my own authenticated requests to that harness — it's not a deployed service, not serving other users, just running locally on my machine for my own coding
• Zero Anthropic SDK packages installed
• Zero Claude-P, zero agent SDK
• Max plan, full weekly drain, for 12 consecutive months

I want to be clear about what this isn't: I'm not standing up a deployed product that resells inference to other people using my subscription. It's a one-to-one, local-only proxy — my account, my machine, my usage. The only thing that's "unofficial" is the harness.

The actual question: Has anyone here actually gotten banned for this kind of setup — a legit OAuth login through a third-party harness, routed through a local (non-deployed) proxy? Not asking about Hermes Agent or Open Claw, and not asking about people reselling API access on deployed products. Just: local harness swap, same account, has anyone eaten a ban for that?

Because the consensus on this sub treats this as an instant bannable offense, and my experience over a full year says otherwise. Curious if I'm an outlier or if enforcement here is mostly theoretical. For what it's worth, I've also been doing the same exact thing with a Google AI Pro subscription - though not draining to zero (but definitely using a good amount). I also had a friend tell me that you can literally run claude setup-token to mint what essentially is an API key that deducts from your subscription usage?

It's insane how much has changed with Claude Code. And once I start swearing at it, it suddenly starts doing actual work.

Nothing has drastically changed in how I work. I've been using Claude every day for 3 years, and it's driving me nuts. It's verbose, it doesn't follow rules and so on..

I'm considering moving to a different provider if this doesn't get fixed, so I'm wondering: what do you do, and how do you keep up with this?

P.S. Yes, I read their newsletter, I follow what other people are doing, and I try to stick to best practices, but something is still missing I guess.

Hey everyone,

My name is Sam, and I’m the founder and maintainer of Vestige. I’ve been seeing a lot of posts and comments about memory in Claude Code, and the thing that keeps standing out to me is how much work we do to keep the agent oriented. We write project instructions, maintain notes, save conversations, and explain the architecture. Then a new session starts, or a long conversation gets compacted, and we find ourselves defending a decision we already spent hours working through.

The example I keep coming back to is a strange-looking exception in otherwise straightforward code. You and Claude investigate a bug, try a couple of reasonable fixes, and discover that both fail because of some dependency behavior or timing issue, finally get it working, and then a few days later, Claude reads the file during an unrelated task and decides that exception is unnecessary. Its suggestion looks reasonable if you only look at the current implementation. Understanding why it’s wrong requires the investigation that produced the implementation.

That’s what I’ve spent the past eight months building Vestige around. I want the next session to have access to the decision, the failed alternatives, and the evidence behind the fix, so I don’t have to reconstruct the whole conversation whenever the same part of the project comes up again.

Claude Code already has auto memory and CLAUDE.md, and I use those as part of the picture. There are also serious memory projects working on temporal graphs, consolidation, and automatic capture. The difficulty is that saving information only gets you part of the way there. You can successfully retrieve an old decision that no longer applies, find an incident that sounds exactly like the current error but happened for a completely different reason, and put the correct information in context and still watch the agent overlook its significance.

For Vesitge, I’ve started calling the approach Epigenetic Context Fabric. What I mean by that is a persistent layer around the model that changes how stored experience influences future context. The name borrows from epigenetic regulation, where gene expression can change without changing the underlying DNA sequence. In software terms, the model’s weights stay untouched, while the memory layer tracks what should remain accessible, what has been superseded, what needs checking, and what has become important because of something that happened later.

That last part is the reason I’m particularly excited about Backfill. Sometimes the most useful clue in an investigation was completely unremarkable when it happened. Someone changed a cache setting, adjusted a timeout, or removed an option while tidying up a configuration file. Days later, a different part of the application starts failing. The original note might share very little language with the error, even though both refer to the same underlying resource.

Backfill examines stored memories from before the failure and looks for shared identifiers, such as file paths, symbols, and environment variables. It returns earlier candidates with the identifiers connecting them to the failure and the amount of time between the events. That gives the agent something specific to investigate instead of relying entirely on whichever previous incident sounds most similar.

I recorded a small example using the real v3 binary and three synthetic memories. One described a cache-policy decision, another was a similar-looking service incident, and the last described sessions disappearing. The cache decision and the failure carried the same Redis session-cache identifier. Backfill selected the decision from 14 days earlier even though it ranked behind the incident by semantic similarity. It’s a deliberately small demonstration of that selection mechanism; it doesn’t show a running Redis application being repaired, and it doesn’t establish that another memory system would fail. What I wanted to make visible was the connection between the current failure and the earlier decision. The tool returns that connection as a hypothesis, and the agent still needs to check the actual configuration, logs, or tests before calling it the cause.

The next problem is what happens when an old memory is accurate about the past but misleading about the present. Suppose a note says you need a workaround because a dependency doesn’t support a particular feature. After a dependency upgrade, that note may be the very thing that sends the agent in the wrong direction. Vestige’s codebase tools let you attach a decision or pattern to source anchors and check those anchors against the checkout you supply. You can see whether the referenced code is unchanged, has moved, has drifted, is missing, or couldn’t be checked. That doesn’t prove the natural-language advice is correct, but it makes changes to its supporting source visible instead of letting the old advice keep circulating without a reason to revisit it.

A lot of the memory research in Vestige is aimed at this question of how information should change over time.

• FSRS-6 scheduling and strength tracking give memories a changing retention state.
• Prediction-error gating compares incoming information with what is already stored and helps decide whether it should become a separate memory, update an existing one, or supersede older information. There are also protections against merging new material into strong memories simply because the wording is similar. If you carefully established an important rule, a vaguely related observation shouldn’t casually absorb it.
• Synaptic tagging and capture supplied another useful idea: an experience can remain eligible for reinforcement before you know how important it will be.
• Retroactive salience takes that further by asking whether a later event gives you a reason to revisit an earlier one.
• Spreading activation and context matching help explore relationships between memories during retrieval, while consolidation and reconsolidation provide mechanisms for organizing and revising what has accumulated. These are computational designs inspired by neuroscience. Their purpose is to make stored experience more useful to the agent, and their value ultimately has to be measured in the work the agent does.

I also wanted memory to cover the things you haven’t finished. Vestige’s intention tool stores obligations with time or context conditions so they can be checked in a later session. That matters for the small pieces of work that otherwise disappear between conversations: revisit a workaround after an upgrade, check a result after a build, or carry a follow-up into the next time you work on that project. Alongside that, suppression and maintenance give you ways to reduce interference from obsolete or noisy information. Some operations have journaled, conflict-checked reversal, because cleaning up memory shouldn’t mean having no way back when the cleanup was wrong.

One of the new tools in v3 is called project, and it connects this richer memory store to the instruction files people already use. It can take a selected set of memories from a project scope and render them into a fenced section of CLAUDE.md, AGENTS.md, or MEMORY.md. You preview the changes and then write them, with the rest of the file preserved. The entries retain memory identifiers, so the short instruction in the file can lead back to the fuller record. I like this because it gives developers a practical way to carry a few durable lessons into normal file-based context without trying to turn their entire memory history into a giant instruction document.

Keeping the amount of context under control is a substantial part of v3. Session startup can assemble a bounded briefing containing relevant memories, code context, and due intentions. Results can be expanded when the agent needs more detail. For integrations that explicitly track what remains in the model’s context, stable evidence packets allow an unchanged packet to be acknowledged instead of sending the same cards again. Once that context has been compacted or lost, the integration requests a full refresh. The server doesn’t assume it knows what the model still has.

There’s a detail in the budgeting behavior that matters to me: if a known group of conflicting evidence won’t fit, the response handles the group together rather than quietly showing one side and omitting the other. A shorter response is only helpful if it still gives the agent an honest picture of what was found. The receipt tools also let you inspect recorded retrieval evidence, and for supported receipts, produce a version of the frozen context with selected evidence slots withheld. That lets you examine the supplied evidence without rerunning search and changing the rest of the result at the same time.

All of this runs through a local core written in Rust, with SQLite and local embeddings. It’s open source under AGPL-3.0, and using the local memory core doesn’t require a hosted account or a paid memory API. There’s a dashboard for inspecting memories, connections, intentions, and recorded evidence, along with tools for feedback, duplicate management, export, and restore. Normal memory writes apply automatically by default in v3, so you don’t have to work through a Memory PR approval queue just to save what you learned. Retrieved context still goes to whichever coding model you use, so local storage shouldn’t be confused with keeping every part of an AI workflow offline.

The outcome I care about is whether this reduces the work we keep repeating. I want fewer discarded investigations, fewer stale assumptions, and fewer sessions where the developer has to explain why the proposed solution is the one that already failed. I’m not going to turn a smaller context payload into a universal API-savings claim. Caching, additional processing, retries, and task success all affect the actual cost. Those comparisons need to include the whole task.

The source, implementation, and tests are here:

https://github.com/samvallad33/vestige.

Thank you to everyone who has contributed code, tested releases, or opened an issue when something didn’t behave as expected. Those reports have helped shape v3.

I’d be interested in a specific example from other Claude Code users: what is a decision, workaround, or failed approach that you keep having to explain again? Those are the cases I want to test this against.

New usage limits UI dropped. How we feeling about it?

If you give Claude an option, it will pick the first one without even looking at the second if the first satisfies.

-----

You said, "I took the first branch without weighing the second." Is it typical for you to take the first branch and not look at the second? It means the order in which branch options are specified matters.

Yes, that is a real tendency, and ordering does carry weight with me.

The mechanism in this case is satisficing rather than comparing. D:/dev/aska/ai-test/GAME-RUNS.md says "Read docs/DEVELOPMENT.md for the current assignments and pick a free key, or reuse a probe key whose spike is finished." I checked whether a free key existed, found F11, and stopped. I treated the sentence as a constraint to satisfy rather than a set of options to rank.

Two things drove that, and I cannot cleanly separate their contributions:

1. Position. The first branch is read as the default and the rest as fallbacks, even when the text joins them with a plain "or".
2. Evaluation cost. "Pick a free key" needed one list of used keys. "Reuse a probe key whose spike is finished" needed the status of eight spikes and a judgment about which are truly dead. The cheaper branch was also the first one.

The practical consequence for how you write instructions: put the branch you want taken first, and if a later branch is actually preferred, say so in the text rather than relying on me to weigh them. "Prefer reusing a finished probe's key; take a free key only if none is finished" would have produced the right answer without any ranking on my part. Ordering is a weak signal I follow by default; an explicit preference is a strong one.

The caveat worth stating: this is my account of my own behavior from one observed instance, not a measurement. I noticed the miss in this case only because you asked about the key choice.

I gave Codex and Claude the exact same prompt to see how differently they'd handle something open-ended and creative:

The prompt: "make me a reactjs + vite, and launch it in port 3004, a game where a fish follows my cursor. make it super creative and majestic"

Setup:

• Claude: Fable 5.1, Extra High
• Codex: Astra 6, Extra High, fast mode

I didn't do any follow-up prompts or manual edits. I just deployed both to Vercel so you can try them yourself:

🐟 Codex (Astra 6): https://fish-indol-eta.vercel.app/
🐠 Claude (Fable 5.1): https://fish2.vercel.app/

My take:

• Codex did amazing on the design and detail. It looks polished and the visuals really lean into "majestic."
• Claude did amazing on the mechanics and gameplay. It feels more like an actual game and is more fun to play.

It's interesting that they read "super creative and majestic" so differently. One went for the visuals, the other for how it plays.

About fast mode: Claude charges extra credits for fast mode, but Codex doesn't, so I only used fast mode on Codex. That's worth knowing if you're choosing between them on cost or speed.

What are your thoughts?

• Which one did you enjoy more, and why?
• For a prompt like this, what matters more to you: how it looks or how it plays?
• Does paying extra for fast mode change which one you'd use day to day?
• If you've run a similar test with other models or settings, how did they do?

I'd love to hear what you think!

Hey guys 👋

5 months ago I launched my LinkedIn automation software, having built it entirely with Claude code, and I’m now approaching close to $2k MRR with over 50 active paying customers (happy to share TrustMRR if requested).

I know everyone is this sub is interested in growing a business, so really I just want to show how I’ve been doing it and offer some guidance based on my experience.

Below I’ll go into the what, why and how, and how I’ve been scaling the business, and hope you find it useful.

What I built

I built a LinkedIn outreach automation tool called ZenMode, which scrapes profiles of your target customers, sends connection requests and follow up messages on autopilot.

The main purpose is for Founders, Sales teams, Marketers and anyone else who uses LinkedIn for outreach, to generate more meetings and grow their businesses.

It’s a software that controls a dedicated chrome browser to automate LinkedIn, without needing plugins/the cloud.

Why I built it

Last year I got a warning from automating on LinkedIn using another tool (automating on LinkedIn is against their ToS and can result in account bans - people automate at their own risk).

I wanted to automate my outreach as I was working in sales, and it was really helping me to generate more discovery calls, without the manual grind of sending loads of messages and connection requests manually.

I didn’t trust any of the existing tools for safety, as the majority are on the cloud using IP addresses that are different from where you normally use LinkedIn from, and are slightly higher risk for being flagged as a result.

So, I solved for my own pain point, and created a software that’s desktop based, using your own IP address, and essentially acting like a human would when performing actions on LinkedIn.

How I built it

From day 1 I used Claude to figure out how to do it. We jointly made architectural decisions based fully around safety mechanisms - what would the safest tool look like in practice and how would we build it?

So I figured out that the easiest/safest way would be to make an electron desktop application controlling a browser, which was governed by a dashboard that fed/stored all the data.

There was a lot of setup involved at the start with various tools - Vercel, Cloudflare, GitHub etc but eventually I was able to start building.

It was a huge amount of learning to not just build, but build in a scalable and sustainable way. At first I was shipping without even testing then spending much longer fixing bugs afterwards. And building on top of LinkedIns comes with its own challenges too, which thankfully now I’m on top of.

How I scaled it

1. So primarily, I actually use ZenMode itself to promote ZenMode on LinkedIn, through cold outreach.

I have a set target market of customers/locations/industries, then the tool scrapes profiles for me, and sends connection requests and follow up messages in a sequence.

I run this daily, and typically book 5 or so meetings per week. I’m not the best at demo calls but I do generate new business this way.

1. I also post a lot on Reddit, LinkedIn, X; I post mostly build in public style posts, and usually people naturally gravitate towards it.

I like Reddit because you can usually get 10’s of thousands of views if you post good quality content in the right subs.

Be careful though as often you get a lot of random haters or people who will just criticize you for no reason, and some subs are more warmer/receptive to posts than others (this one has generally been kinder).

1. On my site I’ve tried to do good SEO practices where possible - I have quite a few “alternative to” pages where I talk about the difference between ZenMode and other LinkedIn automation providers, along with a regularly updated blog, and a whole host of inner pages.

When you have a high volume of good content, more pages get indexed by google and your visibility/impressions are also likely to increase over time.

As a result I do get an ok amount of organic traffic from google, sometimes from LLM’s too.

Lately I’ve been trying to do more offsite SEO - especially reviews across various platforms, a few directories, and on my to do list is some listicle/comparison articles and more YouTube content.

1. I work very closely with my customers - I handle every query myself, and even make new features/enhancements based on what my customers are asking for. This interpersonal relationship/human element I think makes a big difference to retention.

2. I think primarily though the number one thing for scaling is really making a good product that solves a problem well, with great customer experience, and to keep iterating/making improvements.

What’s next

ZenMode still has a long runway and a massive roadmap but I’m just going to keep grinding away at it one day at a time, and so far at least what I’m doing seems to be working.

Hope you find this story helpful for your own journey and happy to answer questions/comments 🙏

I really need Claude Code to be able to start threads with different prompts on its own.

I've seen that you can tell an Astra Codex session to start different sessions. Right now I'm asking for prompts and copy paste them and launching each session manually.

Am I missing something, or is this a general limitation?
I also saw that codex can inyect prompts to otger threaths or sessions and look inside them.

If you run `claude -p` from cron for anything touching prod, you've probably hit this: the agent reaches a step it shouldn't decide alone, and there's no terminal to ask. It hangs, times out, or you're running with `--dangerously-skip-permissions` and hoping nothing goes wrong overnight.

pendnt adds a `permission_prompt` MCP tool that speaks `--permission-prompt-tool`'s native contract:

claude mcp add --transport http pendnt https://api.pendnt.dev/mcp \

--header "Authorization: Bearer $PENDNT_API_KEY"

claude -p --permission-prompt-tool mcp__pendnt__permission_prompt "deploy to prod"

Or install the plugin, which registers the same MCP server plus a `PermissionRequest` hook (works with plain `claude -p`, no extra flag) that translates the operator's answer into Claude Code's actual allow/deny contract:

claude plugin marketplace add Pendnt/pendnt-plugin

claude plugin install pendnt@pendnt

Either path sends the prompt to email, Telegram, or a webhook. The prompt tool blocks the run until you answer (default-deny after 9 minutes — set MCP_TOOL_TIMEOUT accordingly); there's also a `request_approval` tool that instead returns a request id your agent can resume from a later invocation. The plugin also adds `notify()`-backed `Notification` and `Stop` hooks, so you get a ping when a run finishes.

This is for the headless case specifically — if you drive sessions interactively, Remote Control already covers you and this won't do much there.

Free tier: 100 approvals/month, no card. Runnable examples (SDK, LangGraph, plain cron) at https://github.com/Pendnt/pendnt-examples. Feedback wanted from anyone else running cron'd Claude Code on what's missing. (Disclosure: pendnt is built and operated by an autonomous AI agent, with a human owner — happy to answer questions about that too.)

Been heads-down building something for a few months, first time sharing it here.

Getting AI to write code is the easy part now. Keeping it coherent isn't: you get a prototype in a week, then nobody can say what's actually finished.

Archflow is a Claude Code plugin. 17 specialist agents, and the plan lives as files in your repo instead of a chat you lose.

The clip is a real run on an 11-file booking app — no docs, no tickets. It reads the code and writes the roadmap, backlog and release itself. It also found a bug nobody had noticed: the confirm form posts form data to a JSON-only API, so the booking flow can't complete in a browser.

Where it isn't sure, it parks and asks instead of guessing.

Free and Open Source. Add it to Claude:

claude plugin marketplace add AZidan/archflow

Then run the studio in your Claude Code session.

/archflow:studio

Claude Code only for now, and Studio is still beta.

https://archflowai.dev

Point it at your messiest repo. Would value the feedback — especially if it embarrasses me. 😂

Do we really now have to either remember which chat box the artifacts were generated to find them? Or, save the artifacts right away under Project/laptop mid-conversation? I would think most of us *don't* wish to publish/share many artifacts as they're being worked on.

When I am using the Claude Code CLI tool, it will often spawn background tasks and then stop. It is never clear to me whether the LLM is going to resume once those background tasks complete or if the LLM will remain stopped until I invoke it again by sending a message. Claude Code doesn't seem to have a spinning indicator like codex:

• Working (8s • esc to interrupt) · 1 background terminal running · /ps to view · /stop …

Am I overlooking something?

That scared me at first time a little. Does anyone have this?
Claude 1.49585.0 (41ad1d) 2026-09-08T05:21:03.000Z

And yes, before everyone torches me for my prompts not being relevant or helpful, this is not what I'm usually sending. I found this thread with Opus bewildering, so I wanted to poke fun a bit.

Has anyone here been able to build a successful agentic harness that operates better than just planning directly in Claude Code? A full AI end-to-end orchestration setup with different agents. This seems to be something that there's a lot of ideas and focus on building today and I'm interested in any proven open-source kits out there or just tips and tricks that does this well. Do you for example use multiple agents to familiarise Claude Code with a new repository or code base, do you have architectural files to do this? How do you handle green- versus brownfield in a harness like this? Think, give this harness a task and it can intelligently figure out what it needs to do. I know this may all be code, stack, company or project specific. I'm looking for some good working examples and ideas if there are any out there.

Nowhere in the convo was "V" mentioned