The Architecture Decided the Cost. I Just Approved It.

Before any code was written on the OBF Analyzer, a PRD existed. A Content Director had translated the project requirements into a formal specification. A Sr Mobile Architect and a Sr Product Security Engineer, both Claude agents operating under defined roles, reviewed the document and pushed back on two design decisions. A token budget was estimated, written to dev-budget.md, and reviewed. I said go. Build began.

That sequence is not optional. It is the standing procedure for every build in this org. The agents follow a defined SOP and style guide. The budget gets written before the first session opens. I review it and approve it. No gate, no build.

The budget was $0.93. The actual cost was $0.68. That number is not the goal. It is evidence that the process works.

What the Tool Does. What It Does Not.

Building a tool that tries to do both analysis and judgment is how you build a tool that does neither well. The OBF Analyzer handles one side cleanly: JAR symbol exposure, readability scoring, findings classified by signal type and risk level, output as a DOCX report and Markdown summary. The verdict stays with the analyst. That boundary was a design decision, not a limitation.

The Tradeoff Was Named Before The Build Started

Building every file through Claude Code with Sonnet handling all 34 files is the straightforward path, and it has real advantages worth naming honestly.

The capability ceiling is higher. Sonnet and Opus understand security domain context deeply. They reason across multiple files simultaneously and catch integration issues that a less capable model misses. For complex multi-file work, that reasoning quality shortens debug cycles and reduces the iteration cost of getting to a working build. You also get no local infrastructure to manage: no GPU requirements, no model management, no prompt engineering around a local model's context window.

The naive token estimate for this project, assuming Claude Code handled every file, was approximately 470,000 tokens at roughly $1.80. On a Pro plan with a credit balance, that is not a breaking number. But it is the floor, not the ceiling. Debugging cycles, failed code generations, and the overhead of long sessions all compound on top of that baseline. The real question is whether Sonnet-level capability is actually required for all 34 files. For most of them, it is not.

Naming that tradeoff before the first session opened was the decision that made everything downstream predictable.

The Pro Plan Reality

The Claude Pro plan operates on session windows. Sessions cap out. When you are 47% through a 5-hour session with a complex build and the meter is moving, you make choices about how to allocate what is left. That constraint is not unique to this project. It is the real-world operating condition for anyone building on Claude Code without an enterprise billing account.

The answer is not to work around the limit. It is to design the build so that expensive sessions are reserved for work that actually requires them.

How Ollama Solved It

We used Ollama in two distinct roles, and keeping them separate was important.

During development, Ollama (qwen2.5:14b, running locally on an M4 Mac) generated 22 of the 34 project files: test suites, output writers, data model definitions, configuration files. Anything where the algorithm was fully specified in the PRD and the implementation was mechanical. Not one of these files required Sonnet to reason about cross-file architecture.

The discipline that made this work was the spec injection rule. Every Ollama codegen prompt had to include the complete verbatim definition of every dataclass the generated code would access: field names, types, and sentinel values. Not a description of the dataclass. The actual definition. Without this, Ollama invents attribute names from prose context and the code fails at runtime. With it, Ollama generates correct code on the first pass. Across Phase 2, every Ollama-generated file produced under the spec injection rule was accepted without modification. The spec injection rule eliminated the failure mode entirely.

At runtime, Ollama plays a completely different role. The report_generator.py script passes structured finding data to a locally-running model (gemma4:26b or qwen3:14b) to write the narrative sections of the DOCX assessment report. This is not code generation. This is the product itself. No Anthropic API calls. No ongoing cost. The tool runs identically after the hundredth use as it does after the first. Shipping a tool that calls the Anthropic API for every report means ongoing cost and a network dependency. Shipping a tool that runs fully offline means a product that costs nothing after the build. Better product, not just a cheaper one. After the build phase ends, Anthropic never sees another token.

Model Assignment Happens Before Development

The decision framework was assigning every file to a model tier before writing any code. Not after. Before.

Tier 1 is Ollama for pure data: JSON configuration, lookup tables, anything requiring no reasoning. Tier 2 is Ollama with a complete spec for new utility modules, where the algorithm is fully described and every dataclass definition is included verbatim. Tier 3 is Claude Haiku for mechanical edits to existing files: add a field to a dataclass, extend a list, wire up a new parameter. Tier 4 is Claude Sonnet for complex logic, new algorithms, multi-file integration, anything requiring architectural judgment.

The decision rule collapses to two questions. Does this file require judgment about how it connects to other files? Does it require reasoning about edge cases not fully specified in the PRD? Yes to either means Tier 4. No to both means it works down the stack until it lands at the right tier.

The mistake this prevents is defaulting every task to the most capable model because it feels safer. It is not safer. A Tier 2 file generated by Ollama with a complete spec is more reliable than a Tier 4 file generated by Sonnet from a vague prompt. Capability without specification produces inconsistent results at any model tier.

All figures below include the Phase 2 sprint.

The Numbers

Before any session opened, every file had a model assignment and a token estimate based on that assignment. The initial budget was $0.93. The project completed at $0.68, approximately 48% below the naive projection and 27% below the optimized estimate.

That reduction is not the result of prompt optimization or cutting corners during development. It happened because model selection was treated as a design decision before the first file was generated. The architecture predicted the cost. The actual confirmed the prediction.

A Phase 2 sprint added 6 features post-MVP: false positive reduction and evidence framing. It added three sessions and approximately 70,000 tokens. Those sessions are in the totals above. Without Phase 2, the project finishes at roughly 110,000 tokens and $0.40.

What This Actually Means

Solo AI orgs are not new. The tools and patterns for running named agents with defined roles have been documented. What has not been documented is the cost-discipline layer: a mandatory pre-build estimate, a human go/no-go gate, model tier routing as a cost decision, and a receipt that proves the prediction worked.

This is not a cost-cutting exercise. It is a governance story.

The agents on this build were not generic Claude Code sessions opened on a whim. The Sr Mobile Architect reviewed the PRD for architecture fit. The Sr PSE pressure-tested the security methodology. Both operate under scoped roles with defined responsibilities and a standing SOP that governs what each agent produces and how output flows through the org. At the close of each session, key decisions were written to a knowledge base that persists across sessions and projects. The agents do not start cold.

The go/no-go gate is the part that matters most. The budget gets written. I review it. I say go. That human checkpoint sits above everything the agent layer does. No approval, no build.

None of this is an enterprise compliance framework. It is one practitioner, a defined org, a standing process, and a receipt that proves it works. The four-tier system, the spec injection rule, the written budget, the agent roles: these are not independent optimizations. They are components of the same thing. A process that produces reliable output, run consistently, at a cost that makes sense.

The OBF Analyzer is the proof of concept. $0.68 is the receipt. The budget was predictable because the decisions were made before development started. That is the lesson, and it applies beyond this project.