The Model Guide Got Better When Pricing Stopped Being the Main Constraint

How a long model-selection conversation became an interactive AIMM member guide, then changed again when the operating surface shifted from API pricing to subscription usage.

This final article is about turning a messy reasoning process into a shareable artifact.

It builds on the model-routing pieces in this series. If you have not read them, start with I Asked Which Model to Use. The Codebase Answered: For Which Step?

The question was not just “what do I think about models?”

The goal was to produce something AIMM members could actually use.

That meant transforming a long conversation into an interactive guide: clear enough for a first-time reader, structured enough to return to, and practical enough to shape real content workflows.

The Conversation Started as Model Comparison

The early question was direct:

compare claude-fable-5 vs claude-opus-4-8

That led into a series of model-selection questions:

• What does “knowledge work” mean?
• What is the minimum model for professional knowledge work?
• What is the minimum model for professional creative writing?
• How do output quality and pricing differ across effort levels?
• What model should handle each stage of a writing pipeline?

At first, the answers were model-centric.

Then the pipeline questions forced more nuance. Writing was not one task. It had stages:

ideation -> research -> angle selection -> outlining -> drafting -> editing -> fact-check -> headlines

Each stage had a different failure mode.

Research needed retrieval and citations. Angle selection needed judgment. Drafting needed voice and coherence. Copy editing needed mechanical reliability. Headlines needed taste.

That became the first useful guide structure.

The First Interactive Guide

The user asked:

summarize the above as an interactive html tutorial/guide that i can share with my aimm members

That changed the output format.

The guide could not read like a chat transcript. It needed to function as reference material. AIMM members should be able to scan, click, compare, and return later.

The first HTML guide used five sections:

1. The Models
2. The Core Principle
3. The Pipeline
4. By Content Type
5. Cheat Sheet

It included:

• model cards
• effort-level explanations
• flagship vs routine toggles
• expandable pipeline stages
• content-type selectors
• operating rules
• a decision flow

That was the right format for a member resource. It turned conversation into a tool.

Concept #1: Change the format when the audience changes.
A good chat answer is not automatically a good member guide. Reference material needs structure, navigation, and reuse.

Publishing to the Hub

The next step was to publish it.

The request was:

add the file to the herenow website, update the navigation and index pages as required, and publish to here.now online

The guide was already HTML, so the normal markdown publishing script did not fit perfectly. The file was copied into the herenow site manually, the index card was added, breadcrumbs were injected, and the site was published.

The live result:

https://brave-quiche-rax4.here.now/aimm-model-selection-guide.html

That step matters because a teaching artifact is not done when it exists on disk. For a mastermind group, the artifact has to be reachable, navigable, and integrated into the place members already look.

Publishing made it real.

The Guide Needed a Second Version

Later, the operating assumption changed.

The user clarified:

i want to use this guidance within a skill, run from claude, using subscription fees not api. imagine for now there is no fable 5

That forced a major reframing.

The first version of the guide was shaped by API pricing. It included model costs per million tokens, premium-stage decisions, and comparisons involving Fable 5.

But a subscription-based Claude environment changes the real constraints.

The issue is not “how many API dollars does this call cost?”

The issue becomes:

• Will this burn usage limits faster?
• Will this load too much into the conversation?
• Will this take too long?
• Should this step be inline, forked, or spawned?
• Should context be preserved or isolated?

The model-selection guide became a workflow-selection guide.

The updated version removed Fable 5 and reframed the lineup around:

Opus
Sonnet
Haiku

It replaced token-price thinking with four practical levers:

• model per subagent
• inline vs subagent
• extended-thinking triggers
• prompt and decomposition quality

Concept #2: Reframe the guide when the operating surface changes.
API pricing, subscription usage, and local workflow design create different constraints. The guide has to name which world it is serving.

The Pipeline Grew

The v2 guide also changed the pipeline.

The earlier version had 11 stages. The subscription-oriented version grew to 14.

New stages included:

• Stage 0: brief plus persistent voice block
• kill gate: check whether the angle is differentiated enough to pursue
• post-outline research pass
• split fact-checking: retrieval first, adjudication second
• final voice and AI-slop gate

That was not feature creep. It was a correction.

Once the guide was meant to run as a skill, the workflow had to include the gates that protect quality.

A writing workflow for knowledge entrepreneurs cannot only generate. It must also decide when not to proceed, when to gather missing evidence, when to force citations, and when to check whether the output still sounds like the person whose name goes on it.

The guide got better because the goal became more specific.

It was no longer a general model-selection explainer.

It was becoming an operational guide for a subscription-based AI writing skill.

What This Unlocks

The pattern here applies to any AIMM member resource.

A long AI conversation can contain real insight, but it usually needs to be transformed before it is useful to a group.

The transformation has three steps:

1. Extract the decision logic.
2. Choose a format that helps the member use it.
3. Reframe it when the operating context changes.

For example, a conversation about offer strategy might become a checklist, not an essay. A conversation about client onboarding might become a template. A conversation about AI workflows might become an interactive selector.

The artifact should match the job members need it to do.

Key Takeaways

• A model-selection conversation became useful when it was turned into a navigable guide.
• Member-facing reference material needs structure, not transcript-like prose.
• Publishing matters because the artifact has to live where members can find it.
• The guide changed when the operating surface shifted from API pricing to subscription-based skill usage.
• Workflow gates can be more important than model swaps.

How to Start

1. Take one long AI conversation that produced useful reasoning.
2. Identify the decision points a member would need to apply.
3. Choose the artifact format: guide, checklist, selector, template, or tutorial.
4. Remove details that only mattered inside the chat.
5. Publish the artifact where the audience already works.

Behind the Article

The highest teaching value was the v2 reframing. It showed that a guide can be correct for one operating surface and still need a redesign for another.

I compressed the detailed model comparison because the publishing lesson is about artifact transformation, not model fandom.

The single most valuable thing to add before publishing would be side-by-side screenshots of v1 and v2 so readers can see how the guide changed when the constraints changed.