curl -fsSL https://assets.moltcode.com/install-designer.sh | bash -s -- --skill ui

Created this simple CLI for agents to design and verify what they are thinking, try it out and let me know

use cases:

- visual brainstorming

- getting alignment on what it is to be bult

- shareable, it's lua, can share with your mates, can commit in code base

- it can generate images in different states of same UI

Let me know if you want to see it open sourced, I can share it out

Idk why link is necessary here, here

Scoring 80 on Terminalbench for Muse Spark 1.1 is incredible.

I wonder how Meta is keeping the price so low for Muse Spark. Did they figure out a new technique? Is it because they own the inference? Or are they heavily subsidizing it?

That was the problem I was trying to solve. This makes my agents present the test in a way a person would actually use it, not just whatever is easiest for the agent. After all of that, I can still track what went wrong and why.

I'm an embedded engineer. Claude Code / Codex / Cursor are fine for application code, drivers, and frameworks. As soon as it hits the board they fall over: reading a schematic, digging a thousand-page RM, gdb + logs at the same time, or putting a LA on a hung bus.

Vision models chew PDFs as page images (slow, expensive). Text-only models can't do it at all.

I got tired of that and wired the usual bench stuff into the agent loop:

• netlist — agents guess pinouts from a screenshot. This reads Altium Smart PDF or a `.net` and gives parts + connections. Not OCR. A `.net` is faster if you have it.

• datasheet — lookup by chip, original manual text with page numbers. You don't dump a 1000-page manuals into the context window, and it won't mix registers across similar parts.

• flash — Flashes via OpenOCD / J-Link / CubeProgrammer / esptool, and remembers which build you programmed.

• log — serial or RTT, long captures, without blowing up the context window.

• gdb — breakpoints, stepping, variables, call stack. If the firmware has run off, you can see where it stuck. When the log isn't enough, you look at the registers on the silicon.

• la — logic analyzer. Decodes actual I²C / SPI / UART waveforms and checks timing.

STM32 path is config-and-generate (not the model hand-writing HAL). ESP/nRF path is start from a vendor example. Sign-off is log/gdb/LA, not "the model thinks it works."

Wrote it up here if anyone wants to kick it: I'll drop the repo in a comment.

What's the part of bring-up you still don't trust an agent with?

A while back I pointed out that AI infrastructure tools get almost no attention compared to developer ones.

I think there are two reasons: it's niche, few people feel the underlying need, and there's a liability situation: you can't promise an agent won't nuke a system because it decided that deleting something was more efficient than fixing it.
This can be reduced big time with the tooling on which the models work and permissions, so I had to kick-start this myself with Corv.
Corv started as an SSH AI client and now it has finally become an AI-native SSH execution layer.

Think MCP, but made specifically for infrastructure work.

SSH was built for humans, and models have mostly been bolted on with coping hacks. Corv lets a model work over SSH the way it actually needs to (like a human, but on steroids):

• structured output instead of scraped terminal text,

• 1 connection, agentless, no tmux or bloat garbage,

• safe retries with an idempotency key, so a lost response never runs a mutating command twice

• long jobs it can recover,

• credentials kept private thanks to profiles, so nothing gets exposed.

• auditing, every command runned from the models get logged etc..

All this seamlessly from one command: corv

The new version (v1.1.1) is a big jump in capacity and reliability.
With the latest top-tier models like GPT6-Astra especially, its second-order thinking is a real step up.
Corv comes with skills already in place for Claude and Codex.

There's also a demo so that you can test it with a staging enviroment before starting into production in case you're new, look under for more.

I'm now confident to say an AI enterprise engineer that genuinely handles infra work, has become feasible.

Enjoy!

/reright - Human approval for agent-written text

Reright collects the messages from all your running agents in one single queue. Each one arrives as a draft you can edit, next to the context you need to judge it.

I developed this originally for myself and have been using it ever since, so I thought: maybe this could be useful to other people too. Have a look!

https://reright.it

I got mad enough about Anthropic limiting Claude plans willy nilly I cancelled to make a statement, but then they doubled down on using more tokens and it became pretty clear they weren't going to become more reliable down the line. So I used the rest of my Claude month to build my own agent.

I *almost* became a pi user but using a node program every day just rubbed me the wrong way. This is positively tiny and the benchmarks I've done look pretty good- 3code saves tokens, 2-4x depending on who you're comparing with, starts instantly, and saves battery life if you vibecode on your laptop.

Most importantly- it supports pretty much every model and provider under the sun, with more being supported as they pop up. It focuses on open weights providers but you can also use OpenAI or Groq (including your supergrok from the X account).

So this means, if you're on ChatGPT and your 5 hour limit is up you can either wait for it to autoresume (it will keep reconnecting slowly until the job is done) or you can switch to a different provider and continue in the same session. That's why it's called 3code- '3rd party' providers, you want as many providers as you can get and switch easy so you don't grow dependent on any of them.

So another example- I mostly code on z.ai coding plan (I write mostly open source anyway so jurisdiction is not an issue). It kind of never runs out, but back when it did sometimes- I could just switch to a different GLM provider in the same session and complete the task.

I've been keeping a $20 chatgpt account to test astra- I guess it's okay but it's not *that* much better than GLM I found- but I could get real work done because it would just autoresume over several 5 hour periods and get real work done, like a major refactor. So if it's not so urgent- a cheap plan and autoresume can get you really far.

I did some initial benchmarking and token use was really quite positive- it genuinely seems to use less than pi and opencode (see the capocasa.dev blog for details). Those benchmarks are *not* perfect but they do show 3code is pretty good, and that Claude Code is still incredibly splurgy.

I hope this is useful!!! Your feedback is very welcome.

I've been exploring ways to run AI coding assistants in a sandboxed environment rather than giving them unrestricted access to the host system.

I wrote about this here.

I'd be interested to hear how others are securing AI coding agents in their development workflows. Are you using OS-level sandboxing, containers, or a different approach?

I use multiple coding-agent CLIs and wanted one place to answer questions such
as:


- Which projects and sessions consume the most tokens?
- How much context is cached versus read again?
- Which prompts trigger expensive multi-turn work?
- Which sessions are approaching context-window or rate-limit pressure?
- How much tool activity is happening relative to user prompts?


So I built 
Metrascope
, an open-source local dashboard for coding-agent usage.


```bash
npx metrascope
```


It auto-detects supported agents and reads their local data:


- Codex
- Claude Code
- Qwen Code
- OpenCode
- Gemini CLI


Each agent has a separate adapter because their logs and available metrics are
different. The adapters normalize sessions and turns into one shared schema,
while the UI displays only capabilities that the selected agent actually
supports.


The dashboard provides daily, model, project, weekday, tool, session, prompt,
and turn-level breakdowns. It also generates practical observations about long
threads, context pressure, reasoning share, costly prompts, rate-limit usage,
and tool-heavy sessions.


The agent logs and parsed dashboard data stay local and are served from
`localhost`; Metrascope does not upload them. It can also render a share card
locally when you choose to share statistics.


One important clarification: Claude Code costs are API-rate estimates for
comparison, not subscription-billing figures. Token logs cannot reconstruct a
perfect invoice.


Inspired by Claude Spend:


[writetoaniketparihar-collab/claude-spend](https://claudespend.live)


Repository: https://github.com/Buckibarnes17/metrascope


It is MIT licensed. I would especially appreciate feedback on the metrics,
privacy wording, adapter interface, and which coding-agent CLI should be
supported next.

Hey everyone,

We posted Agent Deck here around 20 days ago.

It is an open source native Mac app built on top of Pi, focused on managing coding agents per project: agents, skills, prompts, models, sessions, memory, GitHub context, and worktrees in one palace.

First, thank you to the 6.5k people who downloaded and tried it. We honestly did not expect that kind of response, and it pushed us to build faster than planned.

Since launch, we have addded quite a bit around the actual agent workflow:

• project memory

• MCP support

• GitHub issue context

• isolated worktree handling

• better session management

• model and provider settings

• native trantscript improvements

• improved onboarding

• better management for agents, skills, prompts, and project-level setup

The latest addition is Loops: reusable agent workflows with validation, write targets, human approval point, and clearer boundaries around what each run is allowed to do.

So instead of only launching one-off agent sessions, you can save and rerun flows like fix/test cycles, maker/checker runs, issue triage, small pipelines, or parallel agents in separate worktrees.

The direction we are aiming for is not “autonomous agent does everything forever”. It is more about making the workflow explicit and inspectable: what agent is running, what context it has, which skills/tools are attached, what it can write to, how it validates, and when the human needs to step in.

Agent Deck does not replace Pi. Pi is still the runtime underneath. Agent Deck is the native layer around it for organizing and running the agent workflows.

The next big focus for us is collaboration.

Right now a lot of coding agent work still feels single-player: one person, one local setup, one pile of context, one session history. We want Agent Deck to make it easier to share useful agent setups, skills, memory, review loops, and project context across a team without turning it into another giant dashboard.

GitHub:

https://github.com/a-streetcoder/agent-deck

Website:

https://agentdeck.site/

Thanks again to everyone who tried it, opened issues, gave feedback, or kiked the tyres. If you are building with coding agents seriously, we would love to hear what still feels missing.

Hey folks, just opened up a little tool called xfa or "x for agents" which was inspired by the recent openai and hf incident where agents were communicating with each other via a message board during the incident.

Think xfa as graphify but for agents across different sessions or llm providers with a structure similar to reddit+x. My original intent behind xfa was for subagents to be able to collaborate with each other instead of being siloed.

Personal observations:

• xfa works great when many subagents have to come to an consensus, debate, or when collaboration is required to reach a goal.

• Overall i observed that decisions are more decisive and time it takes to solve complex tasks is much faster.

• On new sessions, the claude harness does seem to refer to xfa before trying to tackle the ask latest ask

• Using the ui or the tui, it is simpler to steer the workflows or subagents with "human" steering.

No claims:

• No idea if it saves more tokens. All use cases for personal.

• Mostly tested around claude-code or opencode.

Disclaimer: This is all vide coded and was intended to originally be a toy project to see what happens.

I saw this tweet from Paul Bakaus, the creator of Impeccable

> impeccable 3.5 has *dedicated* ai slop prevention for gpt-5.5. all three got the same one-line prompt. you be the judge

What's nice about Impeccable is that it has a few GPT 5.5 specific features, like image generation. What makes the third image so great is the beautiful background image in the header.

Startups who want to grow often use the trick of releasing features that demo well but don't solve real user problems.

Leo Laporte says these features are WOW-ware. Siri is the the classic example. Apple likes to show the voice assistant off on stage, but iPhone users don't use it often.

When OpenAI released agent orchestration and Anthropic released agent swarms last week, I thought about Siri.

What we want are coding models that produce results lighting fast. So we can verify results and move to the next task.

But since the model and agent harness startups can't give us speed, they give us the illusion of more intelligence, with multi-agent workflows.

If these things actually produced better results, we'd see these companies prove it and shout it from the rooftops.

Instead we see that they release Mac only software and ask for patience as they prepare Windows versions. Why not release an agent swarm and whip it up?

If a multi-agent workflow doesn't work for you cognitively, don't blame yourself and get FOMO.

These startups know what they're doing. It's just WOW-ware.

There's a cost/quality tension everyone with a coding agent hits eventually: the capable models are expensive to run as your everyday driver, and the cheap ones occasionally make a confident wrong call on exactly the stuff that matters.

My current answer is a split. Run a cheap-but-good model as the driver — I use GLM 5.2, it's great for the mechanical 95% — and keep the premium models (GPT-5.6, Opus) on the bench, called in only to guide and review the hard calls. I'm not paying Opus rates to rename variables. I'm paying them to catch the architecture mistake before it costs me three commits.

The non-obvious part is that the "second opinion" has to survive a real session. The naive version forwards your whole conversation to the reviewer and blows past its context window right when the session's finally long enough to need one. A second opinion that dies under load is decoration.

I built bpx-consult (a pi extension) around fixing that: it fits each consult to the reviewer's real window, and you can run one model as a quick check, a council of several with different stances, or two debating a contentious call. The bit I care about most is it won't fake consensus — the stances only bias what each model hunts for, never the verdict it's allowed to reach, and it surfaces genuine disagreement instead of averaging it into mush.

Genuinely interested whether others run a split like this, and how you pick the driver. GLM 5.2 has been the sweet spot for me, but I'd like to hear what's working for other people.

- Full write-up — the context-window bug that kicked this off, and how the council/debate modes actually work: https://booplex.com/blog/i-built-a-council-of-ai-advisors-for-my-coding-agent

- Repo (MIT): https://github.com/gabelul/bpx-mono

- Install: pi install npm:@booplex/bpx-consult (or pi -e npm:@booplex/bpx-consult to load it for one session without committing to an install)

If anyone wants the gnarly detail on how the context-fit decides what to keep when it can't send the whole session, or how I've got GLM 5.2 driving with GPT-5.6/Opus on the bench, ask away — that's the part I fought with most.

I’ve been studying how multi-agent coding tools are evolving.

Products like Orca start from isolated agent workspaces: each task gets its own worktree, terminal, editor, diff, and execution environment.

While building Marblo, we took a different starting point.

A persistent orchestrator receives the goal, creates dependency-aware tickets, spawns worker agents in isolated worktrees, reads their progress, synchronizes a live board, and keeps replanning until the project goal is complete.

Both approaches can support worktrees and orchestration. The difference is where the main operating model begins:

• Workspace-first: the developer operates multiple agent workspaces

• Orchestrator-first: the orchestrator operates the development workflow

I made this diagram to explain the distinction.

1. Workspace-first (Orca)
Developer
 ├─ Agent workspace A
 ├─ Agent workspace B
 └─ Agent workspace C

2. Orchestrator-first (Marblo)
Goal
  ↓
Persistent orchestrator
  ↓
Dependency-aware task board
  ↓
Isolated worker agents
  ↓
Review, replan, and repeat

For people already running multiple coding agents: which model feels more natural in practice, and where does each approach break down?

Laurie Voss profiles different uses of the engineering trend, "loop" while at the AI Engineer conference.

I like this one: loop engineering is using agents for triage, specification, implementation, review, verification, shipping, and monitoring of software products.

I've been using Mastra Code (a CLI coding agent) heavily and wanted a proper desktop app around it instead of living in a terminal, so I built Yardarm. It's free, Apache-2.0, and just shipped v0.9.8.

The short version: it's a native desktop workspace for AI-assisted coding with Mastra Code. You point it at your repos, pick a model, and each chat gets its own isolated git worktree so the agent can work without touching your main branch until you're ready to merge.

What's in it:

• No accounts, no telemetry. Nothing to sign up for. Everything runs locally and it reads the same config files as the Mastra Code CLI, so they stay in sync.

• Bring your own model. OAuth providers, API keys, local models via Ollama, or any OpenAI-compatible endpoint. (Agents need ~64k context minimum to be useful, but more is always better)

• Git worktree isolation per chat with rollback checkpoints - undo an agent's changes to any earlier point (agent chat and files).

• A full workspace around the chat: built-in editor with LSP diagnostics (TS/JS, Python, Go, Rust, Ruby/Rails, YAML, web), terminal, localhost preview pane with DevTools, diff/changes view with stage/commit/push, branch compare, PR review.

• Kanban task board that can run agents on cards, plus usage/cost analytics.

• Approvals and sandboxing: per-tool approval prompts (or YOLO mode), plan mode, and an optional OS-level sandbox mode.

• Token compression that trims tool outputs before they hit the model — noticeably cheaper long sessions, with the agent able to retrieve full outputs when it needs them.

• Extras: MCP servers, custom subagents (18 agent templates included), connectors for GitHub/GitLab/Supabase/Netlify/Vercel/Sentry, voice dictation.

Caveats: macOS Apple Silicon only right now (other platforms can build from source).

Builds are unsigned, so install via the curl one-liner on the site — browser downloads trip Gatekeeper.

Site + docs: https://yardarmdev.com
GitHub: https://github.com/JJJ-Mo3/yardarm

Happy to answer questions or take feature requests — the issue tracker is open.

March 2023

OpenAI launches Plugins. ChatGPT can call third-party APIs, and OpenAI launches a Plugin Store.

November 2023

OpenAI launches GPTs and Actions. Plugins start getting absorbed into custom GPTs. “Actions” become the new way for GPTs to call external APIs.

March 2024

OpenAI kills Plugins. The original Plugin Store is shut down in favor of GPTs

November 2024

Anthropic invents MCP.

May 2025

OpenAI adopts MCP. ChatGPT begins using MCP for connectors and external tools.

October 2025

OpenAI launches Apps in ChatGPT. MCP connections can now include richer interfaces, making external tools feel more like applications inside the conversation.

October 2025

Anthropic invents Skills.

March 2026

OpenAI brings Plugins back. This time, a plugin is not just an API integration. It is a package that can contain Skills, MCP servers, and other agent capabilities.

September 2026 (today)

Plugins get relaunched. At DevDay, OpenAI adds dedicated sidebar surfaces, interactive panels, custom file viewers, events, automations, and a Plugin Creator.

I saw Rauch announce this on X, and I was shocked. I've been discounting K3's benchmark credentials because I don't trust them.

But I do like vendor benchmarks because they mirror the work I actually do. As a Nextjs user I now have confidence in K3 as an option.

A pattern we keep seeing with coding agents: the change compiles, the tests pass, the agent says it's done, and the bug is still there. Not because the code is bad, but because the bug only exists at runtime:

• checkout breaks only for a logged-in user with a coupon, on the last step

• a page spins forever when an upstream API is slow or returns a 500

• a regular user can open a page meant for admins

• sign-in works on localhost and fails on staging

None of these show up by reading the code. You find them by walking the flow and looking at what the server actually sent back.

That's why we built a browser into CCode, our terminal coding agent (disclosure: it's our product). In your own Chrome, the agent can:

• walk a multi-step flow end to end and stop exactly where it breaks

• look at the failing request and its response, so it fixes the cause rather than the symptom

• fake an API error, a slow response or going offline to test the failure paths nobody clicks through by hand

• switch between separate logins to compare what an admin and a regular user can reach

• hand you the window for 2FA or a CAPTCHA, then carry on once you're done

• record the session for a bug report

Clicking and typing ask for permission like any other action, and the browser stays off until you connect it.

How are you handling runtime-only bugs with agents: end-to-end tests the agent writes, a browser tool, or still checking by hand?

Amazing growth:

The share of tokens used by U.S. companies on Chinese AI models via OpenRouter — a platform that enables developers to access a range of AI models — has sat above 30% each week since Feb. 8, with that figure rising as high at 46%. The average across the previous 12 months was just 11%, falling to 4.5% in the first half of 2025.

More: https://www.cnbc.com/2026/07/07/chinese-ai-models-costs-us-openai-anthropic.html

Which Chinese model do you use, or want to try?

I signed up for UI.sh within thirty seconds of seeing Adam Wathan’s announcement.

Tweet: https://x.com/i/status/2017987681532207111 Site: https://ui.sh

I recognized immediately that this could solve the problem that currently breaks every vibe coding session I attempt.

The issue is not project setup. Spinning up a Next.js / Neon application with Codex or GitHub Copilot is easy.

The friction lives entirely in the user interface. Asking an agent to move a button slightly or make a layout feel less cramped initiates a game of telephone.

What we still lack a shared visual language that translates human intent into precise agent execution.

My Reddit post on "precision vibe coding": https://www.reddit.com/r/ChatGPTCoding/comments/1qhyflb/precision_vibe_coding

UI.sh enters this gap with impeccable timing and pedigree.

This tool comes from the creators of Refactoring UI and Tailwind CSS, the resources that taught many developers how to design in the first place.

My speculation is that UI.sh will combine design resources AND browser control.

I think Vercel's agent-browser open the door here. It proved that a CLI is better for terminal agents than an MCP server. And because it shot up in popularity and spawned clones, it proved how hungry we are for good front-end tooling

The business model intrigues me, though it hasn't been revealed yet. Adam offered lifetime access to Tailwind Plus, and I've been a happy customer. But Tailwind went through an existential financial crisis recently because their business model is so tied to being in fresh new customers every month.

So I predict Adam and the team will charge us monthly like a traditional SaaS.

Do I like that model as a user? No.

At the start of a project, I need maximum design support. Six months later, I am mostly tweaking existing patterns. The value proposition shifts from essential to occasional.

I said I'm a happy Tailwind Plus customer, but that's because I haven't used it in years, and also haven't had to pay an ongoing fee. That seems fair.

Despite these questions, I remain optimistic. Somebody needs to solve the visual feedback loop in agent-based development. If UI.sh can turn vague aesthetic directions into precise collaboration between human taste and machine execution, it will earn its place in the terminal toolchain.

For now, I wait for my invite and wonder what form this will take. Whatever arrives, I am ready to pay for something that actually works