The original problem
OpusAI began with a deliberately simple idea: stop asking one local model to perform every development responsibility at once. Split the work into an Architect role and a Coder role, keep the user in authority, and make the handoff visible.
Early workflow
The initial application established separate local Ollama model selectors and a shared collaboration transcript. That provided the basic USER → ARCHITECT → CODER structure, but the important next question was whether the generated implementation actually worked.
Controller validation
The workflow expanded into controller-side completion checks, Python compile validation and PySide6 offscreen runtime smoke testing. This changed the role of review: model confidence was no longer enough. A failed controller result prevented a pass and could drive a concrete correction cycle.
Verified Final Output
OpusAI added a dedicated Final Output area to separate collaboration chatter from a deliverable that had survived validation and review. Copy and Save As controls made that verified result immediately reusable outside the application.
PerformanceLab becomes part of the suite
OpusAI 1.1 integrated PerformanceLab 1.0.3 directly into the main Qt process. PerformanceLab itself had been developed as a working baseline for controlled local Ollama benchmarking, including system scans, cold and warm phases, repeated measured runs, configuration persistence, report generation, history, comparisons and CPU-governor controls.
The integration namespaced PerformanceLab state under the OpusAI working directory so the primary application could later consume benchmark configuration and history without duplicating storage.
PerformanceLab 1.0.3 baseline
The 1.0.3 cycle established canonical llama3 and qwen3-coder benchmark reports and introduced full benchmark-session timing. It also documented an important analytical limitation: recommendations were based on post-benchmark system state, so benchmark-generated CPU load could be mistaken for unrelated background load.
OpusAI 1.2 source direction
The current source identifies the main application as OpusAI 1.2. The runtime/settings layer has grown to include role-specific CPU thread controls, role-specific output-token budgets, shared context and temperature, configuration import/export/reset behavior, and direct import from PerformanceLab profiles.
The source package also includes a PerformanceLab report visualizer that reads active benchmark text reports, filters by model, graphs selected metrics over time and exports graphs. That moves the suite from merely retaining benchmark history toward actively interpreting it.
Current philosophy
Three ideas now define the project:
- Separate responsibilities: planning/review and implementation are distinct jobs.
- Validate outside the model: executable controller evidence matters more than an AI declaring success.
- Measure the actual machine: local model tuning should be based on repeatable benchmark evidence, not assumptions.
Where the project can go next
The PerformanceLab documentation already defines a future direction for baseline pinning, graphing, stronger statistical analysis, benchmark matrices, experiment organization, confidence measures and explicit pre/post resource deltas. The 1.2 report visualizer begins the graphing side of that direction while preserving the underlying baseline methodology.