A working breakdown of LLM API pricing across Anthropic, OpenAI, Google, and Z.ai, at every reasoning effort. Where the popular claim breaks down, where it could technically be true, and what the data says about intelligence.
Three numbers that answer the question. Source: first-party pricing and Artificial Analysis Intelligence Index v4.1.
cheaper per request at medium reasoning effort
cheaper per request at medium reasoning effort
leading open-weights model, tied with Opus 4.8 and GPT-5.5
A widely-shared take from a respected voice in the space argues GLM-5.2 is more expensive than the proprietary frontier at medium reasoning effort. Worth examining.
I see a lot of people hyped about GLM-5.2. Rightfully so! Having an open weight model surpass GPT-5.4 and every Gemini model is dope.
— Theo - t3.gg (@theo) June 21, 2026
That said - it's not cheap. Both Opus 4.8 and GPT-5.5 set to "medium" are cheaper and smarter than GLM-5.2 pic.twitter.com/SPovI1LKnZ
Theo is right about the first half. GLM-5.2 does surpass GPT-5.4 and every Gemini model on the Intelligence Index. The second half, the cheaper and smarter part, breaks when you run the math.
Reasoning-effort parameters control how many tokens a model spends thinking. They do not change the per-token rate.
The reasoning_effort parameter on GPT-5.5, the extended-thinking budget on Claude, and reasoning_effort on GLM-5.2 all do the same thing. They control how many tokens the model spends thinking. The per-token rate stays fixed regardless of effort mode.
| Model | Provider | Input /MTok | Cache hit /MTok | Output /MTok |
|---|---|---|---|---|
| GLM-5.2 | Z.ai | $1.40 | $0.26 | $4.40 |
| Gemini 3 Pro | $2.00 | $0.20 | $12.00 | |
| Claude Opus 4.8 | Anthropic | $5.00 | $0.50 | $25.00 |
| GPT-5.5 | OpenAI | $5.00 | $0.50 | $30.00 |
For Opus 4.8 at medium effort to come out cheaper than GLM-5.2, Opus 4.8 would need to emit roughly 5.7× fewer reasoning tokens than GLM-5.2, enough to close the per-token gap. In practice, GLM-5.2 uses more reasoning tokens at medium effort than Opus 4.8 does. The per-token rate gap is large enough that GLM-5.2 still wins.
20K input tokens, 70% prompt-cache hit, 5K output including reasoning. Reasoning tokens are billed as output on every provider.
Sorted cheapest first. Bar length is cost. Color intensity shows where each model ranks.
5.1× more expensive on the same workload.
6.0× more expensive on the same workload.
2.4× more expensive on the same workload.
Artificial Analysis Intelligence Index v4.1, a weighted composite of 9 evaluations including GDPval-AA v2, Terminal-Bench v2.1, HLE, GPQA Diamond, and AA-Omniscience.
The four frontier models land within two points of each other. Only Claude Fable 5, at $10 and $50 per MTok, clearly leads.
GLM-5.2 at 51 is the leading open-weights model on the index. On GDPval-AA v2 specifically, the real-world agentic work benchmark, GLM-5.2 scores 1524, ahead of GPT-5.5 (xhigh) at 1514. The Intelligence Index lead belongs to Claude Fable 5 (~60), which costs 2 to 3× more than everything else on this chart.
Theo followed up with a fair point. Cheaper per token does not mean cheaper in time.
It also uses way more output tokens. The tokens are cheaper, but the volume of them means you'll spend much more time waiting for results.
— Theo - t3.gg (@theo) June 21, 2026
Still dope! Just trying to make sure people set their expectations properly pic.twitter.com/hy6NO0CtEq
In his follow-up, Theo added: “the volume of them means you’ll spend much more time waiting for results.” That’s true, and worth being upfront about.
GLM-5.2 emits the most output tokens of any leading open-weights model. Lower per-token cost, but more tokens to wait for.
At max thinking effort, GLM-5.2 emits 43k output tokens per Intelligence Index task (37k reasoning, 6k answer). For comparison, MiniMax-M3 emits 24k, Kimi K2.6 emits 35k, and DeepSeek V4 Pro (max) emits 37k. GLM-5.2 is roughly 65% to 80% more verbose than the leanest open-weights peers.
For batch jobs and overnight pipelines, this is irrelevant. The cost advantage dominates. For latency-sensitive interactive use, Opus 4.8 or GPT-5.5 medium will feel snappier, even at higher cost, because they finish thinking in fewer tokens. That is a real trade-off, not a footnote.
Three narrow cases where “Opus 4.8 medium beats GLM-5.2 medium on cost” can hold up, if you squint.
Anthropic and OpenAI offer 50% discounts on batch jobs. Z.ai has no published batch tier. The gap shrinks to roughly 2.5× instead of 5×.
Claude Max or ChatGPT Pro at $200/mo bundles effectively unlimited usage of the top model. That pricing is not comparable to per-token API rates.
On individual evals (HLE, certain coding tasks), Opus 4.8 medium or GPT-5.5 medium can outperform GLM-5.2. The composite index places them as tied.
Three takeaways. Cost, intelligence, availability. The data holds on all three.
GLM-5.2 is cheaper than Opus 4.8 and GPT-5.5 at every published reasoning-effort level. It is roughly tied with both on the Artificial Analysis Intelligence Index v4.1. It comes from Z.ai under an MIT license, which means self-hosting, fine-tuning, and zero vendor lock-in are real options. None of the proprietary frontier models offer that.
For the first time, an open-weights model is a head-on competitor to the frontier on cost, intelligence, and availability. That is the right thing for builders who don’t want to depend on a single provider. The hype is correct. Set expectations on latency, then ship.
Every claim on this page ties back to a first-party source. No invented numbers.
Last updated June 21, 2026. Pricing pulled from first-party pricing pages on this date. Intelligence Index v4.1 published June 15, 2026.
Content strategy is the wrong abstraction for builders. You don't need a plan. You need a system that turns building into publishing.
Ask any technical founder two questions. The answers tell you everything.
There is a word that kills more builder content pipelines than any other. Strategy. It sounds right. It sounds mature. It sounds like something a serious operator should have.
A content strategy. An editorial calendar. A posting schedule. But strategy is the wrong abstraction for builders. And I can prove it with one question.
No. Or you know you should, but you haven’t gotten to it. Or you tried, but it didn’t stick. Every time.
Yes. Every time. Without hesitation. The refactor. The bug. The 2am architecture decision. The API choice and why.
The building never stops. The content never starts. Not laziness. Wrong abstraction.
It is not a strategy. It is infrastructure that runs while you build.
Here is a calendar. Here are topics. Write them. A parallel workstream. A new identity to maintain. A weekly guilt cycle.
I will log the sessions. I will draft the posts. You review and publish. A byproduct of work you are already doing.
Strategy is a parallel workstream. Pipeline is a byproduct of the work you are already doing.
A working content pipeline has three parts. Not five. Not ten. Three.
The builder never stops building. The builder never writes a post from scratch. The system does the transformation. The builder does the work that generates the insight.
What a session log costs you, vs. what a blank page costs you.
Spiel OS capture. What was decided, what was traded off, what was learned. Structured, searchable, ready for the transformer.
Per Buffer’s State of Social Media and Orbit Media’s annual blogger survey, the average blog post takes 4+ hours to write from scratch. Strategy-led content.
Same work. Different frame. The pipeline extracts what you already did. The strategy forces you to manufacture what you did not.
Why every content tool you have tried produces generic output.
Generic input produces generic output. Feed a system ‘write a post about productivity’ and you get garbage. Feed it ‘I refactored the orchestrator to use handoff-based LLM signals instead of state transitions, here is why’ and the output has teeth. Because the input has teeth.
The quality of the output is bounded by the quality of the work. Good work, good content. Shallow work, shallow content. Most content tools fail because they try to generate insight. The pipeline does not generate insight. It captures insight that already exists in your build sessions.
More founders posting. More AI flooding the feeds. The cost of generic content is rising every week.
Every week, more founders start posting. More AI-generated content floods the feeds. More generic advice clutters the timeline.
The founders who post the most specific content. The content that comes from real work. Real decisions. Real tradeoffs.
Specific content is hard to produce manually. Most founders skip it. A pipeline removes the friction.
Generic content is invisible. Specific content is magnetic.
The most common pushback. Also the easiest to answer.
I am not a content creator. Good. You do not need to be. The pipeline does not make you a content creator. It makes your building visible. There is a difference.
A content creator sits down and thinks ‘what should I write about today?’ You sit down and thinks ‘what should I build today?’ The pipeline takes the second question and generates the output of the first. You stay a builder. The pipeline handles the rest.
Three things shift when you install a pipeline instead of following a strategy.
Because it comes from real work. Real decisions. Real numbers. Generic content disappears by itself when the input is specific.
You never switch modes. You build. The pipeline captures. You review. You publish. No ‘I should write a post’ guilt.
Every build session produces content. Every decision becomes a post. Every refactor becomes a thread. The capture system does the rest.
The things you build, the decisions you make, the tradeoffs you navigate, that is not just work. That is content waiting to be published.
Every builder has an asset they do not track on their balance sheet.
For years I believed my work was not content. I built things. Shipped features. Refactored systems. Content was what you wrote after you built, in a separate mode called marketing, one I never felt qualified for.
This belief sounds rational, but it is a trap. It cost me thousands of potential connections, deals that never started, and a reputation that stayed invisible despite years of shipping real work. I was wrong.
The most valuable content you will ever produce is not the post you sit down to write. It is the engineering decision you made today that you never thought to publish.
Shipping at scale. Digikala, Takhfifan, Varzesh3. Real numbers, real teams, real production.
Not because I lacked expertise. Because I believed expertise and marketing were separate activities.
The most valuable content you will ever produce is the engineering decision you made today that you never thought to publish.
What if building and content generation are the same activity?
Not ‘build first, then write about it.’ Not ‘build while taking notes for later.’ The building IS the content generation. This is not a workflow optimization. It is an identity reframe.
When you refactor a state machine, you are not just improving your code. You are generating evidence about how systems should be structured.
When you choose Postgres over DynamoDB, you are not just making an infrastructure decision. You are generating a framework for tradeoff analysis.
When you kill a bug that took 3 days to find, you are not just fixing an issue. You are generating a lesson that 50 other builders are currently stuck on.
The session is the content. The post is just the format.
Three things shift when you stop treating building and content as separate activities.
You stop ‘writing posts’ and start ‘extracting from work.’ The work is specific. It has numbers. It has tradeoffs. Generic content disappears by itself.
You never switch from builder mode to creator mode. The voice that said ‘I hate marketing’ goes quiet because you stopped marketing and started documenting.
Every build session produces content. Every decision becomes a post. Every refactor becomes a thread. The capture system does the rest.
A builder works on something real. The session becomes the input. The system does the transformation.
A builder works on something real. A refactor. A decision. A bug fix. Instead of letting that work disappear into the commit history, they log the session. Not a diary. A structured capture: what was decided, what was traded off, what was learned.
Then a system reads that log, maps it to what other builders are struggling with, and generates platform-native posts. X for fast awareness. LinkedIn for long-form engagement. Blog for the source of truth.
The system is not the writer. The builder is the writer. The system is just the translator.
Two reasons. Both are about training, not about talent.
The dominant content playbook was written by marketers, not builders. It says: define your niche, plan your calendar, write your posts. A parallel workstream. A skill stack most builders do not have and do not want to learn.
A refactor is ‘I improved the code.’ It is not ‘I discovered a structural truth about state management that applies to every system.’ Builders see what they built, not what they learned.
You are sitting on a library of content. You just never catalogued it.
The objection I hear most. Fair.
This sounds like another content automation tool. I have tried those. The output is always generic.
If you feed a system ‘write a post about productivity,’ you get generic garbage. If you feed it ‘I refactored the orchestrator to use handoff-based LLM signals instead of state transitions, and here is why,’ the output has teeth. Because the input has teeth.
The quality of the output is bounded by the quality of the work. Good work, good content. Shallow work, shallow content. The system does not add depth. It extracts it.
If you are a technical founder feeling the tension between building and posting, here is the takeaway.
You do not need to become a content creator. You need to stop throwing away the content you already create every time you build something.
Your engineering decisions are content. They always were. You just needed a way to extract them without switching identities.
The gap that kept showing up was not the writing. It was the publishing, the last 20% that takes 80% of the energy. This week I shipped 3 things that close that gap.
Every pipeline that turns building into publishing eventually breaks at the same point. The writing is solved. The dispatch is not.
You build something. The session gets captured. The transformer drafts the post. The draft lands in your queue. You approve. Then you open three browser tabs and start copy-pasting.
The friction was never the writing. It was everything after the writing.
Three things that remove steps instead of adding power.
Buffer integration. X, LinkedIn, Threads in a single call. Free tier: 3 channels, 10 queued posts, 3,000 API calls a month.
Config + HTML template, opens in your browser. No Node, no Puppeteer. Edit a CSS variable, hit refresh, ship.
Frontmatter, version history, status markers, supersedes lineage. Voice-matched output starts from a clean input contract.
Buffer integration that falls back to direct APIs when you outgrow the free tier.
The Buffer integration posts to X, LinkedIn, and Threads in a single call. No copy-paste between tabs. No three separate logins. No scheduling tool with its own auth flow.
It is built on Buffer’s multi-platform API. The free tier is genuinely generous: 3 channels, 10 posts in queue, 3,000 API calls a month. One post a day across three platforms with headroom.
One post a day, three platforms, with headroom. No credit card to start.
When you outgrow the free tier, the tool falls back automatically. No config change, no tool switch.
The marginal cost from ‘shipped a build’ to ‘published across three platforms’ is now near zero.
Open one command. Edit a CSS variable. Hit refresh. The visual renders.
The banner tool generates post visuals from a config file and an HTML template. Open one command. A real HTML file opens in your browser. Edit a CSS variable. Hit refresh. See the new banner.
No Node setup. No Puppeteer. No Chrome path fixes. No shell-out dance. The engine is Playwright + system Chrome. The templates use CSS variables in a :root block. Change a color, save, render.
If a banner drifts more than 2% pixel-wise, the test fails. Drift is caught before it ships.
A post without a banner looks half-finished. The lack of a visual is the most common reason builders skip posting.
The tool removes the most common excuse for not posting.
The pipeline reads these to write in your voice. Drift in, drift out.
The docs the pipeline reads to write in your voice got a structural rewrite. Clean frontmatter. Version history. Status markers. Supersedes lineage. A clear source-of-truth declaration for every concept.
When the docs are clean, the output is clean. When they drift, the output drifts. The polish is not cosmetic. It is the input contract for the entire pipeline.
The five docs are the difference between an AI that sounds like you and an AI that sounds like an AI. They are not optional. They are the moat.
These 3 ships do not add power. They remove steps. That is the whole point.
The week’s lesson: removing friction from publishing is worth more than adding another feature. When the marginal cost of publish is near zero, the only question left is what is worth saying.
The constraint shifts from effort to taste. The pipeline handles the dispatch. You stay the editor. The builder never stops being the builder.
The repo is open source. The setup is a 14-question prompt.
Clone the repo. Drop the setup prompt into any LLM agent. Walk through the 14-question setup. The five strategy documents get filled with your strategy. Then every build session becomes:
No editorial calendar. No ‘what should I post’ loops. No blank pages. You build. The pipeline posts.
The capability question (can the AI write this?) is easy. The boundary question (should the AI write this?) is everything.
Every week there is a new AI writing tool. Better models. Smarter agents. More automation. The feeds get fuller of content that sounds like everyone else.
The assumption is linear: more AI capability leads to better output. It is intuitive. It is wrong.
The problem is not that the AI is not smart enough. The problem is that the pipeline has no quality gates. The AI keeps generating. Nobody says stop.
Volume without a gate is just noise at scale.
A content pipeline that produced 120 drafts per week. Published almost all of them. Engagement collapsed.
I built a content pipeline that produced 120 drafts per week. Top-of-the-line models. Beautiful prompts. Full automation. We published almost all of them. Engagement collapsed.
Not because the writing was bad. Because there was no selection mechanism. Volume without a gate is just noise at scale.
Top models, full automation. No selection. Engagement collapsed because there was no gate.
Built on state machines, not agents. Two LLM handoffs, two human checkpoints. The AI does the creative work, the human does the selection.
The capability question is easy. The boundary question is everything.
A self-driving car does not work because it has the best sensor. It works because it has brakes that fire when the sensor says stop.
A self-driving car does not work because it has the best sensor. It works because it has brakes that fire when the sensor says ‘stop.’ Content automation works the same way.
Volume is useful here. The creative layer generates options. Divergent work, exploration, drafts.
No core insight? Cannot draft. No format chosen? Cannot draft. Banner missing? Cannot publish. Gates are stop signs.
Every automated pipeline needs three layers, and they run in strict order.
Most builders optimize Layer 1. They want better prompts, smarter models, more creative output. The leverage is in Layer 2 and Layer 3.
Spiel OS is 30 gates wrapped around an LLM. Not because the LLM is weak. Because the gates keep the output human.
Hard rules enforced by code. Char count, hook, audience, frontmatter, word repetition. No judgment. No negotiation. Pass or fail.
LLM-judged checks. Voice match, insight density, format fit. Composite score must hit 0.85 or the draft does not enter the queue.
Every gate is a floor the pipeline cannot cross. 100 drafts in, 0 published without selection. Volume is easy. Taste is the gate.
A pipeline that generates 100 drafts and publishes none is more valuable than one that generates 100 and publishes 90.
Content has a quality problem. The barrier to entry dropped to zero. The only differentiator left is taste. And taste cannot be automated. It can be gated.
The best content systems are bottlenecked by human judgment, not machine throughput. This is why I built the gate layer in Spiel OS: 30 checks total, 16 mechanical rules plus 14 creative gates. The engine is 30 gates wrapped around an LLM.
Not because the LLM is weak. Because the gates are what keep the output human.
Before you write a single prompt, answer these three questions.
Where does the machine hand off to a human? Find the seam. Spiel OS has exactly two. Format selection. Publish decision.
What artifacts must exist before the pipeline advances? No core insight? Cannot draft. No format chosen? Cannot draft.
What happens if the machine generates garbage? How is it caught? Build the catch before the generation. The catch is the gate.
Build those gates first. Then add the AI. The system that knows when to stop will outperform the system that never does.
2 minutes of capture per build session. The rest runs itself. No blank pages, no editorial calendar.
You ship real things. You solve hard problems. Your DMs are empty.
I spent 8 years shipping real things. Almost nobody knew. Not because the work was bad. Because I never connected the build to the post.
The issue was never writing skill. The issue was that the work happened, the lessons surfaced, and none of it ever connected to a post. A build-session pipeline solves this by making the build the source of every draft.
Real products, real users, real numbers. Almost nobody knew because nothing was ever connected to a post.
That is the entire input. The rest of the content pipeline runs itself. No blank pages. No editorial calendar.
The build is the post. The build is just not connected to the output. That gap is the entire game.
2 minutes of capture. No thinking. This is the raw input that feeds the entire pipeline.
I dropped this into a markdown file at the end of a build. 2 minutes. No thinking. This is the raw input that feeds the entire content pipeline for developers.
session: 2026-06-13
title: refactored auth layer from sessions to jwt
what i did:
- replaced session-based auth with jwt
- cut p95 login 800ms → 90ms
- fixed race condition in token refresh
decisions:
- chose jwt over opaque tokens for stateless verification
- kept refresh tokens server-side for revocation
numbers:
- 800ms → 90ms p95 login
- 0 → 100% of routes now stateless
lessons:
- stateless auth is not “less secure.” it is just different secure.That is it. That is the entire input.
The system loads your strategy documents, runs the session through the compiler, and produces platform-native drafts in your voice.
Your auth is slow because your server is doing too much on every request. Mine was. 800ms p95 just to log in. The fix was not a faster database. It was moving from server sessions to JWT.
Your auth is slow because your server does too much on every request. Mine was. 800ms p95 just to log in. Moved from server sessions to JWT. 800 → 90ms.
800ms login → 90ms login. moved from sessions to jwt. the server does almost nothing now. tradeoff is revocation. worth it.
Full blog post: 4 sections, 800 words, your voice, the reader’s problem at the headline, your build as the footnote.
2 minutes of capture, 30 seconds of review, 0 minutes of writing. The reader gets a post. You did not switch identities. You did not stare at a blank page.
The build is the footnote. The reader’s problem is the headline.
The configuration layer. Nothing else. The rest is execution.
I will not explain the full architecture. Just the point of each document. They are a compiled configuration. The pipeline makes a decision without one only by guessing.
Most of the 30 checks are mechanical noise. These 3 are the ones that change the output.
If the draft does not talk to one named reader at one problem layer, it dies. This is the gate that filters out the ‘here is what I built’ posts that nobody reads.
If the draft mentions the engine, the compiler, the gates, the funnel, or the session log. It dies. The reader does not care about your pipeline. They care about their problem.
If the first line is a preamble, a definition, or ‘I wanted to share’. It dies. The rewrite happens before it reaches the queue.
The other 27 checks are belt-and-suspenders. These 3 are why the drafts land.
The 5 are not independent. They are a compiled configuration.
The pipeline has no input. You go back to the blank page and the calendar that never works.
Every post goes to the wrong stage with the wrong call to action.
The posts talk to nobody in particular. They reach everyone and convince no one.
The output drifts. Internal labels leak. Posts start to sound like press releases.
If you post 2 times a week, this is overkill. If you generate 20-30 pieces per month from shipped work, this is the minimum viable architecture.
The repo is open source. Clone it. Drop the setup prompt into any LLM agent. Walk through the 14-question setup. The 5 strategy documents get filled with your strategy. Then every build session becomes:
git clone https://github.com/ShayanSpiel/SpielOS my-engine
cd my-engineYou updated your bio. Your system didn't. The old positioning is still running in files you forgot existed.
Most founders treat positioning like a copy change. You rewrite the tagline. You update your LinkedIn headline. You feel like you have done the work.
I updated my positioning two weeks ago. The UI changed. The system did not. New tagline. New bio. New homepage. All live. Then I checked the template files.
The previous version was still there. All of it. Each paragraph, each assumption, each outdated reference. The bio said one thing. The files said another. The documents that should have been updated months ago were still speaking the old language.
The new tagline is live. The new homepage is live. Surface-level, you look fresh.
5 templates referenced the old offer. 3 documents used outdated pain points. The market doesn’t see just your homepage. It sees the whole system.
Your positioning is not what you write in your bio. It is what people consistently see everywhere they encounter your business.
The surfaces that break first are the ones you forget exist.
The surfaces that break first are the ones you forget exist: proposals, onboarding docs, email sequences, case studies, sales scripts, prompts, and internal frameworks. Each one is a surface your market touches.
Still reference the old offer structure. The buyer reads it and gets a different story than the one on your homepage.
Subject lines, body copy, CTAs all written for the previous positioning. New leads enter an old conversation.
Pain points from the previous audience. Your ICP moved on, your case studies didn’t.
Objection handling for problems you no longer solve. The script argues the wrong point.
LLM agents trained on the old positioning. Every output drifts back to the previous state.
The slide that says ‘we do X’ when you now do Y. Investors and buyers notice the mismatch.
As long as any of those surfaces still communicate the old story, the market can still encounter the old version of you.
A prospect reads your bio, new story. Then they open an old proposal, old story. Two different messages. Neither fully true.
That is not a fresh start. That is a leak. Here is what most founders miss: each mismatch forces a lead to reconcile two versions of reality. That cognitive friction erodes trust. Most buyers will not do the work. They will just move on.
Each surface that disagrees with another is a small piece of work the buyer has to do to understand you. Most won’t.
The buyer senses the mismatch even if they can’t name it. They move on. You never know why.
Do not think ‘go through each file.’ Think: map every surface that outputs positioning. Then check which version each surface still runs.
Map every surface that outputs your positioning: website, bio, proposals, onboarding docs, email sequences, case studies, sales scripts, prompts, pitch decks. Update each one until the entire system emits the same state.
It takes an afternoon. It is not glamorous. But it is the only thing that actually changes your story.
Every place your positioning lives. Website, bio, proposals, decks, sequences, scripts, case studies, internal prompts.
For each surface, which state does it still emit? New or old? Mark the ones that disagree.
Rewrite each mismatched surface until the whole system emits the same story. One afternoon. The only thing that actually works.
The bio is the first checkpoint. Not the finish line. Positioning is infrastructure, not decoration.
Every content tool asks you to be someone else. A content pipeline for developers works from the terminal, doesn’t require identity switching, and treats posts as a byproduct of building.
Technical founders have 5 to 15 years of deep expertise. They ship real things. Their DMs are empty.
I have talked to dozens of technical founders. Here is the pattern. They tried posting. Got 2 likes. Gave up. They know they should publish. But every time they open a tool, they feel like they are putting on a costume.
Plan a calendar. Find your niche voice. Post consistently. The implication is always the same: you need to become a different person.
The technical founder who built their identity on being a builder resists the second job at a gut level. Not because they are lazy. Because becoming a creator threatens who they are.
The tools do not solve this. They reinforce it. You need something that does not require identity switching.
When you treat writing as a separate job, three things happen.
‘I will post after I finish this feature.’ The feature never ends. The post never happens. Most of your expertise never reaches anyone.
The post becomes ‘here is what I built’ instead of ‘here is what your problem looks like.’ The reader does not care about what you built. They care about their own problem.
The cognitive cost of switching from builder-mode to creator-mode is real. Every switch drains willpower. Most people stop switching entirely.
The result: years of expertise, zero inbound, and a quiet feeling that you failed at something you never actually tried to do.
Writing is not a separate activity. The work session is the source.
Every build produces artifacts: decisions made, numbers measured, lessons learned, patterns noticed, things shipped. Those artifacts are the content. They just need to be captured and transformed.
Prompt, edit, post. Two jobs. The second job requires a different identity. The audience resists it at a gut level.
System captures, transforms, gates, queues. You never switch identities. You build. The system handles the rest.
Real outputs from the system. Two minutes of capture, three to five bullets, no writing.
Step 1. You log a session. 2 minutes. 3 to 5 bullets.
- Switched API gateway from REST to GraphQL
- Query time dropped from 400ms to 40ms for complex joins
- Key lesson: REST forced N+1 queries in the frontend
- Tradeoff: caching is harder now, need CDN strategyStep 2. The system inverts the frame. Your session is not the subject. Your audience’s problem is the subject. The system rewrites the orientation: ‘Your API sends too much data because REST forces over-fetching.’
Step 3. The final post lands on the reader’s problem.
Your API is slow because REST makes you over-fetch.
We switched our gateway to GraphQL.
Query time: 400ms → 40ms.
The frontend now asks for exactly what it needs.
No more stitching responses. No more N+1.
Tradeoff: caching gets harder. But the latency improvement was worth it.
Most teams optimize the database before they optimize the API layer.
Start at the right level.The build is the footnote. The reader’s problem is the headline. You never wrote a ‘post’ — you logged a decision and the system did the rest.
It runs from your terminal. Two templates, one script, one workflow.
Every alternative puts you in a role you did not choose. This one puts you in the role you already have.
You write everything. Identity: Creator. The role you never signed up for.
AI generates posts you approve. Identity: Manager. The role of a content reviewer.
LinkedIn scheduling + analytics. Identity: Social media manager. The role of a scheduler.
GTM drafts from your repo. Identity: Marketing strategist. The role of a brand.
Identity: Builder. The role you already have. The only one you need.
I could not find a tool that let me stay a builder. So I built one.
I install Spiel OS for a small number of technical founders. Not because of scarcity marketing. Because it requires deep alignment with your workflow. The templates need to match how you build. The gates need to match your standards.
Full pipeline installed in your workflow. Positioning, offer design, agents, templates, 30 days review. You own it.
No subscription. No ‘we changed the pricing’ email two years from now. The system lives in your repo or vault.
3 slots per month. Hard cap. If after 30 days you’ve run 5 sessions through the engine and you don’t have 5 standalone-tested drafts, full refund.
A developer content pipeline workflow built in 72 hours. 4 blog posts, 3 LinkedIn posts, 2 state machines, ~85 queued drafts. One system that makes output compound.
For a long time, every work session had the same ending. I built something. I learned something. I moved on. But nothing was captured in a way that could be reused.
I would finish building something, close the session, and the output would basically disappear. Not literally — the code was there, the ideas were there — but nothing carried forward into content, writing, or distribution. So the next day, I would start again from zero.
The disconnect was the real bottleneck. Not writing. Not ideas. Just capture.
By the end of the sprint, the system had produced this much output — and the numbers are not really the point.
Live and indexed. Each one routed from a session log through the compiler, drafts, and gates.
Auto-published through the Buffer integration. Voice-matched, format-correct, approved in the queue.
Single-purpose building blocks. Write, classify, publish, archive, extract. No magic scripts.
Knowledge loop and content loop. State machines, not agents. Deterministic. Reliable.
Sitting in the queue for refinement, repurposing, scheduling. The system keeps producing, you keep curating.
Up from 10. The vault expanded. Every session now produces something that survives it.
The numbers are not really the point. The real change is this: now every session I run produces something that survives it.
I rebuilt my workflow into three simple layers. Each one does one thing. Predictable building blocks, no magic scripts.
I stopped trying to make every post do everything. Each piece now has a single responsibility.
Not everything worked. At first, I over-engineered the system.
The rules got too complex and started conflicting. The system was working against itself.
Some outputs lost the human voice. The pipeline optimized for cleanness, not for feel.
The system started overwriting things I actually needed to keep. Loss of history.
Reduced the rule system by more than half. Enforced one principle: if it does not help output, it does not stay.
Output is not the hard part. Retention is.
Most people do not lack ideas. They lose them. The real advantage comes from building something that preserves what you produce and feeds it back into the next session.
Once I had clear stages, clear commands, clear roles for each output, decisions became almost automatic. No hesitation. No overthinking.
The moment I forced every piece of content into a role (TOFU, MOFU, BOFU), quality actually increased. Because I stopped trying to say everything at once.
This sprint did not work because I worked harder. It worked because less of my output was getting lost. That changed the compounding effect.
At first, this was just a personal experiment. Then it evolved into a system where thinking produces structure, structure produces content, content feeds back into thinking.
Instead of isolated sessions, I now have continuity. That is the real win. A system where thinking produces structure, structure produces content, content feeds back into thinking.
Every build session produces structured artifacts. Decisions, numbers, lessons, tradeoffs. The system knows how to handle each shape.
Structured artifacts become drafts. The compiler inverts the frame toward the audience’s problem. Gates filter the output.
Published content feeds engagement data back into the knowledge layer. Patterns surface. The next session starts smarter.
This is not finished. Some parts are still messy. But the loop itself is working now. And that matters more than perfection.
Still needs work. The compiler is good but not perfect. Corpus-driven voice is the long-term play.
Not every step needs to be automated. Some things are better done by hand. The hard part is knowing which is which.
The gates help, but human curation is still the most expensive part. Quality is a function of what you refuse to publish.
You do not need to produce more content. You need a system where nothing you produce disappears.
Because once output accumulates instead of evaporating, everything compounds. That is the system I build for technical founders — a developer content pipeline that makes your work durable and your output compound.
The system was built in 72 hours. Not because I worked faster. Because I stopped losing work.
Same system, installed in your workflow. Positioning, offer design, agents, templates, 30 days review. You own it.
If after 30 days you have run 5 sessions through the engine and you do not have 5 standalone-tested drafts, full refund.
Build in public automation means content is a byproduct of building, not a separate calendar.
Every builder knows this pattern. You spend the week doing real work, decisions under pressure, features shipping or breaking, patterns emerging in real time, and then Sunday comes.
I tried to automate building in public for years. Every content calendar failed. Monday plan, Tuesday outline, Wednesday draft, Thursday revise, Friday publish, Saturday 0 comments. And the entire time, I was building real things, shipping features, making decisions, learning lessons that changed how I think.
None of that became content. Because I treated content as a separate job. A parallel universe. Building was real. Content was scheduled. That separation is the problem.
The problem is not lack of content. The problem is separation of context. Building and content were split into two systems, and that split is the bug.
There is a smaller, more accurate unit of reality. The session.
A session is any focused block of work that produces at least one of: a decision, a number, a lesson, a pattern, a shipped artifact. If none of these exist, it was not a content-worthy session. It was just activity.
You chose X over Y. You picked this approach over that approach. The decision itself is content.
400ms to 40ms. 800 to 90. Real numbers, real before-and-after, real signal.
Something you learned that would save someone else 3 weeks. The lesson is the post.
Your work session is the content source. Not inspiration. Not raw material for repurposing. Source of truth.
Work → Session Log → Strategy → Compiler (8 steps) → Draft → Gate (30 checks) → Queue → PublishNo separate ‘content creation phase.’ Content is extracted from reality, not invented in parallel to it. The system is the open-source Spiel OS. The full content pipeline for developers removes the identity switch. But extraction alone is not enough. Every post needs a job.
What you build is the content. Not what you planned. Not what you meant to share. What you actually built, decided, or learned. That is the content.
Work, log, classify, compile, gate. No magic scripts. Just predictable building blocks.
This system runs on the open-source Spiel OS. The result is not a plan. It is 30 posts from 12 sessions, classified into a funnel stage.
Each routed from a real session. No content calendar. No planning meetings. No ‘what should I post’ loops.
Every post traces back to one of 12 focused work blocks. The average post is 2.5 sessions of input material.
Every draft passed 30 checks before reaching the queue. The gates are what keep the output human.
And the most important part: the best-performing posts were not planned. They came from real decisions made in real time.
Four things changed. Each one is a precondition. All four had to be true at once.
More content does not create more attention. It creates noise. Planning is the wrong response to a noise problem.
The highest signal is inside shipping logs, debugging sessions, product decisions, and failed experiments. But it stays invisible without capture.
LLMs can now read session logs, extract insight, shape narrative, and format platform-native posts. The bottleneck is no longer writing. It is capturing reality.
Without strategy, session output is noise. With an ICP, a content funnel, and a classifier, that same output becomes a lead generation system.
The old model asks: what should I post this week. The new model asks: what did I build, what problem layer does it hit, what funnel stage does it feed.
We need 3 posts for consistency. Fill the calendar. The output is generic because the input is generic.
What problem layer does it hit. What funnel stage does it feed. The output is specific because the input is specific.
Tomorrow. After your work session, write 3 lines. That is your session log.
That is your session log. Now classify it. Is it a system build, a ship, a lesson, or nothing. Then ask: what funnel stage does it feed. If it feeds the funnel, publish it. If not, continue building. No calendar required.