Cost Implications: Alignment-First, Prototype-First Workflow

analyze-sessions report — 2026-05-24 — Based on 9,482 Claude + 1,750 Codex history entries across 3,344 sessions

1. Overview & Key Numbers

The alignment-first workflow was introduced May 22, 2026 with the directive that every skill producing durable deliverables must output an HTML alignment page for browser-based review before the user approves canonical file writes. The prototype-first gate was introduced May 18, 2026 to ensure product/feature work produces clickable prototypes before production infrastructure.

Together, these represent a fundamental shift in how skills operate: from inline conversational iteration to structured preview-approve-write cycles.

2. Investment Cost: Building the Contract

2.1 Direct Development Overhead

Activity	Scale	Cost Signal
Initial alignment page contract design	3+ sessions, ~15 messages	Medium
Cross-cutting upgrade (`5f11f2f`): add alignment page to all skills	310 files, 4,222 insertions	High
Inline question migration (`d805201`): move questions from bottom section to inline	313 files, 634 insertions	Medium
Skip list creation + strip operation (`1aa1191` + `3b0b98d`)	30 files stripped, 480 deletions + scripts	Medium
Browser-open WSL debugging	3-4 turns in first session	Low (one-time)
Tooling scripts (upgrade, verify, strip, archive)	4 scripts, 3 now deprecated	Low
Benchmark fixture remediation (route assertions)	32 of 37 fixtures needed updates, full Phase 43	High

Total investment commits: 38 of 1,309 total commits (2.9% of all project commits) are alignment/prototype infrastructure. Since May 18, 17 of 126 commits (13.5%) have been alignment-related — a heavy recent concentration.

2.2 Indirect Costs

Q1: Was the cross-cutting 310-file upgrade the right approach, or should alignment pages have been added incrementally per-skill as each skill was touched?

Batch upgrade was correct — consistency matters more than incremental cost Should have been incremental — the overcorrection tax proves batch was premature Hybrid — batch for research/planning skills, incremental for everything else Other / None of the above Need clarification

3. Per-Session Cost Changes

3.1 Turn Count: Before vs After

Skill	Pre-Alignment Avg Turns	Post-Alignment Turns	Delta	Sample Size
`/icp`	8.6	5.0	-42%	16 pre / 1 post
`/idea-scope-brief`	2.7	5.5	+104%	Many pre / 2 post
`/competitive-analysis`	7.3	—	—	7 pre / 0 post
`/journey-map`	8.0	—	—	6 pre / 0 post

Caution Only 3 post-alignment research sessions exist (2 days of data). The ICP turn reduction is directionally encouraging but statistically meaningless at N=1. The idea-scope-brief increase likely reflects richer output scope, not workflow overhead.

3.2 Output Size Inflation

Metric	Pre-Alignment	Post-Alignment	Change
ICP alignment page size	N/A (markdown only)	57 KB HTML	New artifact
Average alignment page size	N/A	~14 KB	New artifact
Deliverables per skill run	1 (markdown research)	2 (alignment HTML + markdown)	2x artifacts

Each skill run now generates both an alignment HTML page (for browser review) and the canonical markdown deliverable. The HTML generation adds token output cost proportional to the page size. A 57 KB page at ~4 chars/token is roughly 14,000 extra output tokens per ICP run.

3.3 Where Costs Shift (Not Just Grow)

Savings Async review eliminates idle LLM context. When the user reviews an alignment page in their browser, zero LLM tokens are consumed. Pre-alignment, every feedback round required the model to hold conversation context while the user thought. On an 8.6-turn ICP session with 2-minute think times, that's ~17 minutes of context-window occupancy eliminated per session.

Savings Batched feedback reduces round trips. The compile-answers YAML captures all feedback in one structured payload instead of 3-5 incremental correction messages.

Cost HTML generation adds ~14K output tokens per research skill run. At Opus pricing (~$75/M output tokens), that's roughly $1.05 per alignment page. At Sonnet pricing (~$15/M), it's ~$0.21.

Cost Every skill contract now includes ~16 lines of alignment page instructions in its SKILL.md, which are loaded into context for every invocation — even when no alignment page is ultimately needed (e.g., a quick re-run of a previously approved deliverable).

Q2: The 14K extra output tokens per alignment page (~$1.05 at Opus) — is this an acceptable cost for structured browser review, or should alignment pages use a cheaper model?

Acceptable — the review quality justifies the cost Generate alignment pages with Sonnet/Haiku to reduce cost Keep Opus but simplify pages — less CSS/JS, more content density Other / None of the above Need clarification

4. Overcorrection Tax

The single most visible cost of the alignment workflow is the overcorrection-remediation cycle. This is the pattern:

Step	Commit	What Happened	Files
1. Require everywhere	`a839142`	Added alignment pages to all skills including run/ship loops	~310
2. Discover overcorrection	—	User corrected: "Run/ship loops are not alignment-page producers"	—
3. Build skip list	`1aa1191`	Created 30-skill skip list + strip script	3
4. Strip exempted skills	`3b0b98d`	Removed alignment sections from 30 skip-listed skills	30
5. Deprecate tooling	`4deed8f`	Archived 3 scripts that were only needed for the overcorrection fix	3+

This cycle consumed 4 commits and at least 2 full sessions to fix a problem that wouldn't have existed if the initial rollout had distinguished research/planning skills from execution/shipping skills. The lesson is documented in tasks/lessons.md (2026-05-21).

Pattern cost estimate: Each overcorrection cycle costs roughly 1-2 sessions of remediation work (~10-20 messages) plus the original overcorrection session. With 5 documented corrections in lessons.md, the alignment workflow has generated roughly 50-100 extra messages in correction overhead across 6 days.

Q3: Should future cross-cutting contract changes require a pre-flight classification step (research vs execution vs utility) before batch application?

Yes — add a mandatory classification gate before any batch skill update Just maintain the skip list — check it before batch operations Stop doing batch updates entirely — only update skills when individually touched Other / None of the above Need clarification

5. Prototype-First: Unrealized Investment

Warning Zero /prototype invocations found in either history file.

The prototype-first gate was introduced on May 18 with a clear lesson: "Product and feature planning should separate prototype exploration from production implementation." But in the 6 days since:

The prototype skill exists in the session skill list but has never been invoked
Infrastructure-only sessions outnumber prototype-only sessions 4.1:1 (432 vs 105)
Infrastructure-before-prototype sessions lead prototype-before-infrastructure 23 to 16
The prototype-first report itself noted a 2.7:1 ratio of production terms to prototype terms across all history

5.1 Cost of Unrealized Investment

Q4: The prototype-first gate has been in place for 6 days with zero invocations. What's the right response?

Be patient — the workflow is new, usage will come as projects reach that stage Force a test — run /prototype on an active project to validate the contract end-to-end Simplify — the prototype gate is over-engineered, reduce it to a lightweight check Other / None of the above Need clarification

6. Forward Projections

6.1 Steady-State Per-Skill Cost Model

6.2 Break-Even Analysis

Component	Pre-Alignment	Post-Alignment	Net
Turns per research session	~8 turns	~5 turns (projected)	-3 turns
Output tokens per run	~5K tokens	~19K tokens (research + HTML)	+14K tokens
User correction messages	~2-3 inline	~1 compiled YAML	-1-2 messages
Context tokens for alignment contract	0	~400 tokens (16 lines in SKILL.md)	+400 per invocation
Async review (no LLM cost)	0 min	~5-10 min	Saves idle context

The alignment page adds ~14K output tokens (~$1.05 at Opus) but saves ~3 turns of back-and-forth. Each saved turn avoids roughly:

~2K input tokens (user message + context re-read): ~$0.30
~3K output tokens (model response): ~$0.23
Total per saved turn: ~$0.53

At 3 saved turns: $1.59 saved vs $1.05 spent on HTML generation = net savings of ~$0.54 per research session at Opus pricing.

At Sonnet pricing, the alignment page costs ~$0.21 and saves ~$0.30 per avoided turn = net savings of ~$0.69 per session.

Positive ROI The alignment page pays for itself if it saves 2+ turns of inline iteration. The early ICP data (8.6 → 5 turns) suggests 3+ turns saved, putting this above break-even.

6.3 Amortized Infrastructure Cost

The one-time infrastructure investment (38 commits, 310+ file modifications, 5 correction cycles, benchmark re-runs) is a sunk cost. To amortize it:

At ~$0.54 savings per research session, the infrastructure investment (estimated at ~$50-100 in session costs) breaks even after ~90-185 research skill sessions
Historical rate: ~29 research sessions over the pre-alignment period (~5 months) = ~6/month
Break-even timeline: 15-31 months at current research session rate
If research session frequency increases (more projects, more users): break-even accelerates proportionally

Q5: The infrastructure investment takes 15-31 months to break even at current research session rates. Is this acceptable given the qualitative benefits (structured review, async feedback)?

Yes — the quality-of-review improvement justifies long payback Need to accelerate — increase research skill usage or extend alignment to more skill types Reduce future infrastructure cost — stop batch updates, only evolve alignment contract incrementally Other / None of the above Need clarification

7. Verdict & Recommendations

Summary

The alignment-first workflow is directionally positive on per-session cost but carries a heavy infrastructure investment that takes over a year to amortize at current usage rates. The biggest cost driver is not the alignment pages themselves but the overcorrection-remediation cycles from batch contract changes.

Key Findings

Positive Per-session turn reduction (~42% for ICP, N=1) suggests alignment pages reduce inline iteration cost
Positive Async browser review eliminates LLM idle-context cost during user think time
Positive Compiled YAML feedback replaces 2-3 incremental correction messages
Negative 14K extra output tokens per alignment page ($1.05 at Opus)
Negative 38 infrastructure commits (2.9% of all commits) for a 2-day-old workflow
Negative 5 documented overcorrection cycles consuming ~50-100 extra messages
Unknown Prototype-first gate: zero invocations in 6 days, untested contract

Recommendations

#	Action	Type	Impact
1	Freeze alignment contract changes for 2-4 weeks to accumulate real usage data	Standing instruction	Avoids further overcorrection tax
2	Track turns-per-session for research skills to validate the break-even hypothesis	Skill enhancement	Data collection
3	Run `/prototype` on one active project to exercise the untested contract	Manual test	Risk reduction
4	Consider generating alignment HTML with Sonnet subagent to reduce output cost by ~80%	Architecture	$0.84 saved per page
5	Add skill-type classification (research/execution/utility) to SKILL.md frontmatter to prevent future overcorrection	Convention	Prevents batch mistakes