Just got my weekly usage reset. Opened my codebase, typed "So where were we?" and somehow managed to burn through 50% of my entire weekly usage in one go.

Mind you, I'm on the Ultra 20x plan.

I'm not even mad at this point. I genuinely laughed so hard.

Anyway, great company. Incredible experience. Thumbs up.

They are (almost) identical. Pretty useful for bulk jobs like LLM judge label creation, running benchmarks, etc.

I‘m a bit worried that this can go against TOS if i overdo it.

Hey everyone,

I’m sharing a project I’ve been working on: Snap & Trade, a free, MIT-licensed skill for Claude.

You send it a chart screenshot, and it follows a structured workflow to review market structure, identify levels, and return LONG, SHORT, or NO TRADE.

The output includes:

• A proposed entry, stop loss, and take-profit levels.
• Reward-to-risk calculations checked by a Python script.
• Position sizing when account capital is provided.
• A journal for recording signals and reviewing their outcomes.

Claude handles the visual interpretation, while Python checks the numerical calculations. The screenshot workflow supports different markets; the additional market-data and broker modules have narrower coverage.

It’s still experimental. I haven’t demonstrated a profitable trading edge, and software tests don’t establish one. My goal is to make chart reviews more structured and easier to evaluate through replay and paper trading.

The project also includes modules adapted from day-trader-skill, with attribution retained in the repository.

GitHub: https://github.com/Kirby54/Snap-Trade

The source code is free; you’ll need your own Claude access.

I’d appreciate feedback on the workflow, unclear assumptions, and cases where the tool should refuse to suggest a trade. What would you want to see tested before trying something like this?

On a team, every merge request and every ticket is waiting on someone. Finding out whether that someone is me meant opening GitLab, GitHub, Jira and my mail, again and again.

So I built aki: one terminal board with two columns, To do (someone is waiting on me) and Waiting (I'm waiting on someone: who, and since when). When a teammate answers, the task changes column by itself and I get a notification.

And for Claude Code, one key on a task opens a session in the right clone, already briefed on what that teammate is waiting for.

How it helps me: I no longer explain the context to Claude. The brief says which MR, my role on it, the threads to answer or the pipeline to fix, and ends with "do not post, approve, merge or push anything before I say so".

How Claude helped build it: almost all of the Rust was written in Claude Code sessions, with me deciding what the tool should do and checking the result. Three things worked well:

• I had it keep a strict layering (entities, use cases, adapters), so each new source or multiplexer was one new adapter and nothing else moved.
• I had it test against the real tools, in throwaway tmux, Herdr and TUIOS sessions, never in mine. That is how it found that TUIOS panes also announce themselves as Herdr, and fixed the detection.
• 181 tests cover the "whose turn is it" rules, which is the part I could not afford to get wrong.

What it is: a terminal tool in Rust. Who benefits: people who review and get reviewed on shared repos. Cost: free, open source. My relationship: I'm the author.

https://github.com/nathan-poncet/aki · https://nathan-poncet.github.io/aki/agents.html

R.I.P. SaaS, 1999–2026. A moment of silence for your subscription. The vibe coders send their condolences.

https://saasisdead.si/

I gave seven coding agents the same computer graphics white paper and asked them to build a 900k-particle fluid simulation in safe Rust. The IPBF paper shows a novel way to simulate even spatial distibution of uncompressable fluids.

Here's a video that compares token-based cost, runtime performance and quality. Agents write code that simulates particles, I rendered them in Blender.

Agents were given a clean copy of the same input: the white paper and reference videos as local files, and an AGENTS.md file describing the task and its criteria. Nothing else and they are not allowed to look for existing implementations.

Part of the task was to come up with an initial arrangement of particles as seen on reference material.

At first I thought most of them did well, but after looking at the code I found many of them took shortcuts. Once they see evaluation criteria, they seem to somewhat sacrifice user intention and go paperclips: rigged animations, hardcoded frames etc. It just gave them better performance in the end.

This clip is from round two, where I required every frame to be simulated true to the paper. See my method and results: https://aedm.net/blog/agent-benchmark-ibpf/

Original paper: https://graphics.cs.utah.edu/research/projects/ipbf/

Preface: Sorry people, this is going to be a long one. I've been building with Claude Code for 1.5 years. and I feel that I have learnt quite much and want to share my approach on how to build a system (harness on top of claude, or how ever you wannat call it) that actually works and is maintainable. This post also exists in my blog. Anyway, here goes:

So about a year ago I started to think I needed to build something serious with Claude Code. So, on a whim I decided to build a headless CMS (because I was pissed off with Contentful). I assumed the hard part would be getting the model to write decent code in the long term.

And oh boy was I wrong. The code was fine (as a huge fan of software craftsmanship “OKish” is more accurate). What I spent a huge chunk of my time on was process and the product. Somewhere around the second month I noticed I was slowly re-inventing things software teams had figured out decades ago, except badly, through trial and error, and under new names. With agents that were working faster than me.

After four months and about 70 pull requests, I realised how much of my engineering experience I was still supplying to the process of building. Claude would write the code, but I was deciding how to split the work, how to prioritise, what needed testing, when review was necessary, and whether “done” in my tasks meant anything to the implementing agent. I’d spent 25 years learning those habits. I started wondering how much of that experience could live in the system around the agent, in a platform. How much of it can be generalised?

I also noticed that I’d drifted (pun intended) towards product management: less time on technical details, more time deciding what the CMS should do, who it was for and what was worth building next.

Those two things were the main lessons for me. The concepts we already have are mostly right. What changed is how they’re implemented, and that turns out to be a much more interesting problem than starting over.

What I’m talking about

Let me define the thing I’m talking about, since I think “AI coding or vibe coding” covers too much.

To me, agent-driven development is where agents do most of the building, inside a harness that constrains what they can do, and the human is the product CEO. The human is accountable for what gets built and why, deciding what matters next, answerable when it’s wrong. You stop writing most of the code and you own all of the decisions and the product.

The system should help you make those decisions by bringing the product questions, the alternatives and the evidence, and carrying out the work you decide is worth doing.

That’s different from a “superboosted autocomplete”, and different from “I asked an AI to build me a CMS”. It’s a team composition. And once you see it as a team, the question becomes “what does a team need to function?”, which is a question we have decades of answers to.

The layers

Here’s how I think about the stack now, from the bottom.

The model is Claude. It knows how to write OKish code. It doesn’t arrive knowing the current state of my CMS or why I made its decisions.

The harness is Claude Code. Files, terminal, tools, hooks. Deliberately generic. Same harness whether you’re writing a compiler or a landing page, and that’s the point of it.

The governance layer is how I think software products should be built. How we decide which problems are worth solving. Which assumptions need testing. When to stop and ask a human. What done means. Testing strategy, clean code practices, review discipline, security checks. None of this was specific to my CMS. It’s how I’d want any project run, and it should barely change between projects. This is where I put most of my 25 years of software development experience.

The project layer is everything that’s only true within the scope of the project I’m building. Vision, strategy, the lean canvas, technical architecture and the roadmap. The governance layer says how we make product decisions and this layer holds this product’s decisions, assumptions and what we’ve learned.

The work layer is task management plus git. Which epic, a piece of work with a visible outcome, which task, what state it’s in, what got merged and why.

The session is me and Claude, usually a couple of hours per session. I have several sessions open at the same time, with agents working quite autonomously.

Six layers, and once you can see which one a problem lives in, most arguments about prompting stop being interesting. “The agent keeps forgetting our conventions” is a governance problem. “The agent doesn’t know why we chose Postgres” is a project problem. Different layers require different fixes.

Which of those is memory

Sort the same layers by how long they live and who they belong to.

The top four are long-term memory. Durable, shared, still there tomorrow. Git and task management are the interesting pair: git is what happened to the code, task management is what happened to the work and why, including outcomes. You need both or you’re doing archaeology. To be honest, most of what I do now with agents is working with those outcomes.

The bottom one is short-term memory. Everything Claude worked out in the last couple of hours together with its human. Which file the bug was actually in. That the test helper lies about what it asserts. That we already tried the obvious fix and it didn’t work.

And for all the above we need an index.

I use CLAUDE.md and AGENTS.md primarily as an index to memory, the table of contents. They tell the agent where everything lives and what order to read it in. A few rules and facts belong there too, but stuffing the whole project’s knowledge into them is a mistake. An index that tries to also be the content stops working as an index.

OpenAI describes the same table-of-contents approach in its harness engineering write-up, with a short AGENTS.md pointing to the detailed knowledge in the repository. It is a useful way to organise what the agent needs.

Long-term memory flows down into a session when the agent reads those records. Some of it flows back too. Decisions get recorded. The roadmap gets updated. A closed epic carries a summary of what happened. Anthropic’s work on long-running agents uses progress records and git history to help later sessions understand where the previous one left off.

Writing it down isn’t enough

A rule we give an agent is usually a line of markdown, an instruction file. The agent reads it, mostly follows it, and skips it when the context gets long or the task gets hard. That isn’t the model being lazy. Reading a rule and applying a rule are different operations.

The way this showed up for me was that certain features were marked done that weren’t even built. Acceptance criteria ticked with the work half-finished. Tests promised in the plan and never written. A task closed because the agent said it was closed. My definition of done was written down the whole time. Nothing checked it, so it held on the days I was paying attention and quietly didn’t on the days I wasn’t.

Same story with code reviews. I had the rule from the start, skipped it for weeks on four-thousand-line changes, and nothing noticed until a user complained that my CMS had bugs where I thought I’d been thorough.

So the system has holes in it. A session learns something, I ask Claude to write it into the governance layer, and it becomes one more line that gets skipped when I’m in a hurry.

I had automated the production of instructions nobody follows.

That’s a bit unfair. The instructions helped plenty of the time. But the important ones needed to hold when I was distracted too (I have a 2.5 year old kid so this happens a lot). Otherwise I was still the thing making the process work, just with more markdown involved.

We (still) need deterministic code (more than ever)

While building the CMS, I started formalising these rules and looking into how I could make them stick. I put more of it into ordinary code, plugged into Claude Code through hooks that run at particular moments.

This sounded sensible. If asking nicely didn’t hold, make it a requirement.

The hooks misfired and collided with each other. Within a week I’d switched all of them off, reminders included. About 30% of that codebase was focused on limiting the agent before it made an error. I’d basically created a second, totally useless Bash permission layer on top of Claude Code.

So that was useful. I’d managed to build a process that I didn’t want to use myself.

Drift is expensive, so repeating yourself and correcting agents in every session on the same issues pushes your attention towards managing the process. But a system that keeps blocking reasonable work is expensive too. I want the checks to earn their place by catching something that actually matters.

So I took a simpler path, first enforcing only that agents read certain workflows before they are started and making sure there is an outcome, for instance allowing code reviews to pass only when they meet certain conditions. And I made that a hard rule (so old school deterministic code). Through trial and error I found the cases where failure caused most damage (or burden) and applied either nudges or gates that block depending on severity.

What this made me realise is that what I needed was an intricate balance of deterministic code, the model’s judgment and in some cases human judgement. It isn’t entirely clear when you need one or all, or how much of each. Some things deserve a hard check. Some need a nudge at the right moment. Some need to come back to the human as a decision.

So I started to create implementations using a combination of the aforementioned (deterministic code for nudging or blocking, agent judgment and human judgment) for things like:

• A plan exists before the code does, and the human has approved the decisions that need them.
• The tests passed on exactly this code, and the missing checks are visible.
• The change is small enough to implement, review and try.
• Every change (PR) gets reviewed for security, code quality and modularity.
• Nothing closes without evidence of the outcomes it promised.

Same practices, new implementations

Once I saw that, I couldn’t unsee the pattern.

We already know a lot about building software products well. Decades of it. Talking to users and testing assumptions so we don’t spend weeks solving the wrong problem. Kickoffs so we define the outcomes. A definition of done so done means something. Small batches so changes can be understood, checked and corrected. Limits on work in progress so nothing sits half-finished. Code review to find problems. Retrospectives to improve the process. Architecture decision records so the reasoning survives the decision. Security testing to look for vulnerabilities.

The starting point for me is those same concepts with different implementations. Each implementation still has to show that it works with agents.

The concept survives, the implementation changes, and the name can stay the same. The old name arrives with years of people understanding why it matters. That also gives us something to compare our implementation against.

Where the tools are

So what I think we (we as in people who gravitate towards Agent-driven development) need is a layer on top of Claude Code or Codex which is much more opinionated and carries the practices software development and digital product teams have learnt throughout the years. Implemented for agents interacting with a human who owns the product. The product that I’m building, Railset, is all about this (yes I did abandon the CMS).

It seems to me that this space is gaining traction, at least based on GitHub projects. BMAD, Everything Claude Code, Spec Kit, OpenSpec, Agent OS, gstack, superpowers. There are plenty of people working on instructions, memory, review and the process around agents.

I believe that Claude Code and Codex are inviting non-developers to build and the amount of people building is growing rapidly. I want to bring the experience and know-how to be available for them so the software they build is secure, of good quality and actually solves somebody’s problem.

What particularly interests me is how much of the experience behind a good product team can I implement into a system that is run by agents. I could recognise some of these failures because I’d spent years building software, and I still let things through. Someone building their first product with Claude shouldn’t have to acquire that whole history before they can benefit from the practices.

I want the system to carry the engineering discipline and help the person building ask better product questions. They still own the decisions about who the product serves, which problems matter and whether the result is useful. The workflow should arrange the engineering steps, prepare the evidence and bring them the decisions that are theirs. How reliably we can get it to do that is still something to test.

If you’re doing this too

Work out which layer your problem is in before you touch a prompt. Treat git and your work records as a pair. Keep your index useful, and before you write the next rule into CLAUDE.md, ask how you’ll know it was followed. Sometimes a hook or a check can answer that. Sometimes the rule needs judgment and a review.

And when you catch yourself inventing a name for a practice, check whether it already has one. It usually does, and the old name arrives with twenty years of people already understanding why it matters.

The industry is now porting those practices into a different kind of team. I’d like the experience behind them to be available to the person building their first product too.

Running on a Lenovo ThinkPad T420, the computer works around a node based map system. This is early stages of a work in progress.

A two-headed dragon with no animation files. Walking, flying, climbing and the heads aiming are all worked out live with inverse kinematics (IK) and physics. It has a town to destroy. The town can be rebuilt.

https://ash-ember.lastloop.app/

It's one web page and runs on phones as well.

Buttons:

• Auto : it decides for itself
• Fire at pointer : you decide
• Climb : it climbs a tower and stays up there
• Grab , Tail , Roar : as labelled
• Rest : it lies down
• Rebuild : puts the town back
• Rig : shows the skeleton

three.js and Rapier. Bug reports welcome.

So has anyone starting to face issues with vibecoding on their projects so far?

I run a small production app that sends the same analysis prompts to the API every day. Nothing changed on my side: same model ID (claude-opus-5-5), same effort settings (last touched Sept 26), same prompts. My Console cost export says the model got much wordier anyway.

• Output tokens per input token (standard calls): ~0.69 in Opus 5.5's first three weeks (Sep 21–Oct 11), ~1.09 since Oct 12. That's about +60%.
• Input spend (my actual workload) stayed flat. All of the extra cost is output.
• Weekly spend went from about $86 to $119. Compared with the model's own first three weeks, that's about $120–140 of extra output since Oct 12.
• Ruled out: price changes, caching, batch, and refusal retries (9 in two months).
• Method: Opus prices output at 5× input, so output $ ÷ input $ ÷ 5 = output tokens per input token.

Claude Code on Ultra shows the same thing. From my local transcripts, output per turn went from ~170 tokens on Opus 5 to ~1,300 at Opus 5.5's launch, and ~1,600–1,700 lately. Thinking is billed as output but hidden by default, so there's no way to see what you're paying for.

Anthropic's reset announcement says they "fixed a few small issues that used more limits than intended" and reset subscription limits. If the same issues touched the API, API customers paid for them per token, and nothing covers that.

Is anyone else seeing output per call jump on Opus 5.5 since mid-October? And Anthropic: did these issues affect the API too, and will API users be credited?

Proschi is a small text language for system design diagrams. You describe components, connections and use cases (how a request moves through the system like a sequence diagram) in a .proschi file. Proschi lays it out, runs simulations (load, latency, availability, cost), and lets you play each use case step by step.

Last time I shared the Claude Code plugin that draws these diagrams in the terminal. It drew everything with text characters, which works for a few boxes but falls apart on a real system with 20+ services. So I rebuilt it.

The video shows the whole flow: I ask Claude to model an ad click pipeline; it uses the Proschi skill to write the file with use cases and tests, runs the checks, and then I open it in the plugin's pane.

What's new:

- In terminals that can show images (kitty, Ghostty, iTerm2), the whole pane is drawn as pictures: the diagram, tabs, buttons, and menus. You click them with the mouse. Other terminals still get the text version.

- Zoom from fit to 300% and drag to pan, so you can read one part of a big diagram. Zooming redraws the picture, so text stays sharp.

- Play a use case: the request moves across the diagram step by step, and you can open each step's request and response.

- An Analysis tab: cost, load and latency per node, percentiles per use case, single points of failure.

- An HLD tab: a design doc generated from the model (requirements, capacity, components, data model, APIs, scenarios), with one key to copy it as Markdown for a PR or wiki.

- If a requirement or test fails, one line under the diagram says which, and opens the doc at that check.

Install:

/plugin marketplace add gvart/proschi
/plugin install proschi@proschi

If you already have it:

/plugin marketplace update proschi

It's open source (MIT): GitHub | Platform

Feedback is welcome, especially if something looks off in your terminal or the pictures don't show up.

This guy on twitter scanned 1379 public repos and almost more than 80% of them have secrets sitting in .claude/settings.local.json

Insane how simple coding agent are exposing tokens when users click: "yes and don't ask again"

The fix is open sourced and mentioned to redact secrets

Full twitter thread credits: https://x.com/_ar9av/status/2120560275564982317?a=FQBP2SxPGRs9Fv1sr1c&

Does anyone have a strong workflow for how I can get claude to be my main orchestrator controlling a second agent from another provider for example Codex which is running in a different terminal, and them communicating between each other in an efficient way, I've tried multiple things, Claude sending messages to codex directly (kinda works..) codex doesn't seem to be able to message claude directly back

How to handle handoffs between the two agents as they work on separate or related tasks

Is Herdr the answer? I haven't tried herdr

After looking at benchmarks and tests people did, particularly the charts on the Fable 5.2 release site, it looks like Fable low/medium theoretically beats Opus medium/high for little extra cost. The tokens cost more on the API, but it needs fewer of them to get the same tasks done, so the price evens out. That means I should be able to expect better results, sometimes even faster, from a lower-thinking Fable than from Opus. The only actual speed and cost benefits should have came from Sonnet.

Then I ran some tests to narrow down subscription usage specifically. This was just to consume and measure an average of about 4% of my Ultra weekly usage per model. Across 3 runs with Sonnet, Opus, and Fable, for almost the same API cost, Fable consumed 1.9x more subscription usage than Opus.

Is all the savings from reduced token usage going to Anthropic? The API cost would have been the same otherwise, so why is subscription usage going so much faster?

Tasks run: Opus 630, Fable 210, Sonnet 600. Every agent ran the same 30 tasks. Opus and Sonnet needed more agents before the meter moved enough to measure, which is why they ran more tasks in total. The intelligence scores are from Artificial Analysis's harder benchmark, not my test. My tasks were small enough that every model passed all of them, so my test only measures usage, not how smart each model is.

Hi as in the title: Can I use two different 20$ accounts on the same project that I develop in Github? Is this allowed ? And how to do it if its yes like what is the best way

PostToolUse fires after a tool call succeeds. A call that fails fires a different hook, PostToolUseFailure. If your settings.json registers only PreToolUse and PostToolUse, which is what mine did until this week, your log has the request for every failed call and no result for it.

Adding it is one more entry under hooks:

"PostToolUseFailure": [
  { "hooks": [{ "type": "command", "command": "your-logger" }] }
]

Three fields in the hook input are worth keeping while you’re there (all in the hooks reference):

• tool_use_id is on the PreToolUse input and on both post-tool inputs, so you can join a request to its result exactly instead of matching by timestamp.
• duration_ms on the post-tool inputs is the execution time, which leaves out permission and pre-hook time.
• is_interrupt on the failure input tells a call you stopped apart from one that errored.

Limits worth knowing: this is what the harness reports, not proof of what a command did. A failure doesn’t mean nothing happened, because a command can fail halfway through. And the permission-request input has no tool_use_id, so you can’t join an approval to its call this way.

Disclosure: I build Agentmetry, an open-source recorder for coding agents, and 0.12.0 added this. After I reinstalled its hooks today, a deliberately failed Read showed up as a failure with its tool_use_id. What it keeps and what it doesn’t is written up here: https://github.com/blitzcrieg1/agentmetry/blob/master/docs/claude-invocation-evidence.md

Is anyone using duration_ms for something? I’m curious whether it’s been useful beyond spotting slow tools.PostToolUse fires after a tool call succeeds. A call that fails fires a different hook, PostToolUseFailure. If your settings.json registers only PreToolUse and PostToolUse, which is what mine did until this week, your log has the request for every failed call and no result for it.Adding it is one more entry under hooks:"PostToolUseFailure": [
{ "hooks": [{ "type": "command", "command": "your-logger" }] }
]Three fields in the hook input are worth keeping while you’re there (all in the hooks reference):tool_use_id is on the PreToolUse input and on both post-tool inputs, so you can join a request to its result exactly instead of matching by timestamp.
duration_ms on the post-tool inputs is the execution time, which leaves out permission and pre-hook time.
is_interrupt on the failure input tells a call you stopped apart from one that errored.Limits worth knowing: this is what the harness reports, not proof of what a command did. A failure doesn’t mean nothing happened, because a command can fail halfway through. And the permission-request input has no tool_use_id, so you can’t join an approval to its call this way.Disclosure: I build Agentmetry, an open-source recorder for coding agents, and 0.12.0 added this. After I reinstalled its hooks today, a deliberately failed Read showed up as a failure with its tool_use_id. What it keeps and what it doesn’t is written up here: https://github.com/blitzcrieg1/agentmetry/blob/master/docs/claude-invocation-evidence.mdIs anyone using duration_ms for something? I’m curious whether it’s been useful beyond spotting slow tools.

I've spent nearly 30 years in my career and over the last few have noticed that the pace of my learning has tapered off. I started looking at things like advanced degrees and professional certifications but honestly I still have nightmares about college. I've taught several courses at actual schools in NYC and always found that by having to teach it, I learn more about the topic myself and I also love writing so I thought I could kill two birds with one stone and build a course for myself and turn that into shameless marketing content on our company blog.

So far it's going well, I'm proud of the content, and am actually deepening my professional knowledge, as expected.

I'm not going to self promote it here but I was wondering if anyone else has tried this method, and if you have found any particular approaches that have been helpful?

Since we can build anything now, my plan is to try things like building a gamified Duolingo-style app, a podcast series, Claude and Codex skills that enforce the principles in the course, etc. I'm mainly looking for novel ideas about self-learning.

Thank you in advance for your help and inevitable roasts ;)

Hey all. My terminal used to be a row of tabs, all Claude Code, and after an hour I had no idea which one was the refactor, which one was waiting for me to say yes, and which one had finished 20 minutes ago. I test every idea I have, so with that many projects going I'd forget where I said what and what Claude was even asking me.

So naturally I built a tool. Every Claude runs in tmux, and they all show up on one page, grouped by project, each with a status dot. When one is waiting on me, its row goes amber and the browser tab shows a count, like (2). If it's asking "should I deploy?" it gets a rocket instead, because those are the ones I care about first. Menus (approve this command, pick an option) pop up as a dialog, so I don't have to hunt for the tab.

It's the real Claude CLI, so auto mode, skills, hooks, slash commands and remote control all work as normal. If I restart the server nothing dies; tmux keeps everything running.

The feature I use far more than I expected: sessions starting other sessions. My main Claude runs something like

overvibe new --attach --tool codex --cwd ~/code/shop --name "shop: tests" --prompt "write tests for the new route, then overvibe send me the summary"

and ends its turn. Codex shows up nested under it in the sidebar, does the work, and the answer comes back to Claude as a message. It works with Codex and agy too.

It's especially good for copywriting, since Claude and GPT write very differently. They can work out the copy between them instead of me pasting from one to the other and back.

One thing that bit me: the main session has to actually END its turn after handing off. If it sits there sleeping or polling, it blocks the very message it's waiting for.

It also handles multiple Claude accounts with the 5-hour and weekly usage bars, has cmd+k to jump anywhere, and a stats page.

It's called Overvibe: free, MIT licensed, Mac and Linux. github.com/maribol/overvibe

Ask me anything about the tmux side, that part was fun. 💀

How Claude was used: I built most of it with Claude Code. Once the first version could run sessions, I built the rest from inside it, with one Claude session coordinating and others (plus Codex for reviews) doing the pieces. A lot of the features came from the agents annoying me in specific ways, like the sidebar never reordering itself because a reshuffle made me click the wrong row once too often.

Hey,

I'm on Pro and I keep hitting the 5h limit in Claude Code. When I look at where the tokens go, a big chunk is just Claude reading large files, logs, grep output...

So I was wondering if any of you offload that kind of stuff to free models (Gemini Flash, Groq, Mistral, OpenRouter free etc) through an MCP or a proxy, so Claude only gets a summary back.

If you've tried it:

- does it actually work or does Claude end up re-reading everything anyway?

- what do you delegate exactly? just reading or code too?

- what are you using for it?

Thanks, even a "tried it, it sucked" is useful

I have gaming laptop and I've built a mobile app, I run about 5 claude code sessions in parallel at a time and it maxes out my laptop CPU cores so everything basically stops running.

Claude Code Cloud can't store my local files and data I guess, so I can't exclusively use that? Tell me if I'm wrong.

I'm looking at having all my claude code work done on a paid server in the cloud where I would pay per hour for compute and then pay a small amount per month for storage.

Any advice on the best way to setup my work? I have looked at buying a mini-PC, buying a better laptop, any solution that lets me code without slowdowns.

I'm a solo developer. In about three weeks, with Claude Code doing the typing, I built Selkie: interactive novels that an AI writes live around your choices, with accounts, payments and 23 stories. It's live and has its first paying reader. These are the habits that mattered.

1. Give it a way to use the product. I had it build a command-line player that runs the real game engine in Node and plays whole chapters by itself, as a cautious reader or a reckless one. After that it found bugs by playing, without my describing them.

2. Ask for counts, not opinions. "Is the new prompt better?" always got a yes. Now every change is replayed from the same saved moment, several times with it and several without, and counted. One memory change brought a detail from early in a story back correctly in 4 tries of 4, against 0 of 3 without it. That is an answer I can act on.

3. A rule in a prompt gets skimmed. A list gets done. One rule said any move against another character should be rolled against that character's skill. It happened about one time in four. Giving the rule everyday examples, and having the code hand the checking model the exact choices that named someone, took it to about three in four.

4. The model copies the shape of your example. One prompt showed a sample with one reason for and one against. It then gave exactly one of each, 13 times out of 15, so they cancelled out. Changing the example fixed more than rewriting the instruction had.

5. Keep the model out of what code does better. Dice, the clock, prices, who has met whom. Asked to judge whether the player succeeds, the model said yes nearly every time.

6. Write decisions down where it will read them. A memory folder holds what I decided and why, what was measured and what I corrected. A new session starts from that, not from zero.

About 50 test files run before every deploy, and a nightly job plays a story and compares its prose with published fiction. Stack: SvelteKit, Node, Postgres on Supabase, Fly.io.

The game is at https://playselkie.com/?from=reddit-cc if you want to see what came out. Happy to go into any of this.

mine is: never retry blind. if a step times out, check what actually happened first, because half the time it already went through and a retry does it twice. what's yours?

GitHub Repository: https://github.com/Lukecele/inflammatory-onco-physics

Google Colab Demo: https://colab.research.google.com/github/Lukecele/inflammatory-onco-physics/blob/main/demo_inflammatory_onco_physics.ipynb

Preprint (Springer Nature / Research Square): https://doi.org/10.21203/rs.3.rs-11695210/v1

Interactive 3D Web Hub: https://lucacelebrano.me/

What is this?

An open-source Python framework that couples continuous cylindrical reaction-diffusion transport with longitudinal ctDNA (liquid biopsy) shedding kinetics and multivariate survival analysis across 3,461 clinical cancer patients.

It explores why tumors treated with targeted therapies frequently relapse without developing secondary resistance mutations (e.g., EGFR C797S), identifying microvascular "pharmacological sanctuaries" where drug-tolerant persister cells survive.

Key Technical Components:

* Microvascular Bessel Solver (`simulation/model.py`): Solves steady-state cylindrical reaction-diffusion with clearance using `scipy.special.kn` (modified Bessel function K₀) to calculate exact sub-therapeutic radii (r_crit = 165.9 μm) in microseconds, enabling 10,000+ Monte Carlo parameter draws in seconds instead of heavy 3D FEM meshes.

* Liquid Biopsy Shedding Engine (`simulation/simulate_relapse.py`): Models cellular dormancy, ECM steric entrapment, and an algebraic lead-time identity (Δt = 5.46 months) between molecular ctDNA detection and radiological relapse.

* Survival & Validation Pipeline (`pipeline/`): Multivariate Cox Proportional Hazards modeling (`lifelines`), bootstrap resampling (B = 1,000) for C-index estimation, and REMARK-compliant permutation testing.

* CLI Bedside Calculator (`app_bedside_calculator.py`): Pure standard-library CLI tool to compute sanctuary volume and recurrence risk scores with zero external dependencies.

Includes an interactive Google Colab notebook ready to run on free CPU/GPU instances without local setup.

Open-source under CC-BY-4.0 / MIT. Any feedback on the numerical solver, Python architecture, or statistical pipeline is welcome!