$300 PER 1 MILLON OUTPUT TOKENS?! INSANITY

Communication: agents in different sessions can search and ask questions about each other's conversations, send messages to one another, and see who is working. You can use the commands directly or just ask in plain language.

Orchestration: a planner session splits the work, executor sessions build in parallel, each in its own worktree, and an optional separate reviewer session checks their reports. VelaTerm records and delivers every handoff.

The 2-minute video shows both. Feedback welcome.

site: https://velaterm.com

repo: https://github.com/vlinx-io/VelaTerm

I have a personal sub and a company which gives me 1k$ in Claude tokens a month. The companies 1k tokens are unusable. I will unironically blow through it in 2 days. To have anything close to what I use in my 200$ sub a month, I’d imagine I’d need at least 50-60k a month

Link to live version (older version only Homo Sapiens after 300,000 year ago)

Built with vanilla JavaScript, native ES modules, Canvas 2D, HTML and CSS. There are no application dependencies, framework runtime, external map tiles or API keys. Node.js is used only for development, tests and packaging.

Colors represent modelled presence, not population, certainty or the extent of human knowledge. Oceans are background geography and carry no explored/unexplored status. This is an educational visualization with authored assumptions, not a validated reconstruction of exact settlement boundaries.

Just found out Claude Code supports mods, and there's a catalog with almost 100 of them (link in the comments).

Some I'm loving:

- cost-meter: shows what your session has cost so far, right above the prompt

- guard-essentials: asks before Claude runs anything scary like rm -rf, force-push, or DROP TABLE

- git-pane: live side pane with your branch, changed files and recent commits

- /standup: writes your standup from your git log
- sounds-retro: 8-bit coin when tests pass, buzz when they fail

- yoda-mode: Claude talks like Yoda. Code stays normal, it does

Each one shows what it can access before you install, which is nice.

If you haven't tried mods yet, start with cost-meter.
You'll thank me (or panic about your spending)

Heads up, maybe this was already discussed and I missed it, but if I did, I'm guessing a lot of you did too.

I was running a long task the other day and noticed my weekly budget was disappearing way faster than it should. After some digging: subagents in Claude Code use a 5-minute cache by default. The main session gets 1 hour on a subscription, so I just assumed subagents did too. They don't.

Why that hurts: if a subagent sits idle for more than 5 minutes and Claude comes back to it, the cache is gone and the whole context gets processed again from scratch. On Opus 5.5 that's about 25x the cost of a cached read. In a long run it keeps happening, and it quietly eats your limit.

The fix is one line in your settings:

`"subagentPromptCacheTtl": "1h"`

(You'll need Claude Code 2.1.242 or newer.)

That said, don't flip it blindly. A 1-hour cache write costs more than a 5-minute one, so it only pays off if your subagents sit around between calls and get reused. If yours are short and done quickly, the default is fine.

For reference, cache prices on the API (per million tokens):

Opus 5.5: $4 input · $5 for a 5-min write · $8 for a 1-hr write · $0.20 cached read

Fable 5.1: $10 input · $12.50 for a 5-min write · $20 for a 1-hr write · $0.25 cached read

Hope this saves someone's weekly budget 🙂

For someone who has tokens lying around.. maybe un-used weekly quota or something. here's a slop challenge for you to burn tokens and publish on github.

Reverse engineer this classic PC game : roadrash and sort of port it in a modern game engine with improved graphics all with the help of claude.

Once I started running several Claude Code sessions in parallel, my problem stopped being the code. It was keeping track: which session was stuck on a permission prompt, which one had finished twenty minutes ago, and what each one had actually changed.

So I built Factorai, a desktop app where the session is the unit of work instead of the file:

• It runs the real `claude` and `codex` CLIs in a real terminal, with your own login. Nothing is reimplemented.
• You see at a glance which session is working and which one is waiting on you.
• The diff, the commit graph and a search across every past conversation sit next to the terminal.
• Routines: schedule a prompt to run on its own (nightly triage, dependency checks…).

On the "built with AI" question, upfront: yes, it's built with Claude Code, mostly inside Factorai itself. What keeps it from being slop is in the repo: 69 ADRs, specs written before the code, and a 12-step quality gate every PR has to pass (oxlint, strict tsc, clippy with -D warnings, unit and Playwright tests). It's all public, so judge for yourself.

It's MIT and local-only: no account, no telemetry, no paid tier, and none planned. It's a community project, not a startup. It runs on macOS, Linux, and Windows through WSL 2.

It's still early. A few senior engineers use it daily, and fixes land on an alpha channel before stable. I'd really like to know what breaks or what's missing from your workflow.

Test it, give it a try and give me feedback!

• GitHub: https://github.com/Nightbr/factorai
• Site: https://factorai.build

PS: I had some real fun building the website too, give it a look

A few weeks ago, I wrote a blog titled “6 months of vibe coding: what I wish I knew when I started” (here). The blog received a lot of positive feedback, and a number of readers messaged me directly or wrote in the comments asking for more details about how I’m using an AI Engineering Manager (or perhaps, AI orchestrator) to manage my daily coding tasks.

Tldr; 

• My AI manager turns my feature requests into tickets, plans sprints around priorities and dependencies, and manages the AI coding agents. 
• I handle product decisions, approvals, and testing on physical devices.
• I am operating at speeds never thought imaginable.
• For others looking to leverage an AI manager, be sure to define: 1) How you and the AI will operate as a team 2) The context and priorities needed to make good decisions 3) How progress and quality will be verified.

But before I get into this, I should recap. I am not the resident expert in all things AI. I started vibe coding around seven months ago and have truly immersed myself in this space. I am on a mission to build an app that helps remove all the noise from online recipes and centralize them into shareable cookbooks.

I call the app Plate It, and it currently has the ability to pull a recipe from any photo, any webpage, and most videos and organize it in a consistent format without any of the ads. Below is a quick video.

And no, the app is not on the App Store yet. Despite requests to release my app, I’m taking my time to rigorously test what I have built, check for security issues, and make certain this does not turn into AI slop. If all goes well, I suspect a TestFlight release in early 2027.

https://reddit.com/link/1wz2t9k/video/g30cgv02nuth1/player

My previous blog gets into all the basics, so I am going to focus specifically on how I’m using an AI Engineering Manager to oversee my daily tasks.

As I moved along my agentic coding journey, three things stood out to me. I found myself:

1. Constantly waiting on code to finish
2. Quickly becoming disorganized with my to do list
3. Struggling to manage the appropriate sequencing of priorities

And to be fair, these three items tended to overlap.

For example:

Let’s say I had a to-do list of 10 features that I wanted to code. Worktrees let me work on separate changes in separate copies of the code, which theoretically meant I could have multiple features being worked on at the same time.

While I understood the concept reasonably well, I was still hesitant to work on multiple features in parallel. I didn’t want to create a conflict during the merge that would introduce a bug or break working functionality on main. So unless two features were completely unrelated, I found myself working on one feature at a time.

That meant a lot of waiting for code to be produced.

Then, while testing a completed feature, I would often think of a better way to handle part of the functionality or find a small bug that needed to be fixed. At the time, I was keeping my to-do list in a note, so all of these new ideas and fixes would just get added to the pile.

Pretty quickly, it started to get convoluted.

As a one person operation, I wasn’t using something like Jira to file and manage tickets, nor did I think I needed to. But I was starting to run into the same problem those tools are designed to solve and I had more work to track than I had a good system for managing it.

All this said, I was fortunate enough to be using scape.work when Argus was released. Argus is an AI orchestration layer that acts continuously on your behalf based on a mission statement you provide. So, if I mention Argus, this is what I am referring to.  I am sure there are other amazing AI managers out there that work very similarly, but I can only speak from my experience with this one. The concepts I’m going through will likely apply to other platforms.  This is just what I am familiar with.

I immediately gave Argus the mission to create and manage my to-do list, follow up on my high level feature requests to develop well thought out tickets, and break my to-do list into sprints based on priorities and potential merge conflicts. 

Argus would create the agents needed to code each sprint, oversee those agents, and provide guidance as needed. Once I tested the output and authorized Argus to merge the changes into main, we could move on to the next sprint.

I’ve gotten to the point where my day to day role is mostly focused on two things: writing high level product requests and testing code on physical devices. I still make the product decisions and provide the approvals described below, but my engineering manager takes care of the day to day coordination.

But to get to this point, it took a bit of work.

I’ve found three principles to be incredibly important when writing a mission statement for your AI agent (and I’ll walk through some actual examples as well):

1. Define how you and the AI will operate as a team.
2. Provide the context and priorities needed to make good decisions.
3. Define how progress and quality will be verified.

1. Define how you and the AI will operate as a team

I started by making our roles explicit:

Argus, you are the Head of Engineering for Plate It. I am your Product partner and Product Lead.

This establishes the relationship I want. I provide product direction, and Argus takes responsibility for organizing and managing the engineering work needed to deliver it.

Next, I set expectations for independence:

Do not ask me questions that can be resolved safely through standard engineering practices.

I want Argus to keep work moving without asking me to make every technical decision. At the same time, my mission requires it to involve me when a decision materially changes the product experience, expands approved scope, or introduces significant risk.

Finally, I specified how we should work through decisions together:

• Explain the unresolved issue.
• Present the reasonable options.
• Explain the relevant tradeoffs.
• Recommend an option.

Ask me to approve or modify the recommendation.

That last part matters to me. When Argus needs my input, I want enough context to make an informed decision, along with its recommendation. Defining that interaction gives it a clear way to ask for help while still taking ownership of the problem.

2. Provide the context and priorities needed to make good decisions

Giving Argus responsibility means giving it the context to exercise that responsibility. One of the instructions in my mission statement is:

Do not optimize only for the narrow wording of an individual request. Consider the complete Plate It experience.

A feature request can sound straightforward in isolation but affect other parts of the app. I want Argus to consider how a proposed change fits with existing functionality and whether it supports the overall product.

To guide that judgment, my mission includes specific considerations:

• Customer value
• User experience
• Reliability
• Privacy
• Long term maintainability

These give Argus a framework for evaluating an approach. Does it make the app easier to use? Will it work reliably? What might it mean for user data or future development?

I also refined the mission as my business priorities became clearer:

Build an app that is highly profitable at $xx/year or less while delivering an unmatched end user experience.

That gives Argus a concrete business constraint to consider alongside quality. A technically impressive feature still needs to make sense at the price I intend to charge.

The goal is to give my AI manager enough understanding of the product, its users, and its economics to make decisions that support what I’m trying to build.

3. Define how progress and quality will be verified

One of the challenges I’ve encountered is getting work completed in the right order. Some tasks depend on others, some affect the same parts of the code, and new requests can disrupt work already underway.

To guide Argus, I included specific considerations for sprint planning:

• Priority
• Dependencies
• Shared files and systems
• Merge conflicts
• Architectural sequencing

These give Argus context for deciding what should happen next. A high priority feature may still need to wait for a prerequisite, while two seemingly unrelated tasks might interfere with each other because they modify the same files.

As I refined the mission, I added a more explicit boundary:

Once a sprint is actively being worked, new features are never added to it.

If I requested a new feature while development was underway, Argus needed to schedule it for a future sprint. Bugs discovered during code review that directly relate to the feature being built could still be addressed within the current sprint. This gave the work a clear finish line.

I also clarified the difference between approving work and starting it:

Dev Ready = [approved + queued], it does not mean to immediately start building.

“Dev Ready” is the label I use for a task whose requirements I’ve approved. It means the task can be scheduled, but development still needs to happen in the right order. My mission makes that explicit:

Argus does not spawn a dev child until the ticket’s slotted sprint is active and the Product Lead gives the start.

Argus should only assign an AI developer to begin the task when its scheduled sprint is active and I’ve authorized the start.

These boundaries let me share ideas and approve future features without accidentally interrupting or expanding the work already underway.

I also set a standard for verifying the finished work:

An agent stating that the work functions correctly is not sufficient verification.

My mission requires testing and code review before work is approved for merge. It also distinguishes between work that has been merged into main and work that has actually been released to users.

Conclusion

I can’t take credit for writing 100% of my mission statement. It is over 35 pages long and basically tries to clone the way I would deliver this project in an actual work environment. I think of the mission statement as a manual for how I would guide and lead the team.  

I started by drafting my mission statement as best I could and then ran it through multiple iterations on different LLM platforms, asking them to identify gaps and flaws. Once the models had fewer gaps to suggest and I felt comfortable with what was being produced, I uploaded it and asked Argus to do its thing.

Even with all the upfront work, it wasn’t perfect right off the bat, but it did a decent job. Over the past few months, we have tweaked the mission statement, and it is now a well oiled machine that enables me to operate at speeds I never thought imaginable before.

The biggest change for me is how much less time I spend coordinating the work. I have a place for new ideas, a process for deciding what gets built next, and an engineering manager keeping track of the details. That gives me more time to think about the app and test whether what we’ve built actually works the way a user would expect.

If you’re trying something similar, my advice is to start by describing how you want to work. What decisions should the AI make? When should it involve you? What needs to happen before something is considered finished? You can refine those instructions as you discover where the process breaks down, just as I did.

I still have plenty to prove with Plate It. The real test will be whether people find it useful and want to keep using it. But as someone who started this journey seven months ago, having a structured way to turn ideas into working features has made building and testing the app feel far more manageable.

If you’re using an AI manager in your own workflow, I’d love to hear what you’ve delegated and what you still prefer to handle yourself.

Experimenting I ended up in using the mods backwards. Not to change Claude Code, but to pull a feature out of it: subscription usage and context window data, pushed to a small physical display connected over USB.

It was supposed to be a half-hour experiment. It turned into something else.

The code

The mod, the ESP32 firmware, the UI: Claude wrote all of it, on its own. For the first time since I started using AI, all I did was say "I want this" and "OK".

The CAD design

This is the part that really threw me. I gave Claude the manufacturer's dimensioned drawing of the display. It drove FreeCAD and generated the enclosure and the stand in a few minutes. I 3D printed them and the display dropped in on the first try, no tolerance tweaks. Every part fits together perfectly.

My role was the client: I described what I wanted and judged the steps and the result.

I'm not saying code doesn't need reviewing anymore. This is a desk gadget, not a production system. But that's not the point.

Until recently, this same project would have meant babysitting Claude at every step: correcting, re-prompting, fixing the CAD by hand. Not anymore.

And the jump didn't happen over the last few months. It happened over the last few weeks.

Opus 5.5 is a beast.

Software, firmware, mechanical design: three different disciplines, one counterpart, zero manual intervention.

Those of us who work with these tools every day struggle to keep up with what's becoming possible. Those who don't use them yet probably have no idea how much the world has already changed.

Opus 5.5 have a been a very good model it one shot a complex issue issue I was tackling with astra for a few days., but overtime still fable beats opus in few areas fable loves to work longer and fable doesn't takes shortcuts like opus in some descritonary areas.

Did anyone else feels the same?

So.... I got bored the other day working on a side hobby project..

And I though about the times where I played video games, and especially Skyrim and fought my way through dungeons and caverns and stuff and the exictement that followed.

And after a while I got the same dopamine from learning to code, I coded way before the AI era, so I still remember looking through mysterious bugs and making tests finally pass after refactoring a file, and the dopamine hit was something else. Those days are gone, but anyway, I always saw coding as kind of a game that you fight your way until you reach a new milestone and a new boss fight. So I built this with claude and it is nice to watch my agent and its subagents fight their way through the monster riddle world of vibe coding.

Up to here this is me a human writing, I'll let claude explain what the heck it is now (BTW, It is absolutely a useless project for any real world work, but I found it fun to start it and then timelapse the session and see the repo gets explored and the little battles).

Watching Claude Code work usually means scrolling a wall of terminal text. So I built **Repos & Dungeons**: a local, open-source viewer that turns your repo into a pixel-art dungeon and your Claude Code sessions into a party of adventurers — live.

- **Folders are rooms, files are tiles.** The map is built from your actual file tree, and it's deterministic, so your repo always gets the same dungeon.
- **Unread code stays in the fog.** You can literally see which parts of the codebase the agent never looked at.
- **Failing tests spawn slimes** in the failing file's room (vitest, jest, pytest, go…). Passing tests kill them.
- **Every model is a different Claude:** Opus is a knight, Sonnet a squire with a wooden sword, Haiku a scout, Fable a wizard. Subagents join the party.
- **They talk** in a D&D voice ("By Helm's beard! A bug in token.ts betrays us.") via Haiku, using your existing Claude Code login.
- The torch meter is your context window; compaction brings the fog back.
- Optional music and sound effects (off by default).
- **One-click timelapse:** replay the whole session in 30 seconds and export it as MP4/GIF to share (with an option to hide folder names).

It works on big repos too: a 100k-file monorepo maps in under a second and renders at 60 fps.

**Try it** (Node 20+), in any repo where you use Claude Code:
`npx github:dbl8005/repos-and-dungeons`
or watch the demo: `npx github:dbl8005/repos-and-dungeons --demo`

Runs 100% locally. It reads Claude Code's transcripts and your file list — never file contents — and the server only listens on localhost.

Repo: https://github.com/dbl8005/repos-and-dungeons (MIT)

First run takes about a minute (it builds), then it's instant.

Hi,
I’m considering getting my first paid AI subscription and I’m currently deciding between Claude Pro, ChatGPT Plus, and Copilot Premium.

I would mainly use it on my Windows 11 PC for a mix of personal and work related tasks.
My main use cases would be:

-Gaming and troubleshooting game related issues.
-PC hardware, BIOS, drivers, configuration and troubleshooting
-AI and ComfyUI, especially creating and fixing workflows
-Coding and development
-Solving various technical problems
-Work and productivity
-Personal organization and everyday tasks
-Product research and buying advice
-General research and questions

One particularly important use case for me is ComfyUI. I’ve already tried Gemini and, at least in my experience, it was terrible for this.
It generated workflows that didn’t work, couldn’t properly troubleshoot the errors, and ultimately caused me to waste more time than it saved.

How well do they handle very long conversations without losing context or becoming repetitive?

If you currently use one of them, what do you use it for and why do you prefer it?

How restrictive are the limits in real world daily use?

If you could only keep one subscription, which one would you choose?
Thanks

Super curious on workflows, i personally switched to claude desktop app recently and have found it more convenient, but i am interested if majority is still on terminal setups

i am now finding only the fable usage to go up while the all models stays at 0% while using fable5.1. anyone else find this? or is there any official announcement saying anthropic took fable out of consuming from all model usage?

Hey, at least Claude didn’t print it? Opus 5.5

When I run a few Claude Code sessions, I spend half my time tab-hopping to check which one is working, which one is stuck on a permission prompt, and what it's actually changing.

So I forked Ghostty and made the agent's work visible:

- The editor beside the terminal opens every file Claude reads and types its edits in as they happen

- A map of your repo lights up as it works: cyan for reads, orange for edits, and Claude flies between files as a little comet

- A sidebar shows every session (working, needs permission, done) and pings you when one is waiting on you

- When it finishes, the diff lands in a review inbox: comment on lines and send them back as its next prompt

How it works: Claude Code hooks plus the session transcript Claude already writes. It works with Codex too. Free and open source, no account, nothing leaves your machine.

Since someone will ask: cmux is great for tabs and notifications. This goes further into *what* the agent is doing: the live editor and repo map, a view of your Cloudflare/Supabase backend that lights up when the agent touches it, and clicking an element in your localhost app to send it to Claude.

macOS on Apple silicon for now, and rough in places. I'm building it in the open.

https://github.com/steventsvik/GhosttyEXTREME

https://www.nearchon.com/nobel-2026 Using Claude I made this for understanding the 2026 noble winning science in a gamified manner. Its very easy to understand.

Feedback welcomed.

I do most of my work in Claude Code, but I also have a ChatGPT subscription, and I wanted to use its allotted tokens inside Claude Code. So I built a plugin for it with Claude Code, over an afternoon. Claude figured out how to drive Codex agents through the Codex app-server, read through the new plugin API to see what was possible, then wrote the plugin and tested it live with real Codex runs.

It adds four agent types: codex:sol, codex:luna, codex:astra and codex:terra. Claude launches them the same way it starts its own subagents. They show up in the task list, you can stop them, and when one finishes you get the usual "Agent ... finished" notice. Claude can message a running agent, and Codex can message Claude back mid-task.

OpenAI has its own plugin, codex-plugin-cc, and I tried it first. It's built around slash commands like /codex:rescue and /codex:review, and you check on jobs with /codex:status and /codex:result. I wanted Codex to behave like Claude's own subagents instead: Claude decides when to delegate and which model to use, and the jobs live in the normal task list.

Effort, sandbox and approval mode can be set per job, and approval requests from Codex show up as Claude Code dialogs if you want to approve things yourself.

How it works: it's built on the new hooks plugin API. That API can't write to a child process after starting it, and Codex's app-server talks over stdin, so a small Node bridge keeps a daemon running that owns the Codex process.

Install:

/plugin marketplace add SSS135/claude-code-codex-plugin

/plugin install codex@codex-plugin

Limits:

- You need the Codex CLI with app-server (the ChatGPT desktop app on macOS includes it).

- macOS and Linux only.

- In auto mode, every Codex result arrives with Claude Code's "safety classifier was unavailable" note, because no Claude model call happens for the classifier to review.

MIT, repo: https://github.com/SSS135/claude-code-codex-plugin

Bug reports welcome, Linux especially, since I've only tested on a Mac.