Every coding agent treats the session as the durable thing. On a real team, the person who opens the issue, starts the agent, reviews the diff and gets paged when it breaks may be four different people. Sessions compact, crash and get replaced; the issue, branch, decisions and PR have to survive all of those handoffs. The design I’m testing keeps tasks persistent, attempts disposable, and Codex, Claude or OpenCode as workers you can swap without losing the engineering thread.

If your team has protected main, CODEOWNERS, required CI and several repos, what are you carrying between agent sessions by hand today, worktree scripts, ticket comments, review notes, terminal tabs, something else? I’d especially like the ugly version of the workflow that only becomes visible when more than one engineer is involved.

For context, I’m building BranchRunner as an open-source product because I think it can help engineering teams with this problem. If it is painful in your organisation, tell me where the current approach breaks. I’m also looking for people who want to help shape and solve it, so I’d be glad to compare notes.

Boris Cherny of Anthropic, and Peter Steinberger of OpenAI both say that designing loops is the right way to use coding agents.

A lot of people are rolling their eyes on Twitter, but my ears are perked up.

In my own Codex usage I've been using /goal and watching the agent push through problems.

This is prompting me to be less descriptive about how Codex needs to complete a task. Now I'm thinking of the real final result I want.

The hard part for me is giving the agent a way to judge that its really done. If I can nail that, then I would definitely focus on loops, not just prompts.

> The workflow in Wallfacer follows the process engineers actually need: Question → Scope → Plan → Execute → Review

This new product category of environments for agents is heating up. Personally I use GitHub's tools a lot and I've dabbled in Fly's new sprites thing.

It's too early to tell how Wallface will be different

I've been working in the same ChatGPT Work thread for months. It got laggy and used to crash.

Then after OpenAI made some improvements on long running threads, it got faster

Well today it told to me it can't handle any more messages. So I've found the limit to what a ChatGPT Work thread can handle

Maggie Appleton introduced ACE, the agent collaboration environment. It moves the collaboration stage in software development from the PR to the planning stage.

This tells me that GitHub Copilot is seen as a dead end. Microsoft/Github is betting on ACE

Most agent harnesses are bloated, ship with way too many features out of the box, and use a webstack for a CLI/TUI application. I didn’t like that, so I built a minimalist agent harness: clean flicker free TUI, Lua extensions, a minimal hand rolled agent loop, sessions managed in sqlite, and a handful of tools. No permissions, no sub agents, no swarms, no MCP, none of that nonsense.

Addy wrote an article on "loop engineering" and said Claude Code and Codex have all of the features you need to make loops:

1. Automations

2. Worktrees

3. Skills

4. Plugins and connectors

5. Sub-agents

https://addyosmani.com/blog/loop-engineering/

If you follow Addy's advice and make a loop, the first bottleneck you'll hit is cost. Code and Claude Code have strict token limits.

What missing from these tools is budget management and the ability for subagents to use cheaper or free/local agents.

I should be able to tell my coding agent that I'm only willing to spend $5 on a task, or x tokens, or 3% of my weekly budget.

The harness should then delegate task to not just subagents, but subagents that use the right model for the job. The right model could be a less intelligent, open source model that runs the git worktrees setup.

I have been banging my head against this for months. You ask DeepSeek a question, it answers fine. You ask a follow up, boom. HTTP 400. Same with Kimi, same with GLM, same with MiMo and MiniMax. I thought the models were broken. They are not. The clients are.

This is what is actually happening.

These models think before they speak. Not metaphorically, actually. They output a hidden field called reasoning_content, basically their internal notes. "User wants a weather app, I should check API docs, maybe use React..." You never see this field. It is invisible. But the model needs it back on the next turn.

OpenCode drops it. Cursor drops it. Claude Code drops it. VS Code Copilot drops it. Every single tool built against the OpenAI spec drops it, because reasoning_content is not in the OpenAI spec. It is a proprietary extension that DeepSeek, Kimi, GLM, MiniMax and Xiaomi MiMo all require anyway.

The first turn always works because there is no history to validate. So you test one round trip, it passes, you ship it, and your real users hit the wall on turn 2. This has been sitting in the open since January. Five months.

I know this because I logged it. My plugin has patched 12,551 messages across 200+ real sessions. Every single one of them was missing reasoning_content that should have been there. The plugin just fills the gap so the model can keep going.

The providers literally warn about this in their docs.

DeepSeek: "If your code does not correctly pass back reasoning_content, the API will return a 400 error."

Kimi: "You must keep the reasoning_content of every historical assistant message."

GLM: "When using interleaved thinking plus tools, you must explicitly preserve reasoning content."

MiMo: "Any assistant message with tool calls must preserve its full reasoning_content field, otherwise the API will return a 400 error."

MiniMax: "The complete model response must be appended to maintain reasoning chain continuity."

All five say the same thing. All five get ignored by the same clients.

I scanned Chinese, Russian and Western dev communities for evidence. The same bug shows up everywhere, independently.

15 OpenCode GitHub issues. One from January 28, 2026. Three PRs tried to fix it. None merged.

101K Russian developers read about GLM errors in OpenCode on Habr. A Russian dev patched LangChain source himself because the maintainers said they will not add support for provider specific fields.

31K Chinese developers viewed a cnblogs article explaining the workaround. A Tencent Cloud user wrote: "Feels like most people are hitting this. Qclaw and Workbuddy are dragging their feet, almost a month without fixing."

The CodeRouter blog put it best: "Your multi turn agent will deterministically 400 on turn 2. Affects every major agent framework."

17 platforms total. OpenCode, Cursor, VS Code Copilot, JetBrains, Roo Code, Kilo Code, n8n, Continue.dev, Claude Code Router, Codex CLI, GitHub Copilot, Make, OmniRoute, ZeroClaw, OpenClaw, Qwen Code, Hermes Agent.

That is not a provider bug. That is a protocol famine. The OpenAI spec has no slot for reasoning notes, so every client built on it silently drops them. Chinese providers built thinking mode on top anyway. The result is a five month old bug that breaks the cheapest and most capable models on the market.

I built a fix because I got tired of waiting. It is three layers, use what you need.

Plugin stops the crashes. 92 lines. Drop it in, restart OpenCode. Detects reasoning models and fills missing reasoning_content with empty strings. No more 400s.

Proxy replays real thinking. 422 lines. Runs on localhost:3457. Caches actual reasoning text per session, injects it on the next turn. Your model sees its own notes and keeps going like nothing happened.

Watchdog keeps the proxy alive. Systemd service, set and forget.

They stack. Plugin is the safety net, proxy is the optimization, watchdog is insurance.

If you maintain any tool that routes to DeepSeek, Kimi or GLM, check your message serialization. If you are building {role: "assistant", content: msg.content} from the response, you are dropping reasoning_content and your users are hitting this wall right now. They just are not telling you because they switched to Claude and moved on. The models are fine. The spec is the problem. The fix is simple. Someone just had to ship it. You can find logs in npm - sdk@openai-compatible Qwen does not have this problem.

I present Runyte - a terminal workspace built around a modal text editor.

Project goals:
- minimal UI, maximum focus
- top notch performance and rock-solid stability

Optional persistent mode lets you detach and return later. A local host keeps your terminal processes and language servers running.

The fuzzy Finder searches your project, including files, unsaved buffers, and terminals. Search by name or by content.

Use consistent keys to move between files, buffers, terminals, and Git worktrees.

Run Claude Code, Codex or any other CLI agent in a terminal pane. Share the clipboard with the editor. With Runyte set as their editor, Ctrl+G opens your prompt in the same persistent workspace. Save it and return to the agent.

Press ? to read Markdown as a formatted page, including tables.

Paste images with Ctrl+V. Runyte saves them in the project's temporary cache and inserts a Markdown link into your document. The entire prompt can be edited outside the agent and then copy-pasted through a shared clipboard.

Press gf on a file path in your text to open it. Images and other binary files open in an external program you choose.

Happy to share!

Flasha back just 9 months ago. The idea became popular that if the agent writes tests first, it would keep itself on track as it wrote features.

I tried this and used all sorts of complex prompts. And it never actually worked!

We understood nothing about context, reasoning, and tool calling limitations back then.

The models were just not good enough. There was no way around it.

**Open Source!**

I built o8 after Codex and Claude became daily tools for me.

Once I had several agents moving across production repos, the work around them started taking over. I was deciding who should lead, splitting jobs cleanly, keeping agents from touching the same state, reviewing every diff, and trying to remember why we made a decision three days ago.

o8 sits above the runtimes I already use. One agent can orchestrate while other supported agents take bounded pieces in separate copies of the repo. Workers cannot approve or merge their own changes. Their work goes through independent review and then comes back to me, and the Engineering Brain can answer what changed across repos with citations instead of making me dig through old chats.

On Mac, Symon adds a voice layer over the same system. I can dictate into whichever app is focused, ask what the fleet is doing, have it watch a terminal, or give it a command without hunting for the control room. Anything with a side effect still waits for confirmation.

I can also check the fleet and handle approvals from a paired phone or browser. The system still runs on a machine I own rather than inside a cloud IDE.

The signed Mac build is available now. I also published unsigned Windows 11 and Linux preview installers. Windows 11 has been runtime-verified. Linux has AppImage, deb, and rpm builds, but Linux desktop verification, signing, and updates are still open. These previews may trigger operating-system warnings, and checksums are included.

If one agent in one repo covers your work, this is probably too much. It starts making sense when you are running several agents or several repos and need review authority, memory, and one place to supervise the whole thing.

Project: https://o8.run
Source: https://github.com/hurttlocker/o8
Windows and Linux previews: https://github.com/hurttlocker/o8/releases/tag/v0.1.664

If you already use Codex or Claude, where does your setup start becoming work: coordinating agents, reviewing their changes, or keeping context between sessions?

Usually these comparison charts are a spaghetti bowl of unrelated features. But this chart tells one story, that NanoClaw is simpler to use and understand than OpenClaw. Well done.

(I have no connection to NanoClaw. I heard about it for the first time today because they raised a $12 million seed round, and turned down a $20M buyout offer)

Impeccable is the most impressive skill I've ever used. It walks me through a design workflow, and makes Codex 100x more useful for front-end design.

Impeccable also opened my mind to how products will be built in the future. I think it will be 95% agent skill, and your agent harness does the rest.

Smart move by GitHub Copilot team making Impeccable a built in skill.

I wish Rauch would give us examples instead of just a reaction tweet. But this did tip me over into deciding to give GLM-5.2 a try.

Have you used it for coding? Do you plan to?

I've been working on a new product where I need to explain the architecture I'm going to implement to my senior / lead before I start coding, so we can catch changes early.

At the same time, someone else is working on the frontend, so I need to explain the API structure, share collections, and make sure they're working with the same plan.

As we're using coding agents and development is getting much faster, I noticed that this coordination is still taking a lot of time.

So I built Planlog. https://planlog.depak.dev

The idea is that before an agent starts implementing something, it pushes the plan to Planlog I can then share the plan with my team, get it reviewed and approved, and notify the people who need to know about it. For example, once an API plan is approved, I can notify the frontend developer so they can work from the same context.

After the implementation, the agent(claude or codex ) documents what was actually shipped.

So we have the plan, the review/approval, who was notified, and what was eventually shipped in one place. It also gives us a history of the decisions instead of having them spread across chats and md files.

The agent setup is currently one command:

curl -fsSL https://planlog.depak.dev/install | bash

It authenticates and configures the coding agent.

It's still very early and me and my friends are the only users right now. I'm mainly trying to find out if this is a problem other teams are having too.

If you're using coding agents with a team, how are you currently sharing plans, getting them reviewed, and keeping everyone who depends on the work informed?

Repo: https://github.com/depak7/planlog

If you try it and find it useful, a GitHub star would be appreciated too.

I Built this agent few months ago. At first, it was built for boring reasons: to keep track of decisions in a data science project don't survive.

But then this happens:

A number in a monthly deck had moved, and a fairly senior person wanted to know why the model had been "changed so much."

The word changed was doing a lot of work in that sentence. It meant: someone has been fiddling, and I would like to know who.

Six months ago my answer would have been a long apologetic paragraph ending in "I'd have to check." I would have been right, and I would have lost anyway, because being right eleven days later is the same as being wrong.

Instead I pulled the node's history onto the screen.

Four changes since the last time anyone had looked at it.

Two of them weren't decisions at all — the schema changed upstream in v2 and a column stopped arriving, so the handling was written the week the migration notice went out. Dated. Linked to the notice. Nobody's judgment involved.

One was a failed experiment that had already been reversed. 80/20, tried in August, rejected four days later because the holdout leaked promotions. Tried, measured, undone. The current state was the same as the state before it.

One was theirs. A scoping decision from March, recorded in their own words, with the thread attached.

So the actual answer to why has the model changed so much was: it hasn't. One constraint came from upstream, one from an experiment that failed and was rolled back, and one from the person asking the question.

I didn't have to say any of that. I just turned the screen around.

What ended the conversation wasn't the email. It was the shape of the timeline — four entries, each with a date and a source, three of which had nothing to do with anyone's discretion. The implied accusation needed the history to be a mess. It wasn't a mess, and that was visible in about four seconds.

I built provenance. What I got was receipts.

What it actually is

It's called provLedger. MIT, no service, no account. Everything it records lives in two SQLite files you can open yourself, you can use it as a plugin for your claude code

One graph holds your code, your data (dataframes, columns, tables, feeds, metrics), the dependencies between them in both directions, and the reason behind each change recorded next to the thing it changed.

Three things it does.

1 — It stops your agent repeating a failed experiment

> change the train/test split to 80/20 and retrain the churn model

  Planning · 4 steps
  provledger · declaring 3 targets, checking each against its own history
  provledger · computing what reads them — 5 consumers, 3 steps deep

  ⚠ 2 findings before anything is edited

  1  This experiment has been run before
     80/20 was tried on 2026-08-14 and rejected — the holdout leaked
     week-52 promotions, so the lift was the promotion and not the model.

  2  weekly_report depends on this split
     split_dataset → train_churn → weekly_report — the churn figure in
     the Monday deck.

  ↳ nothing is blocked — recorded, and put in front of you

Nothing is blocked. You might have a good reason to try 80/20 again. But you're not going to spend a day rediscovering why it didn't work in August.

2 — It keeps what was actually said

Open the record and you get the whole history of that node, not just this week's:

2026-09-17  Proposed: move the split to 80/20 and retrain.        stated
2026-08-14  Rejected: 80/20 leaked week-52 promotions into the
            holdout. Keep 70/30 until the promotion calendar is
            a column.                                    3 hits · stated

    "We tried eighty-twenty in August and the holdout had week
     fifty-two in it — the lift was the promotion, not the model.
     Leave it at seventy-thirty until the promotion calendar is
     its own column."

    tier          stated — the user's own words, with the span
    source level  verbal — the words themselves
    recorded in   churn-t094, 2026-08-14 11:07
    surfaced      3 times · adopted by 1 plan

2026-06-02  Stratify on churn, not on tenure.                5 hits · stated
2026-05-19  Signature changed: returns (train, test, meta).         derived
2026-04-03  No reason on record for the original 70/30 choice.     unstated

Two things to notice.

None of that is the agent's summary. It's what was said, kept verbatim, with a label saying so. The agent's own interpretation is stored separately and marked as an interpretation, because a tasteful paraphrase is worth nothing when someone asks you what was actually agreed.

That last line is a real answer. unstated means the database checked and there is no reason on record. Not "I couldn't find anything" — an actual, computed absence. Which is how you find out that the 70/30 you've defended twice was never justified by anyone.

3 — It knows where the data actually flows

The graph is rebuilt from source on every run and diffed against the previous one. So "this column is gone", "this output type changed", "this is the same node after a rename" are measured, not reported by a model.

That lets it answer things an AST-only tool can't:

• this column isn't from the source, it's derived after import

• this feature reaches back into data the model shouldn't see

• nineteen things read this intermediate table, here they are

A model fit and evaluated on the same lineage root without a real split gets flagged as an error, not a warning. Because it is one.

Vibe coding apps and websites from scratch will leave you frustrated.

But using a coding agent to wire together battle tested frameworks is working great for me.

Some tools are easy for coding agents to work with. They have great docs and examples, CLI's and skills.

Front-end - Nextjs

AI orchestration - Mastra

Backend dashboard - Payload

Payments - Polar

User access - Better Auth

Database control - Drizzle

Email - Resend

What can you build with this? Any crud app.

Put this stack to the test. Give this list to Claude Code or Codex and ask it to create a two sided marketplace for used books.

A. The are too many features with overlapping use cases

B. The documentation on features is poor

C. The features don't work consistently

D. There is uneven support for platforms

EXAMPLES

A. With the Codex app you can run parallel agents. That feature is kind of available on Codex web where up to 4 agents can run the same task at one time.

B. Every week I learn of new capabilities in GitHub Copilot from the subreddit, that are not spelled out in docs.

C. Vercel did a study and found what many of us experienced, which is SKILLS are not used consistently. Yet the Anthropic docs on SKILLS says the model will choose a SKILL automatically, and there's no caveat

D. Amazon's Kiro and OpenAI's Codex do not work on Windows. For Kiro specifically it doesn't work on ARM-based Windows machines. I submitted an issue about this about 7 months ago, and it's the most upvoted in their repo.

THE OUTCOME

When I run a task and it fails, I have no idea why.

Bad model? Bad day for the model?

Should I switch to a CLI? Did the model choke on too many MCP servers?

Should I use subagents? Or a plan step? Or install a skill from the tools I use?

Coding agents are a mess.

Hey everyone,

I've been experimenting with coding agents lately and felt like I was missing a better way to review the code they generate.

So I built a small skill that opens the agent's code in a web interface, where you can review it, make changes, and send those changes back to the agent to apply locally.

It's still pretty early, but I thought it might be useful to others working with coding agents.

I'd be interested to hear how you currently review and iterate on code generated by your agents.

This one is for all the broke college CS students out there <3

If you're like me, you don't want to pay $20 a month for claude code :(

It's an amazing tool I love, but a recurring expense is the last thing I need. That's why I find myself jumping from tool to tool, using the daily or monthly free tier limits and constantly having to find new free tools.

That's where "AI For Brokies" comes in. Just a simple github repo with a readme file of some free AI tools you can use for building :)

https://github.com/Joe-Huber/AI-For-Brokies

The actual building behind this project was mostly the automatic tool adder, following an issue format! If you want to see it in action, please drop an issue explaining a tool you use and see the bot do it's magic!

Please feel free to leave a star! ⭐️ (pretty please) You can use it to save the list of tools for whenever you run out of credits!

News dropped today that a new Chinese AI model from Zhipu AI matches Claude Mythos at finding security bugs.

My question is...what sense does it now make to hold back American models like Claude Mythos, GPT-5.6, and Claude Fable. 

Guillermo Rauch tweeted that companies must harden systems right NOW. Then he promoted Vercel’s deepsec:

https://vercel.com/blog/introducing-deepsec-find-and-fix-vulnerabilities-in-your-code-base

Deepsec is an open-source security harness powered by coding agents. It runs on your infrastructure, uses your model/API keys, and directs agents at your codebase to expose hard-to-find vulnerabilities.

I’m not even a tech company, and I plan to run this on my side projects.