u/sco77

Just had an appointment with a GI doctor and she explained that I have to fast before an endoscopy. When I told her that I do regular fasts of between 3 and 7 days, she was a bit adamant about saying I should not do fasts at all.

When I started explaining the deep microbiology of fasting responses of the body over time, she said "we can agree to disagree."

What on Earth is going on in Western medical education that a doctor of 25 years who works in GI has an adamant negative fasting attitude?

Hippocrites taught us that food is thy medicine and they take the Hippocratic oath to not do harm. Yet they are with a straight face saying that fasting is effectively bad for you, when doing so denies the evolutionary and anthropological reality of adaptive endocrinology resulting from occasional forced fasting on vast populations of humans in our history, due mostly to resource constraints.

I felt pretty confident in my description of the body's response at 3 days, 4 days and 7 days in terms of autophagy mitophagy and then protein remodeling.

Because I read studies.

Because I pay attention to this forum. Because I strive to understand the machinery of sustained caloric burn with this expensive brain.

It's like they don't understand how protein sparing works in a fasting scenario, and only deride the reduction of lean body mass in a fast as an unhealthy thing, not even realizing how ubiquitinated organelles are disproportionately selected during autophagy, leaving your in cells in an overall more healthy state after refeed and recreation of new organelles, or how pre-cancerous cells are stressed by glucose reduction and many may not adapt as well to the fasted state and end up triggering cell death of those cells.

I'm going on a bit, but the frustration of medical professionals being utterly blind to the well studied benefits of fasting is uniquely frustrating.

Any one else have experience with this wall of ignorance in the medical profession?

I'm trying to understand how people who use more than one coding agent (Claude, Codex, Cursor, Gemini CLI, Copilot, OpenCode, Aider, etc) actually split the work between them:

• Which agents do you run, and on what kind of work?

• How did you decide which one got that task?

• Have you caught an agent saying a task was done when it wasn't? How did you find out?

• Do you track which agent handles which kind of task well?

• Have you stopped using certain agent for certain work? What happened to make you stop?

• Has an agent ever sent something somewhere it shouldn't have (a key, an address, private code)? What happened?

I'm researching this for an open-source project to help us help ourselves and not get locked into big company harnesses. I'll post a summary of this thread if I get good feedback :D

Thanks!!!

**Pipeline:** Fable Orchestrator, Sonnet Workers, Opus Checkers (Complex tasks Opus Opus)

**Result:** *~90% of all caught defects were invisible to their own author at "done."*

.

Layer	Defects Caught	Unique Error Types
author self-review (builder, at green gates)	2	2
blind law check + blind correctness check	24	6
re-verify of fix rounds	8	2
final static confirm	2	0
.

**The builder's tree was green — typecheck, lint, 1098 passing tests — and still contained six functional defects:** the keyboard swallow, the macOS-dead chords, the detached-card menu, the stream-order inversion, a test that could not fail, and the vacuous boundary clause. Every one would have merged without the independent layers. The same held for Fable brief shipped as done. Blind check convicted it 17 ways, twice.

.

**RED-Proof statistic:** the green suite caught ~69% of induced defects; RED-sealing lifted the reachable kill rate to ~100%. 10% remain documented while **21% of Defects were Rescued**

.

**Across the three completed RED passes:** 95 mutations, 66 killed by the existing suite with 29 survivors. That's *one defect class in three passes a fully green suite silently*. Of the 29, 21 were sealed under pins (permanent detection) and 8 were proven unreachable behind stronger gates equaling the above measured reduction.

.

**Re-verify statistic:** fix rounds introduce defects at a ~50% rate per unit, and re-verify has caught 100% of them. Class 1: 2 (only re-verify caught them). Class 2: 2, including a silent inversion of a writer ruling. Stage 4: 2. Six for six, none escaped.

.

**The escape statistic:** *Zero known functional regressions reached post-merge across seven protocol units* 3 Fable session reviews since implementation (sessions 10, 15, 19) surfaced only design gaps and application feel issues, but not a single never a broken unit. Compared to the pre-protocol record we documented three defects that passed a green suite, two review rounds, and an executed gate, one of which would have returned No-Go on the study by construction. That class has not recurred since the blind layer landed.

.

**Cost:** *the protocol roughly doubles the unit's total compute* Stage 4 spent about 1.7M tokens building and about 1.9M checking. So the deducible trade is: ~2x cost buys ~10x defect detection over author self-review, a ~3x shrink in what a green suite can miss, and a measured escape rate of zero. This stands to augment the earlier post study [here](https://www.reddit.com/r/Claudeopus/comments/1vrmby0/token\_savings/) where the calculation focused on savings around cache and agent costs coming from the tiered model structure of the orchestration.

.

**Limits, stated:** this is observational, not controlled — there is no arm where we merged unchecked and counted your pain. **Important Note** *Author self-catch is undercounted* (defects fixed silently mid-build never register). And the denominators are small: seven units, 95 mutations. But the direction is not close, and every number above traces to a line in the record.

Pipeline: Fable Orchestrator, Sonnet Workers, Opus Checkers (Complex tasks Opus Opus)

Result: ~90% of all caught defects were invisible to their own author at "done."

.

Layer	Defects Caught	Unique Error Types
author self-review (builder, at green gates)	2	2
blind law check + blind correctness check	24	6
re-verify of fix rounds	8	2
final static confirm	2	0
.

The builder's tree was green — typecheck, lint, 1098 passing tests — and still contained six functional defects: the keyboard swallow, the macOS-dead chords, the detached-card menu, the stream-order inversion, a test that could not fail, and the vacuous boundary clause. Every one would have merged without the independent layers. The same held for Fable brief shipped as done. Blind check convicted it 17 ways, twice.

.

RED-Proof statistic: the green suite caught ~69% of induced defects; RED-sealing lifted the reachable kill rate to ~100%. 10% remain documented while 21% of Defects were Rescued

.

Across the three completed RED passes: 95 mutations, 66 killed by the existing suite with 29 survivors. That's one defect class in three passes a fully green suite silently. Of the 29, 21 were sealed under pins (permanent detection) and 8 were proven unreachable behind stronger gates equaling the above measured reduction.

.

Re-verify statistic: fix rounds introduce defects at a ~50% rate per unit, and re-verify has caught 100% of them. Class 1: 2 (only re-verify caught them). Class 2: 2, including a silent inversion of a writer ruling. Stage 4: 2. Six for six, none escaped.

.

The escape statistic: Zero known functional regressions reached post-merge across seven protocol units 3 Fable session reviews since implementation (sessions 10, 15, 19) surfaced only design gaps and application feel issues, but not a single never a broken unit. Compared to the pre-protocol record we documented three defects that passed a green suite, two review rounds, and an executed gate, one of which would have returned No-Go on the study by construction. That class has not recurred since the blind layer landed.

.

Cost: the protocol roughly doubles the unit's total compute Stage 4 spent about 1.7M tokens building and about 1.9M checking. So the deducible trade is: ~2x cost buys ~10x defect detection over author self-review, a ~3x shrink in what a green suite can miss, and a measured escape rate of zero. This stands to augment the earlier post study here where the calculation focused on savings around cache and agent costs coming from the tiered model structure of the orchestration.

.

Limits, stated: this is observational, not controlled — there is no arm where we merged unchecked and counted your pain. Important Note Author self-catch is undercounted (defects fixed silently mid-build never register). And the denominators are small: seven units, 95 mutations. But the direction is not close, and every number above traces to a line in the record.

Check this report y'all

Numbers, from the current price sheet (per million tokens):

Model Input Output Fable 5 (me) $10 $50 Opus 5 $5 $25 Sonnet 5 $3 ($2 intro through 8/31) $15 ($10 intro) The ratios are clean: one Fable token costs 2 Opus tokens or 5 Sonnet tokens (at the intro price — which happily covers your entire build week).

Measured from this session so far. The delegated work that has completed: the five-reader evidence workflow (~403k tokens: ~137k Opus, ~267k Sonnet) plus the two blind-check passes (~123k Opus). Call it ~526k delegated tokens. At a typical read-heavy mix, that cost roughly $3. Run through me instead, the same volume is roughly $8.50 — about a 65% saving on that work. The Sonnet builder still running will likely add several hundred thousand more tokens at the 5:1 ratio, and your Fable shape-review is the one place we deliberately spend the expensive tokens.

The bigger savings are structural, not per-token:

My context stays small. Those ~526k tokens of file-reading never entered my window — only the reports did. Every turn I take re-reads my whole history as input; a small history means each of my ~dozen turns costs a fraction of what a bloated one would, and the prompt cache (reads at ~0.1×) stays hot. This compounds across the session — it is the largest single saving and the hardest to put one number on. Blind checks cannot be done solo at any price. A checker must not share the builder's context. Today that layer caught three drifts and one regression in prose I wrote. That is a defect saving, not a token saving, and it is the part of the methodology I would defend even if all models cost the same. Fable spend goes where it multiplies: rulings, law prose, plan synthesis, and the shape-review. Spice, not the main course — your own instruction, and the economics agree with you. Caveats, stated honestly: the token counts are harness-reported totals, the input/output mix is estimated, and my own orchestration turns are Fable-priced regardless. Rough shape: the methodology moves 80–90% of the session's token volume down to Sonnet and Opus tiers, at 1/5th and 1/2 my price respectively.

Check this report y'all

Numbers, from the current price sheet (per million tokens):

Model Input Output Fable 5 (me) $10 $50 Opus 5 $5 $25 Sonnet 5 $3 ($2 intro through 8/31) $15 ($10 intro) The ratios are clean: one Fable token costs 2 Opus tokens or 5 Sonnet tokens (at the intro price — which happily covers your entire build week).

Measured from this session so far. The delegated work that has completed: the five-reader evidence workflow (~403k tokens: ~137k Opus, ~267k Sonnet) plus the two blind-check passes (~123k Opus). Call it ~526k delegated tokens. At a typical read-heavy mix, that cost roughly $3. Run through me instead, the same volume is roughly $8.50 — about a 65% saving on that work. The Sonnet builder still running will likely add several hundred thousand more tokens at the 5:1 ratio, and your Fable shape-review is the one place we deliberately spend the expensive tokens.

The bigger savings are structural, not per-token:

My context stays small. Those ~526k tokens of file-reading never entered my window — only the reports did. Every turn I take re-reads my whole history as input; a small history means each of my ~dozen turns costs a fraction of what a bloated one would, and the prompt cache (reads at ~0.1×) stays hot. This compounds across the session — it is the largest single saving and the hardest to put one number on. Blind checks cannot be done solo at any price. A checker must not share the builder's context. Today that layer caught three drifts and one regression in prose I wrote. That is a defect saving, not a token saving, and it is the part of the methodology I would defend even if all models cost the same. Fable spend goes where it multiplies: rulings, law prose, plan synthesis, and the shape-review. Spice, not the main course — your own instruction, and the economics agree with you. Caveats, stated honestly: the token counts are harness-reported totals, the input/output mix is estimated, and my own orchestration turns are Fable-priced regardless. Rough shape: the methodology moves 80–90% of the session's token volume down to Sonnet and Opus tiers, at 1/5th and 1/2 my price respectively.

I've been managing my minerals and this is my fourth 7-Day but I'm going to actually go into the 8th day and I'm just wondering what people do to break their fasts.

I've done it a few different ways and not always the best at first at least. But I have some ideas about how to do it this time, but I really want some encouragement about good ways.

I had to really lay down the law tonight. I have Cline running with deepseek V4 pro and Claude running with whatever model I can afford in my monthly ticker and my Google pro supporting my anti-gravity use. I can only afford the two pro accounts every month and so the deepseek API cost is the only variable and it's super economical. GLM 5.2 Is probably next on the horizon, but the only thing that makes this dog's breakfast work is what I discovered again for what I hope is the final time.

You really really have to have vigorous control of all of these things ....coding standards, workflows, ADR discipline, matching rule files for all of your agent interactions (so they can behave in a common way), document discipline, queue discipline, attribution discipline (even if it's just agent attribution it's still important), ideation session management, road map and feature creep management, ui integration management, hardware management and maintenance, tools updates, security updates.....

But no matter what, harness your agents harnesses through your code base discipline to keep harness harmony, And your sanity.

I have been working intensely on a pre-open source local first agent harness project for ~5 months.

​

The evolution of the project structure has taken profound turns as I researched and discovered important sub-components of how harnesses really work and, once my project got to a certain level of complexity, all hell started breaking loose:

​

* UI components would suddenly stop working

* Tests would pass but the actual code files would fail

* Architectural decision points once a decision was made and a task completed, would disappear from view: No ADR, no update to documentation (despite instruction to do this every time), And generally poor traceability for decisions.

​

But I didn't figure out how I was breaking things until I started running Claude Code.

​

Immediately, lots of problems surfaced. LOTS of problems.

​

* Tests that satisfied *themselves* but didn't function to actually test the code

* File after file, once we started to tie the front end back in, were... I don't know how to say this nicely, sort of cluged to work in isolation, and would fail silently upon execution.

​

But the real tell was the god files.

​

Using Gemini to develop the code had created a set of 3 monoliths that upon running a deep graph analysis proved to be the hole within which most of the silent failures resided.

​

So now a month into using Claude code, (sonnet and opus) I have a deep, segmented, organized, and stable application. It literally took a month to unfuck the rickety structure that actually contains a lot of (IMHO obviously) great ideas, but that we're not being exercised in the pipeline...

​

* My AST splitter was being ghosted and agents would just choke and OOM or return 0 data

* My context management system was being bypassed and causing illogical truncation.

* Agent model pairings were being confidently mis-declared, and downstream from that I had false confidence in smaller models doing work that I assumed bigger models were doing.

​

I could keep going but the real lesson was don't rely on Gemini to do anything that very confidently declares completed, only to later find *serious* flaws in the code output. Like a refactor that I did to better organize files from the root and got the * I got it all done sir "then the subsequent shim cleanup immediately broke *so many things* that I had to hastily restore them and have only now finally fully reorchestrated the code base so that it has zero references to the once root level files. I mean even building it there was a mistake Gemini never called me out on.

​

I'm not saying you can't trust Gemini to do work on your code base...

​

But what I am saying is research before you trust, then verify like three times: even using Gemini as a sub agent to do very well scoped tasks,(which I would do when I was in a claude cool down time) I still needed to validate the approach the agent took, and (to save my sanity) have a different agent accomplish the same exact task and compare the code output. This has saved my bacon on several occasions.

​

I started building this project in Gemini, using AI Studio, migrated to the anti-gravity IDE when it was released, and now, I literally use the anti-gravity IDE to auto compose git commit messages, and I still have to update those to be more detailed. I will use it for cleanup or validation operations, but I reserve less and less time to use Gemini for coding.

​

I have it make pretty pictures for me now.

​

So while this seems like a flame on Gemini in general, and maybe anti-gravity in specific, I still use anti-gravity to tweak the visuals in the UI, as it's pretty good at that... although it will also try to convince you to do something outlandish and pretty, but completely unnecessary if you don't put the brakes on its ambition.

​

And, also, of all the agents I've worked with, Gemini is by far the most sycophantic. It will blow smoke up your ass 12 ways to Sunday, even if your system instructions are very specific about reserving praise for super genius ideas alone. If I believed 5% of what it told me I would think I was an elite engineer.... And once I release this code to open source everyone in the world will know I'm definitely not 😆

​

By way of comparison, a month has allowed me to actually leverage the best mathematical objects, agent model pairings, and validation patterns I have insisted upon. And thank goodness I didn't take some Gemini advice to "just use cosine similarity" to check agent drift (SMH).. I would have left the two best pieces of code I wrote on the cutting board before they ever got implemented.

​

Trust but verify, and then verify again.

​

​

​