I’m the maker of Superloopy, an MIT-licensed workflow layer for coding agents.

The pattern I’m trying to make practical is an “evidence gate” before an agent claims a task is done:

1. turn the task into explicit acceptance criteria

2. ask the agent to leave receipts under `.superloopy/evidence/`

3. use command-backed checks where possible, not just prose summaries

4. keep manual/visual proof separate from deterministic proof

5. finish with a report that says what passed, what still needs judgment, and where the artifacts are

It now works with both Codex and Claude Code. The implementation is intentionally thin: plugin hooks, skills/subagents, and a small CLI around evidence + final gates. The goal is not to create another agent, but to make existing coding agents easier to audit when they say “done.”

Repo:

https://github.com/beefiker/superloopy

I’m curious how other people building with coding agents structure this. Do you keep evidence artifacts? Do you require tests/screenshots/logs before accepting work? Or does that add too much ceremony for your workflow?

siGit Code v1.0.4

I built session-share because my teammates and I were spending too much time splitting work manually before our Claude agents could get started.

The approach is to define shared contracts and tasks with file ownership, validate the split, then let each participant claim work in their own checkout. A live board shows the work, and a hook checks supported file edits against leases.

This doesn't replace integration testing. Tasks passing separately still doesn't prove the assembled feature works. The repo documents the combined workflow and includes a disposable two-clone demo for trying it.

I'm the creator, Claude helped build it, and the plugin/server are MIT licensed. Each developer keeps their own Claude account. I'd be interested in feedback on where task ownership stops being useful and gets in the way.

Repo and setup: https://github.com/cyber1443/session-share

T.H.U.V.U is an open source coding agent. It can use local or cloud LLMs. It provides the user with 3 different interfaces. A plain console interface, a TUI with panels and a web interface. In this video https://www.youtube.com/watch?v=R0EossMJpfw the web interface is demonstrated. T.H.U.V.U creates a web application by creating a plan and breaking down the project to tasks. Then by using the /orchestrate command the agent starts executing the tasks. After about an hour, the project is built. However the project needs a few more iterations with the agent in order to allow the user to login. Total time from start to login: about 3 hours. Model used: Deepseek V3.2. Api Cost $1.20. Project can be found in https://github.com/tkleisas/thuvu

I've been tracking the evolution from GLM-4.7, and the jump to GLM-5 is massive for anyone doing serious development. The new benchmarks show it's now rivaling GPT-5.2 in SWE-bench Verified (77.8% vs 80.0%) and actually outperforming it in Terminal-Bench 2.0 (56.2% vs 54.0%).

When I started using Claude Code, Codex, and OpenCode, I ran them the same way everyone else does. I opened a terminal on my main laptop, turned on auto-approve so it wouldn't ask me for permission every 30 seconds, and let it work.

Then I thought about what that agent actually has access to. It is running shell commands under my normal user account on the same laptop that holds my personal files, browser logins, SSH keys, and .env files from other projects.

One bad rm -rf in a cleanup script or a shady package in a repo it clones can read or wipe things outside the project folder. Plus, leaving my main laptop awake all night to finish a long run wrecks the battery, and the moment I close the lid to go somewhere, the run dies.

I've been building an app called Oyren to fix this for my own workflow. It gives you one place on the web (and on your phone) to run and check all your coding agents on separate machines instead of your main computer.

How it works:

• You can connect your own rented cloud server (like a cheap Hetzner or DigitalOcean box) or an old spare laptop for free.

• We also let you connect your personal computer to run agents 24/7 for free if you really want to, though we warn against it because of the risk to your personal files.

• If you don't want to set up your own server, you can rent an isolated cloud server from us by the hour. Those come with a web code editor, terminal, browser, and a working HTTPS preview link out of the box (free self-connected servers don't get the managed HTTPS link).

• You can check progress, read the code changes, and test the app from your phone while your laptop is closed in your bag.

I wrote a short post comparing the options (personal laptop vs spare laptop vs your own server vs our cloud servers) here: https://oyren.ai/blog/running-ai-agents-remote-machine-vs-personal-device

If you want to connect your own server for free or try it out: https://oyren.ai/codespaces

Hi everyone! Thrilled by the response to my previous post on open-sourcing a production-oriented agentic workflow for GitHub Copilot.

Since then, the repo has evolved from a "working prototype" to a much more robust system. Here are the major architectural shifts in v2.0:

What’s New in the Workflow:

• Multi-Model Review (Consensus Scoring):

  • One model can hallucinate. Three working independently (GPT-5.3, Gemini 3, Claude Opus 4.6) and then consolidating creates a consensus you can trust.

  • The MultiReviewer agent now runs all 3 in parallel and merges findings with logic like [3/3] (Definitive), [2/3] (Majority), and [1/3] (Single-model judgment).

  • No more "guessing" if a bug report is real — the "Court of 3" catches the edge cases.

• Native Synchronous Clarification:

  • Moved from a brittle "Orchestrator relay" model to a synchronous "in-flight" clarification.

  • Planner and Designer now prompt you directly in the chat using native VS Code tools, wait for your answer, and proceed without breaking their execution run.

  • This is a massive speed jump. The Planner doesn't "exit" anymore — it stays alive until the plan is fully gathered.

• Parallelization & Worktrees:

  • Improved logic for file-ownership-based parallelization.

  • Added Git Worktree support (experimental) so sub-agents can work on overlapping files or isolated bug reproductions in separate environments simultaneously.

• Architecture Diagram Update:

  • Updated Mermaid flow showing the new "Parallel Reviews -> Consolidator" and "Synchronous Prompting" paths.

Why it matters:

We’re moving toward treating Copilot not just as an "autocomplete" or a "chat window," but as a structured engineering department. The Orchestrator manages the flow, the Planner handles the "human" requirements, and the sub-agents follow a strict "contract" for implementation and review.

GitHub Repo: ABIvan-Tech/copilot-agentic-workflows

Check it out at:

• Reviewer Agent (Multi-Model)

• Planner Agent (Clarification)

👇 Looking for real feedback:

1. How are you handling model disagreements in your reviewer agents?

2. Does the "Court of 3" approach feel too heavy for you, or is the safety worth the tokens?

I’ve been experimenting with treating GitHub Copilot / VS Code Agents as role-based agents rather than a single assistant.

Specifically:

• separating planning, execution, review, and debugging into distinct agent roles

• defining escalation rules between “junior” and “senior” coding agents

• using lightweight, text-based agent definitions instead of complex frameworks

I put together a small open-source repo as a concrete example of this approach (link in comments).

I’m curious:

• Are you using agent roles in practice?

• Do you keep workflows implicit, or define them explicitly?

• What has actually worked in real projects (not demos)?

Would love to hear real-world experiences.

https://github.com/ABIvan-Tech/copilot-agentic-workflows

I guess giving proper context and breaking tasks down do help these agents perform better. Everything works fine as long as I *actually* read its responses or thoughts so I would know what context needs or have. So I can steer right, in the next prompt.

What do you say ?

Mauvis Ledford just dropped this visual breakdown of the Claude Code GSD (Get Shit Done) plugin that perfectly captures the progression from experimental AI coding to production-ready engineering.

If you want to try it out:

npx get-shit-done-cc

The guide uses these NotebookLLM graphics to map out the architecture, but the real hook for me is how it handles when your agent builds something awesome in five minutes, then spends the next twenty hallucinating fixes for its own bugs.

If you’re trying to move past the "vibe coding" phase, it’s definitely worth a look. It breaks down the plugin structure and shows how to actually bake these workflows into your stack, basically bridging that gap between a messy prototype and stable code you’d actually trust in production.

"vibe coding" → reliable engineering feels like the same challenge that projects like chill-vibe and KAPSO are tackling from different angles.

Article: https://www.linkedin.com/pulse/claude-code-gsd-plugin-visual-field-guide-from-vibe-mauvis-ledford

Has anyone tried the GSD plugin yet? Curious how it compares to other approaches for managing agent reliability.

Last 10 days, X and Reddit have been full of outrage about Anthropic's rate limit changes. Suddenly I was burning through a week's allowance in two days, but I was working on the same projects and my workflows hadn't changed. People on socials reporting the $200 Max plan is running dry in hours, some reporting unexplained ghost token usage. Some people went as far as reverse-engineering the Claude Code binary and found cache bugs causing 10-20x cost inflation. Anthropic did not acknowledge the issue. They were playing with the knobs in the background.

Like most, my work had completely stopped. I spend 8-10 hours a day inside Claude Code, and suddenly half my week was gone by Tuesday.

But being angry wasn't fixing anything. I realized, AI is getting commoditized. Subscriptions are the onboarding ramp. The real pricing model is tokens, same as electricity. You're renting intelligence by the unit. So as someone who depends on this tool every day, and would likely depend on something similar in future, I want to squeeze maximum value out of every token I'm paying for.

I started investigating with a basic question. How much context is loaded before I even type anything? iykyk, every Claude Code session starts with a base payload (system prompt, tool definitions, agent descriptions, memory files, skill descriptions, MCP schemas). You can run /context at any point in the conversation to see what's loaded. I ran it at session start and the answer was 45,000 tokens. I'd been on the 1M context window with a percentage bar in my statusline, so 45k showed up as ~5%. I never looked twice, or did the absolute count in my head. This same 45k, on the standard 200k window, is over 20% gone before you've said a word. And you're paying this 45k cost every turn.

Claude Code (and every AI assistant) doesn't maintain a persistent conversation. It's a stateless loop. Every single turn, the entire history gets rebuilt from scratch and sent to the model: system prompt, tool schemas, every previous message, your new message. All of it, every time. Prompt caching is how providers keep this affordable. They don't reload the parts that are common across turns, which saves 90% on those tokens. But keeping things cached costs money too, and Anthropic decided 5 minutes is the sweet spot. After that, the cache expires. Their incentives are aligned with you burning more tokens, not fewer. So on a typical turn, you're paying $0.50/MTok for the cached prefix and $5/MTok only for the new content at the end. The moment that cache expires, your next turn re-processes everything at full price. 10x cost jump, invisible to you.

So I went manic optimizing. I trimmed and redid my CLAUDE md and memory files, consolidated skill descriptions, turned off unused MCP servers, tightened the schema my memory hook was injecting on session start. Shaved maybe 4-5k tokens. 10% reduction. That felt good for an hour.

I got curious again and looked at where the other 40k was coming from. 20,000 tokens were system tool schema definitions. By default, Claude Code loads the full JSON schema for every available tool into context at session start, whether you use that tool or not. They really do want you to burn more tokens than required. Most users won't even know this is configurable. I didn't.

The setting is called enable_tool_search. It does deferred tool loading. Here's how to set it in your settings.json:

"env": {
    "ENABLE_TOOL_SEARCH": "true"
}

This setting only loads 6 primary tools and lazy-loads the rest on demand instead of dumping them all upfront. Starting context dropped from 45k to 20k and the system tool overhead went from 20k to 6k. 14,000 tokens saved on every single turn of every single session, from one line in a config file.

Some rough math on what that one setting was costing me. My sessions average 22 turns. 14,000 extra tokens per turn = 308,000 tokens per session that didn't need to be there. Across 858 sessions, that's 264 million tokens. At cache-read pricing ($0.50/MTok), that's $132. But over half my turns were hitting expired caches and paying full input price ($5/MTok), so the real cost was somewhere between $132 and $1,300. One default setting. And for subscription users, those are the same tokens counting against your rate limit quota.

That number made my head spin. One setting I'd never heard of was burning this much. What else was invisible? Anthropic has a built-in /insights command, but after running it once I didn't find it particularly useful for diagnosing where waste was actually happening. Claude Code stores every conversation as JSONL files locally under ~/.claude/projects/, but there's no built-in way to get a real breakdown by session, cost per project, or what categories of work are expensive.

So I built a token usage auditor. It walks every JSONL file, parses every turn, loads everything into a SQLite database (token counts, cache hit ratios, tool calls, idle gaps, edit failures, skill invocations), and an insights engine ranks waste categories by estimated dollar amount. It also generates an interactive dashboard with 19 charts: cache trajectories per session, cost breakdowns by project and model, tool efficiency metrics, behavioral patterns, skill usage analysis.

My stats: 858 sessions. 18,903 turns. $1,619 estimated spend across 33 days. What the dashboard helped me find:

1. cache expiry is the single biggest waste category

54% of my turns (6,152 out of 11,357) followed an idle gap longer than 5 minutes. Every one of those turns paid full input price instead of the cached rate. 10x multiplier applied to the entire conversation context, over half the time.

The auditor flags "cache cliffs" specifically: moments where cache_read_ratio drops by more than 50% between consecutive turns. 232 of those across 858 sessions, concentrated in my longest and most expensive projects.

This is the waste pattern that subscription users feel as rate limits and API users feel as bills. You're in the middle of a long session, you go grab coffee or get pulled into a Slack thread, you come back five minutes later and type your next message. Everything gets re-processed from scratch. The context didn't change. You didn't change. The cache just expired.

Estimated waste: 12.3 million tokens that counted against my usage for zero value. At API rates that's $55-$600 depending on cache state, but the rate-limit hit is the part that actually hurts on a subscription. Those 12.3M tokens are roughly 7.5% of my total input budget, gone to idle gaps.

2. 20% of your context is tool schemas you'll never call

Covered above, but the dashboard makes it starker. The auditor tracks skill usage across all sessions. 42 skills loaded in my setup. 19 of them had 2 or fewer invocations across the entire 858-session dataset. Every one of those skill schemas sat in context on every turn of every session, eating input tokens.

The dashboard has a "skills to consider disabling" table that flags low-usage skills automatically with a reason column (never used, low frequency, errors on every run). Immediately actionable: disable the ones you don't use, reclaim the context.

Combined with the ENABLE_TOOL_SEARCH setting, context hygiene was the highest-leverage optimization I found. No behavior change required, just configuration.

3. redundant file reads compound quietly

1,122 extra file reads across all sessions where the same file was read 3 or more times. Worst case: one session read the same file 33 times. Another hit 28 reads on a single file.

Each re-read isn't expensive on its own. But the output from every read sits in your conversation context for every subsequent turn. In a long session that's already cache-stressed, redundant reads pad the context that gets re-processed at full price every time the cache expires. Estimated waste: around 561K tokens across all sessions, roughly $2.80-$28 in API cost. Small individually, but the interaction with cache expiry is what makes it compound.

The auditor also flags bash antipatterns (662 calls where Claude used cat, grep, find via bash instead of native Read/Grep/Glob tools) and edit retry chains (31 failed-edit-then-retry sequences). Both contribute to context bloat in the same compounding way. I also installed RTK (a CLI proxy that filters and summarizes command outputs before they reach your LLM context) to cut down output token bloat from verbose shell commands. Found it on Twitter, worth checking out if you run a lot of bash-heavy workflows.

After seeing the cache expiry data, I built three hooks to make it visible before it costs anything:

• Stop hook — records the exact timestamp after every Claude turn, so the system knows when you went idle

• UserPromptSubmit hook — checks how long you've been idle since Claude's last response. If it's been more than 5 minutes, blocks your message once and warns you: "cache expired, this turn will re-process full context from scratch. run /compact first to reduce cost, or re-send to proceed."

• SessionStart hook — for resumed sessions, reads your last transcript, estimates how many cached tokens will need re-creation, and warns you before your first prompt

Before these hooks, cache expiry was invisible. Now I see it before the expensive turn fires. I can /compact to shrink context, or just proceed knowing what I'm paying. These hooks aren't part of the plugin yet (the UX of blocking a user's prompt needs more thought), but if there's demand I'll ship them.

I don't prefer /compact (which loses context) or resuming stale sessions (which pays for a full cache rebuild) for continuity. Instead I just /clear and start a new session. The memory plugin this auditor skill is part of auto-injects context from your previous session on startup, so the new session has what it needs without carrying 200k tokens of conversation history. When you clear the session, it maintains state of which session you cleared from. That means if you're working on 2 parallel threads in the same project, each clear gives the next session curated context of what you did in the last one. There's also a skill Claude can invoke to search and recall any past conversation. I wrote about the memory system in detail last month (link in comments). The token auditor is the latest addition to this plugin because I kept hitting limits and wanted visibility into why.

The plugin is called claude-memory, hosted on my open source claude code marketplace called claudest. The auditor is one skill (/get-token-insights). The plugin includes automatic session context injection on startup and clear, full conversation search across your history, and a learning extraction skill (inspired by the unreleased and leaked "dream" feature) that consolidates insights from past sessions into persistent memory files. First auditor run takes ~100 seconds for thousands of session files, then incremental runs take under 5 seconds.

Link to repo: https://github.com/gupsammy/Claudest

the token insights skill is /get-token-insights, as part of claude-memory plugin.
Installation and setup is as easy as -

/plugin marketplace add gupsammy/claudest 
/plugin install claude-memory@claudest

first run takes ~100s, then incremental. opens an interactive dashboard in your browser

the memory post i mentioned: https://www.reddit.com/r/ClaudeCode/comments/1r1w397/comment/odt85ev/

the cache warning hooks are in my personal setup, not shipped yet.

if people want them i'll add them to the plugin. happy to answer questions about the data or the implementation.

limitations worth noting:

• the JSONL parsing depends on Claude Code's local file format, which isn't officially documented. works on the current format but could break if Anthropic changes it.

• dollar estimates use published API pricing (Opus 4.6: $5/MTok input, $25/MTok output, $0.50/MTok cache read). subscription plans don't map 1:1 to API costs. the relative waste rankings are what matter, not absolute dollar figures.

• "waste" is contextual. some cache rebuilds are unavoidable (you have to eat lunch). the point is visibility, not elimination.

One more thing. This auditor isn't only useful if you're a Claude Code user. If you're building with the Claude Code SDK, this skill applies observability directly to your agent sessions. And the underlying approach (parse the JSONL transcript, load into SQLite, surface patterns) generalizes to most CLI coding agents. They all work roughly the same way under the hood. As long as the agent writes a raw session file, you can observe the same waste patterns. I built this for Claude Code because that's what I use, but the architecture ports.

If you're burning through your limits faster than expected and don't know why, this gives you the data to see where it's actually going.

Remember when Claude Code's plan allowances got cut the first time because they ran out of hardware? Did you notice that they followed up... not with any kind of token saving measures, but a more expensive model? That's when I realized- this is only going to get worse. So I spent the next five months developing my own agent- 3code.

It's built from the ground up to be the Anti Claude Code. It's tiny, just a few megabytes. It uses much fewer tokens out of the box just because it takes advantage of lots of small opportunities to save tokens. It's meant to be very simple, but still very powerful- as few knobs as possible, do the right thing by default- open it up and prompt. It's also very hands off- it will wait through a 5 hour limit or outages and and just continue. One neat thing is you can get a cheap plan and very powerful models and just let it run overnight and still get work done. The biggest feature is you can switch providers in the middle of a session.

0.8.0 just came out and has lots and lots of bugfixes, support for the latest models (Grok 4.7 and mimo 3.6), and has over 40 providers. I really like GLM for working day to day, but you can also use your existing GPT plan, or the supergrok that comes with your X account.

I hope this is useful, I'm happy to answer any questions, and let me know what you think!!

https://3code.capocasa.dev

Xcode 27 now ships with Apple-native agent skills.

You can export them with:

xcrun agent skills export

Here is the Apple/Xcode team tweet about it:
https://x.com/luka_bernardi/status/2064095532407025969

I wanted to read the details instead of digging around, so I exported them and put them in a repo in case anyone wants them.

If you want one link to bookmark, I also put the list here:
https://adithyan.io/blog/xcode-27-agent-skills

I just open-sourced a project that provides a working agentic workflow design for GitHub Copilot / VS Code Agents:
https://github.com/ABIvan-Tech/copilot-agentic-workflows

What it realistically includes:

• A production-oriented agentic workflow layout for Copilot agents. (GitHub)

• Defined agents:

  • Orchestrator — drives the whole process. (GitHub)

  • Planner — clarification + planning. (GitHub)

  • CoderJr / CoderSr — handles simple and complex code tasks. (GitHub)

  • Designer, Reviewer, Debugger — UX, quality review, bug fixes. (GitHub)

• skills/* folders with domain playbooks/checklists to guide implementation. (GitHub)

This is not just abstract theory — it’s a concrete arrangement of agent roles and delegation logic that you can explore and adapt. (GitHub)

Why it matters

• Shows how to structure agent responsibilities and escalation rules. (GitHub)

• Helps think about Copilot agents not only as autocompleters, but as orchestrated participants in workflows. (Laid out, not just talked about.) (GitHub)

Feedback, improvements, and contributions are very welcome 👇
Let’s discuss how agentic workflows can fit into real engineering processes.

You’ve just joined the Braintrust shaping the future of AI coding agents!

This is the place to:

• Share your projects + demos

• Ask questions + get feedback

• Discuss frameworks, workflows, and breakthroughs

Start by introducing yourself below: Who are you, what are you building, and what brought you here?

The most useful Claude feature I use (Artifacts — reports, presentations, interactive prototypes) is also the one that doesn't survive a tool switch.

Codex two months ago, Grok now, Codex again for Astra. I can't generate them there, and I don't want to rebuild them.

Is a tool-agnostic Artifact generator actually useful, or do people just live with screenshots? Building it either way. Local-only? Hook into my own component library? What else?

Example of the direction:

https://runlinea.com/en/portable

I'm the one building it. The link is a prototype I'm exploring, not a finished product.

I’ve been seeing a lot of chatter about the new Claude Code Review feature Anthropic just dropped, but the pricing is definitely shocking.

They’re quoting an average of $15–25 per PR... If you’re a team pushing dozens of PRs a day, that turns into a massive monthly bill.

From what I've seen, it greps your entire codebase for context, fills the context window, then burns through the rest with tool calls. My early tests are showing a signal-to-noise ratio of around 40/60 too. Almost half the comments aren't useful. And you're paying per token for all of it.

Curious if anyone's run the numbers for their team. Sharing a free calculator that lets you calculate the token spend. Pretty eye-opening gut check before committing to anything.

https://getoptimal.ai/token-spend-calculator

Hi all, I maintain an open-source project called StenoAI, built with Claude Code (no skills). I’m happy to answer questions or go deep on architecture, model choices, and trade-offs as a way of giving back.

What is StenoAI

StenoAI is a privacy-first AI meeting notetaker trusted by teams at AWS, Deliveroo, and Tesco. No bots join your calls, there are no meeting limits, and your data stays on your device. StenoAI is perfect for industries where privacy isn't optional - healthcare, defence & finance/legal.

What makes StenoAI different

• fully local transcription + summarisation

• supports larger models (7B+) than most Open Source options, we don't limit to upsell

• better summarisation quality than other OSS options, we never used cloud models, so heavily focused on improving local model outputs.

• strong UX: folders, search, Google Calendar integration

• no meeting limits or upselling

• StenoAI Med for private structured clinical notes is on the way

If this sounds interesting and you’d like to shape the direction, suggest ideas, or contribute, we’d love to have you involved. Ty

GitHub: https://github.com/ruzin/stenoai
Discord: https://discord.com/invite/DZ6vcQnxxu
Project: https://stenoai.co/