> freezes the gates LLM-written readmes love to use inscrutable jargon that means nothing outside of the context window that birthed it.
LLMs are obsessed with “gates”. Freezing the gates here is intuitive to me as this point — don’t let validation drift.
/architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
41–47 of 47 posts
Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#42> freezes the gates LLM-written readmes love to use inscrutable jargon that means nothing outside of the context window that birthed it.
Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#43Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#44Reduce Fable tokens by 80%, simply by not using it! > I am fairly convinced this is the shape serious agent work keeps converging toward. "this" being "plan with expensive model, implement with cheap model". Anyone who follows HN would be hard-pressed to disagree; this architecture is re-invented twice monthly. https://www.facebook.com/groups/vibecodinglife/posts/1946207... https://github.com/openai/codex/discussions…
I don't disagree with any of this. It is generated software, and it's not a novel idea. I didn't mean for it to come off like that. It's just solving an itch that I couldn't find a solution to and I'm getting a lot of personal utility out of it. I do have a lot of experience with agentic memory, multi-agent systems and harnesses and wasn't super impressed by the workflow of Fable calling opus subagents so I figured I…
FWIW, re: best practices, your install script potentially runs `rm -rf` on the user's global skills whose names shadow your project's.
Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#45Earlier quoted context omitted.
Agents are in a wacky state, which makes projects like this fall into a weird spot. Eg I vaguely expect my agent to do two disparate things: manage dependency injection for tools, prompt modifications, etc, but also be the sort of “brain trust” that controls the flow of execution (can we stop now, do we keep going, etc). This project is meant to be the latter, but there’s not a clean way to integrate that into Claude…
But why does your agent control doneness? It seems to me the most odd part to delegate. All LLMs are terrible at it. Most LLM tasks can be expressed as a DAG or DAG of DAGs. Why delegate that to a random point in context instead of enforcing the flow?
And it gets delegated to context because it’s either to have another session and tell it to double check and critique the first LLM than it is to write a deterministic test for every prompt. Like if I want a new form that sends a REST request on submit, I can have two LLMs duking it out in 5 minutes. If I have to write Selenium tests then I might as well just write the feature. Or I can have an LLM write the tests, but that’s more or less the same as letting a second LLM judge the first.
Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#46Earlier quoted context omitted.
I had a similar experience. So far Fable has been a game changer, at least for the work I used it for. Having said that, I think its writing is definitely worse than GPT 5.5. Ethan Mollick also observed the same. He called it more "Claudy." It generates worse academic prose than other frontier models.
I think the claude code harness made up a significant part of the improvements co-released with Fable, the nested agent capabilities seem to be much better even with opus (which I guess we're stuck with for a while).
Re: /architect: Reduce Fable tokens by 80%, Fable orchestrates/reviews, Codex builds
#47I wanted to see what would happen if Claude delegated work to pi wiht a model like Deepseek, so I forked your repo and tried it out. It's working really well so far. https://github.com/pcomans/architect-loop-pi