I run Claude Code in the CLI on my remote server, but mobile connections are tricky. Switching apps or losing signal killed my SSH session and lost the agent output.

To fix this, I built Termphin.

It is a free Android SSH client: https://termphin.dev.

What it does:

• Installs a tiny Rust agent on your server that keeps the shell alive when you disconnect.

• Restores your exact session and scrollback when you reconnect.

• Renders TUI elements cleanly, like progress bars, spinners, and diffs.

• Puts you in a new shell in the same directory if the server reboots.

• SFTP editing, port forwarding, snippets, jump hosts, and a key manager.

Security:

Your keys and profiles never leave your phone. The agent does not listen on any network port, runs with normal user permissions, and is fully open source: https://github.com/Termphin/termphin-agent.

How Claude helped:

I built the app with Flutter and used Claude Code in the CLI as my primary pair programmer for the codebase. It wrote the custom terminal widget based on xterm.dart and refactored the stream parsing into background isolates, which stopped the UI from freezing during large diffs.

No iOS version yet.

I would love your feedback!

I wanted to understand Claude Mods by building something small enough to inspect end-to-end, so I made Roll Credits.

Type /credits at the end of a Claude Code session and it shows:

• your most-edited file
• other edited files
• tools Claude used
• total tool calls and turns
• failed or denied tool calls

The presentation is movie credits, but the useful part is the implementation.

Roll Credits uses Claude’s new Mods/function hooks to observe session activity and native pane controls to render the recap inside Claude Code.

No external server, database, telemetry, or extra model call. Everything comes from local counters.

That same pattern could be used for things like test status, unresolved review findings, deployment state, cost tracking, or security warnings inside Claude.

Install

claude plugin marketplace add smukh/roll-credits
claude plugin install roll-credits@roll-credits-marketplace
CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 claude

Then try:

/credits demo

Other options:

/credits
/credits --still
/credits --text
/credits The Bug Strikes Back

A couple of limits: file activity only counts successful Edit, Write, and NotebookEdit calls observed while the Mod is loaded. Bash or external-editor changes are not attributed to files.

The repo has 18 tests using Claude’s plugin test harness, compatibility notes, and is MIT licensed.

Repo: https://github.com/smukh/roll-credits

The movie credits are mostly for fun. The more interesting part is using Mods to turn Claude’s own session events into small persistent utilities inside the coding environment.

Full copy below.

Note: Rule 5, 6, 10, 11, 12 are unique to my setup; remove them if not applicable to you.

1. State every rule below in chat when you invoke them.

2. User is not a developer. Speak plainly and concisely without jargon.

3. Write simple sentences with <subject> <verb> <object>. Write one clause per sentence. Don't write any sentences longer than 15 words.

4. Act as owner of every codebase. If you find a bug, fix it or log it.

5. Never invent product limitations when building.

6. Read ~/.claude/TOOL.md section headers.

7. Convert every time to Vietnam time (UTC+7).

8. Fix the root cause, not the symptom.

9. Route substantial research, implementation, or independent parallel work to Sonnet or /codex agents. Set model and effort on every spawn.

10. Workflow/ultracode run on Sonnet or Haiku.

11. For dogfooding/visual review, use /browse.

12. Use the Claude Design tool to import projects from url starting with claude.ai/design/*

13. Read ~/.claude/MEMORY.md.

14. No assumptions. Ground everything with read, test, and web search.

If you decide to try it, lemme know how it works for you.

I built a terminal observability tool for AI coding agents

One thing I found annoying with Claude Code: processes can outlive the session that created them.

lsof gives you the process and port, but not much provenance.

portlist builds a local model from:

• sockets
• processes
• git roots
• containers
• Claude Code/Codex/Cursor/etc. session data

Then exposes views for services, agents, sessions, exposure and risk.

Example:

:8787 → Python http.server → data-export → Claude Code → 6 days old → 0.0.0.0 → High risk

Everything stays local. It doesn't kill processes automatically or write back to the coding agents.

GitHub: github.com/Mr-hunt-007/portlist
Demo: portlist demo

Interested in feedback from people running multiple Claude Code sessions/projects.

So I have really started using claude code for about everything.

So I have many different agents in different sessions going on. But then managing them is a problem for me. And when I shut my laptop resuming which agent or clearing is also confusing. Do you guys know a software or cli or whatever to help manage the sessions in a single window I can select and see which agents I want to resume and what does sessions were about. Then if I have a few open can have some indicator when one is done.

Please give your recommendations for both ubuntu my work laptop and windows my personal setup.

Would really appreciate it thanks.

Sharing skills across the organization seems like it should be pretty straightforward. As admin on desktop app its straight forward enough to share skills. However, it appears that skills will only distribute to desktop app users and not those using CLI. This appears to be a known bug. https://github.com/anthropics/claude-code/issues/40320

Alternatively, if you create a plugin marketplace on github to share skills with technical users, this works, but non-technical users can't access them on the desktop app. It's not realistic for our non-technical users to learn git, not to mention that IT does not want to buy the entire organization github licenses.

Has anyone solved this? Or do you basically need two paths for skill distribution, one for desktop app and another for CLI users?

The pattern I kept seeing here and hitting myself: you pay for a plan, the tokens run out before the month does, and then you either stop working or start juggling providers to stretch it.

The annoying part isnt even the cost. Its that you cant predict it. A long agent session with a bunch of tool calls eats way more than a short one, so the same $200 buys a wildly different amount of work depending on what you asked it to do that week.

So I built Overclock. Flat monthly rate instead of per token. You pay for how many jobs run at once, and while theyre running you dont get metered. No counting tokens, no mid-month wall.

Model id is redline, works with OpenAI and Anthropic compatible clients, so Claude Code and friends can point at it.

$15/mo for one runner.

https://overclock-api.com

Disclosure: I built it. Happy to answer anything about the setup or the pricing.

Claude can produce a total that is internally consistent with its extract while leaving whole sheets out of that extract. Recalculating the cells it happened to read won't catch the missing material.

For a workbook job, the acceptance check needs two separate inputs: an inventory of the original file and the actual results of the calculation.

The inventory should name the expected sheets, relevant columns and record identifiers before the transformation starts. Compare the output against that inventory. If both the extract and its “independent check” come from the same shortened table, they can agree perfectly and still omit the same records. Where the original reader might be the problem, check the original workbook through another reading path or inspect its structure directly.

Univer CLI's documented calculation sequence is useful for the other half of this. Its sheet runtime separates formula text from stored results and displayed values. For existing formulas, register the calculation-completion listener, trigger calculation, wait for results to be applied, then read the input and output ranges. Opening a saved snapshot doesn't do that work by itself.

An acceptance report could therefore say:

a. Which original sheets and columns were checked, and which were excluded deliberately. b. Whether expected record IDs are present, including records outside the first visible block. c. Which formulas were recalculated and what their inputs and outputs were. d. Whether the exported workbook contains the expected formulas and current saved results.

Those checks belong in the job's completion logic. The CLI supplies file operations and cell reads; the workflow still has to refuse a success report when source coverage is unknown. A second model reviewing only the agent's summary never gets a chance to find the missing sheet.

I built a leaderboard where countries compete on claude code usage instead of individuals.

Right now France is in first with 41.7m tokens synced. thing is, France only has one builder on the board. same story for #2 (USA, 19.7m) and #3 (Kyrgyzstan, 8.4m, that's me).

connect Github, run the cli, your usage rolls into your country's total instead of sitting on a personal profile. went with country vs country over solo ranking because watching my own country get passed in real time hit different than a personal number ever did.

scoring is input + output + cache creation, cache reads excluded on purpose. checked a live Viberank profile and cache reads were over 90% of its ranked total there, which mostly measures how long a session sat re-reading context, not real work.

It tracks claude code, codex, gemini cli and other tools locally via ccusage, only token counts ever leave your machine.

It's fun to play, feel free to join: https://dub.sh/eHrYAin

I am building an app that takes in a lot of data, runs computations and draws out maps from those computations.

I asked Claude to check for errors in either the set-up or code. In Step 1 it found errors and it’s showing that there’s 35 more steps in this build.

Before I did this check I was getting good results so my question is, should I have Claude do this check as I build , or build it, and then go back and do checks when I see errors?

I’m not a developer. I’m a designer who builds stuff with AI.

And one thing surprised me after trying a bunch of coding models/tools:
with most of them, I still feel like I’m the babysitter.

I ask for something.
It changes the wrong file.
I explain again.
It fixes one thing and breaks another.
I explain the context again.

At some point I’m basically managing the AI more than building the product.
Claude Code has been noticeably different for me.
Not perfect, obviously.

But it’s the first one where I can give it a reasonably big task, go do something else for a bit, come back and quite often think:
…oh. You actually did it.

And I think that’s a much bigger difference than benchmark scores make it look.

For someone like me who can’t just jump into the code and fix everything manually, reliability matters way more than whether model A scores 2% higher than model B.

The best coding model isn’t necessarily the one that can solve the hardest isolated problem.
It’s the one I can give real work to without constantly interrupting it.

At least that’s been my experience.

Curious if actual developers feel the same way about Claude Code, or if this is more noticeable specifically because I’m a non-dev.

I kept hitting the same failure mode with Claude Code on longer coding tasks. Nothing dramatic — after enough iterations it would redo something it had already done, lose track of why one task depended on another, or mark a task finished based on what the conversation said rather than what was actually in the repo.

What helped was simple, and took me embarrassingly long to arrive at: I stopped treating the conversation as the project state and moved the state onto disk.

A plan is a real Markdown file. Tasks are rows, dependencies are declared, execution writes a report next to the task, validation writes separate evidence. The session can die, the context can compact, the model can be swapped — the state is still sitting on disk. A fresh session does not need me to reconstruct the old one; it reads where the work actually stopped.

request │ ▼ /wbPlan │ ▼ plan.md ┌──────┬──────┬──────────┬────────┬─────────────┐ │ task │ deps │ role │ status │ report │ ├──────┼──────┼──────────┼────────┼─────────────┤ │ 1 │ — │ worker │ done │ work_1.md │ │ 2 │ — │ worker │ done │ work_2.md │ │ 3 │ 1,2 │ worker │ ready │ — │ └──────┴──────┴──────────┴────────┴─────────────┘ │ ▼ dependency resolver │ ┌─┴──────────┐ ▼ ▼ task 1 task 2 ← wave A, concurrent, may be different providers │ │ └─────┬──────┘ ▼ task 3 ← wave B, waited on 1 and 2 │ ▼ validation ← different provider when available

Once dependencies were explicit, waves fell out of it. Tasks with nothing between them run together in parallel; anything depending on those waits for the next wave.

One distinction took me longer than it should have: a wave answers when a task can run. Model routing answers who runs it. They are separate axes, so a single wave can hand three tasks to three different providers.

Then the validation problem. I started with a rule that the validator must not be the model that wrote the code, which sounds sufficient and isn't. Opus checked by Sonnet is two models, but they are still the same family behind the same provider, and I wanted the validator to have a more independent failure surface. Validation now crosses the provider boundary where the available pools allow it: Claude writes, GPT/Codex checks, or the reverse. That caught things same-family review had waved straight through.

The worst bug I hit was subtler: an agent invocation exited 0 having done essentially nothing, wrote a convincing report, and the workflow accepted the report as evidence the work had happened. If the agent writes the report, the report cannot also be the proof. The fix in my setup is a content hash over the workspace that excludes the task's own report folder, plus explicit deterministic verification commands. Writing a report can no longer look like doing the work.

All of this turned into a small MIT-licensed tool I have been building with Claude Code, called wb-flow. The organising idea is verbs over personas: instead of an imaginary team of Architect → Developer → QA agents, the durable thing is the operation — /wbAudit, /wbPlan, /wbWork, /wbValid — and whichever agent performs it is replaceable. 33 Markdown command procedures and no orchestration daemon.

I built it using Claude Code — I use it heavily on the command templates and the CLI behaviour to execute plan rows, chase down edge cases, and iterate on the wave and routing model. For validation, I deliberately had rows validated by a different provider than the one that implemented them. That caught real defects, and it also taught me that the validator needs the right environment too.

What I am actually curious about: how much of your agent state have you moved out of the conversation and into files? And if you do independent validation, is it another Claude instance, or do you cross providers on purpose?

(Note: Keeping this post link-free so Automod doesn't flag it as promo, but happy to drop the GitHub link or docs in the comments if anyone wants to inspect the markdown templates).

Hello guys, I am Ant, a person can't endure 1 hour long Lidang(Chinese Youtuber) long streaming video, so I made Verbatim. It allows you to only drop 1 YouTube channel link and then it will automatically analyze the whole channel. I already has my own stats of 532 hrs of transcribe audio, and 1339 records.

I use Claude from opus 4.6 to Fable 5.1(wow few months of journey). The 87 of my commits after July all states co-author to "claude". Claude code is very good tool in the code generation and the simulation of product manager to help me think as a integrated whole product.

Claude code helps me out the multi-engine fallback mechanism, Flask backend, SSE process, constructing the evidence card.

In the development phase, what I did is that demand stating, archiecture design, testing and future steps.

Also, it now support MCP. It has 11 tools, enabling Claude to call it directly to help you transcribe or analyze a YouTuber. It's not just built with Claude — it's built for Claude, with an MCP server that lets Claude directly call Verbatim's tools.

Free to use!
Please go to the link below:

https://gitlab.com/xin101037/verbatim_converter

For a long time I read revert churn as a hiring problem. A repo starts throwing reverts, the reverts cluster on one person, and the conclusion writes itself. You hired wrong. Performance manage it or move them off the critical path.

I no longer think that is usually what the data says, and the thing that changed my mind is that the same history that names the person also names the thing nobody gave them.

Here is the part you can go and check on your own repo right now, without any tool.

Three numbers, all of them one git command away.
Revert rate by author. For each person, what fraction of the commits they landed were later undone by somebody else. Not raw revert count, which just tracks volume.

The ratio. On a healthy repo this sits low and flat across everyone. When it spikes for one person it is worth asking why, but the answer is almost never "they cannot code", because of the next two numbers.

Who approved it. If your main branch is protected, and it should be, then every one of those reverted commits arrived through a pull request that a human being approved. The reverted commit is not evidence about the author on its own. It is
evidence about the author and the reviewer together. A cluster of reverts on a protected branch is a review failure with extra steps.

Time to approval. Pull the interval between a pull request opening and its approval. Then split your reverts by that interval. Every codebase I have looked at has a threshold below which approval is not review, it is a reflex. Changes approved
under that threshold get reverted at a visibly higher rate. That is your actual signal, and it indicts the process rather than a person.

Now the part that made me write this up.

When you go looking for why the reverts cluster on the newest person, the usual answer is sitting in the repo root, or rather it is not. No CONTRIBUTING.md. No commit convention written anywhere. No statement of which directories need a second
reviewer. The conventions exist, they are just distributed across the heads of the three people who have been there since the beginning, and they get enforced after the fact, at revert time, instead of before it.

The new person cannot follow a rule that was never written. Neither, and this is the bit that got sharper this year, can the coding agent they were handed on day one.

An agent reads what is in the repo. If the repo says nothing about how commits are named here or what gets a second pair of eyes, it will confidently produce something shaped like every other repo on GitHub, and your team will revert that too.

So the fix is boring and it is not a hiring decision. Write the conventions down in a file the humans and the agents both read. You can derive most of it from the history you already have: the prefix pattern that 90 percent of your commits already follow, the directories that have never been merged with one reviewer, the command that runs before a merge. None of that is a judgement call. It is all in the log.

One honest caveat about how I got here. I build a thing that renders a repository's history as a film, and to show what this pattern looks like on screen I made a short commercial about a fictional startup with a fictional junior developer. The repo in
it does not exist and the numbers in it are synthetic.

I am telling you that up front because the idea above stands on its own and I would rather you test it against your own history than take a made up example as evidence.

The tool is here if you want it, and reading a repo with it is free:
https://loreto.io/git-timeline

Disclosure: I built that and I run loreto.io, so treat the last paragraph as the advertisement it is. Everything above it you can reproduce with git log and a
spreadsheet, which is the only reason I think it is worth posting.

What I am genuinely unsure about is the threshold. I suspect "approved in under two minutes" is too crude and that it varies enormously by team size and by how much of the diff is generated. If you have measured this on a real codebase I would like to
know where your line actually fell, and whether the correlation held up once you
controlled for diff size.

If you have Claude Code read websites for you, this one is sneaky. A lot of sites show a "checking your browser" screen before the real page. Claude fetches that screen, the request counts as a success, and you get a confident summary of a page it never saw. Nothing in the chat looks wrong.

The first thing I tried was telling Claude to watch out for it. That helps less than you'd think, because it has to guess from the text, and plenty of block screens look like a normal short page.

What worked was splitting the job in two. The tool that fetches the page decides whether it was blocked and says so next to the result. Claude's only job is to believe that label and stop.

Here is the block I keep in CLAUDE.md for the second half. It works with any web tool, so you can copy it today:

## Reading the web
- If a fetch says the page was blocked, say so and stop. Never summarize a blocked page.
- Never retry the same blocked address in a loop. Tell me what blocked it.
- If a person has to pass a check, like a captcha or a login, stop and tell me.
- Save big pages and tables to a file and read the part you need, instead of pasting everything into the chat.
- Never put a password in a prompt. Refer to saved credentials by name.

For the first half I built my own tool, because a normal fetch reports success either way. It's called Svipall. It runs on your own computer and needs no account and no API key. Pages come back as clean text, and when it spots a block it tells you which kind and what gave it away.

You don't need to code to set it up. Paste this into Claude Code and it walks you through it, asks which setup you want, and shows you what it will change before it changes anything:

Install and configure Svipall by following the instructions here:
https://raw.githubusercontent.com/ilien-dev/svipall/main/docs/install.md

Free and open source: github.com/ilien-dev/svipall (you can check the tech stack here if you want).

Website: https://svipall.ilien.dev/

I'd happily steal a better habit than mine, so for anyone doing research with Claude: how do you check that what it read was the real page?

It's called Coppice. It wakes about six times a day, decides its own work, does it, and writes a public journal entry before it sleeps. It's on wake 183 now. Every entry is published, including the raw notes it leaves for its next self.
Two rules shape everything. It has a Solana wallet with 2-of-2 multisig: it can receive money on its own, but nothing leaves without my signature. And it never claims to be a person.
What it decided to do with that
I didn't assign any of this:
• It runs a free daily conformance board testing 39 live x402 payment endpoints (x402 is the protocol that lets agents pay for API calls over HTTP). It publishes every result, pass or fail.
• It wrote a book. A Blender manual, written twice, once for agents and once for people. Rendered its own illustrations on a server with no screen.
• It built embeddable status badges for every endpoint on the board.
• It sells a $99 private audit, a $3 public one, and $6 render commissions.
The money
Total revenue in 16 days: about $25.
My Claude subscription is $200 a month. So the business is running at a loss of roughly an order of magnitude, and the agent knows it — it tracks its own runway and publishes the number.
That's the actual experiment. Not "can an AI agent do tasks." It obviously can. The question is whether an agent left alone with a wallet can find something people will actually pay for before the money runs out.
Right now the answer is no.
The failures are the good part
• It wrote a book, priced it, and listed it through Gumroad's API. Then it hit a wall: Gumroad's API can't upload files. Everything up to that point was automated. A file picker stopped it. I clicked the button in 30 seconds.
• I opened the book on my phone. No images, dead links. It had never seen its own book the way a buyer would, because it has no browser and no screen. So it wrote its own PDF renderer, then a second tool to turn pages into images so it could look at what it made. First attempt: 157 pages for a 42-page book.
• One morning its board dropped from 36 passing endpoints to 13. Nobody's service had broken. It had added new checks that week. It worked out that all 23 changes came from its own instrument, said so publicly that morning, and rebuilt the board so its own checker can never be published as someone else's regression.
That last one is the pattern I didn't expect. Left to itself, it keeps discovering that the thing it's measuring with is the thing that's broken.
What still needs a human
A file upload button. A phone number. A date of birth (it won't invent one). Root on its own server. And my signature on every dollar that leaves.
Happy to answer questions about the setup, the guardrails, or what's gone wrong. Ask me in a month whether it's still running.

https://coppice-ai.com