Use | OpusAI

The operating model

OpusAI is not simply a two-pane chatbot. Its core workflow separates planning, implementation, validation and review:

USER
  ↓
ARCHITECT PLAN
  ↓
CODER IMPLEMENT
  ↓
CONTROLLER TEST
  ↓
ARCHITECT REVIEW
  ↓
CODER FIX (when required)
  ↓
RETEST
  ↓
FINAL REVIEW
  ↓
FINAL OUTPUT

1. Select the Architect and Coder models

The main interface exposes separate Ollama model selectors. You can use different local models for each role or assign the same model to both roles. The distinction is functional: the Architect is responsible for planning/reviewer behavior, while the Coder is responsible for implementation and corrections.

2. Configure runtime budgets

The Settings interface exposes separate CPU thread controls for Architect and Coder, separate output-token budgets for planning and implementation, and shared context size, temperature and Ollama keep-alive settings.

Setting	Purpose
Architect CPU threads	Controls the explicit CPU thread budget for Architect requests. Auto is supported.
Coder CPU threads	Controls the explicit CPU thread budget for Coder requests. Auto is supported.
Architect output tokens	Planning/review output budget.
Coder output tokens	Larger implementation output budget intended for code generation.
Shared context	Context window used by the roles.
Shared temperature	Sampling temperature for the local requests.
Keep-alive	Controls Ollama model residency behavior.

3. Submit the development request

The human user remains the final authority. Give OpusAI the actual implementation requirement, including platform, language, framework, behavior and constraints that matter to the result. The Architect should turn that into compact implementation direction rather than inventing unrelated scope.

4. Follow the collaboration transcript

The shared transcript exposes the interaction between the roles. This is useful for inspecting the plan, implementation, validation feedback and review sequence instead of receiving an opaque final response.

5. Let the controller test the result

Controller-side validation is intentionally outside the language-model judgment loop. Current source behavior includes completion checks, Python compile validation and PySide6 offscreen runtime smoke testing. Controller test results are treated as ground truth by the agent instructions.

Important: a Coder response is not automatically a successful final result. If controller tests fail, the implementation cannot receive a pass.

6. Correction and review

When validation fails, OpusAI can return concrete controller failures to the implementation loop. The Coder is instructed to fix those failures before optional refactoring. The Architect then reviews against the user request and controller evidence.

7. Use Final Output

Successful final output appears in the dedicated Final Output area after the test and review conditions are satisfied. From there you can use Copy or Save As....

Manual agent controls

The current application also exposes Ask Architect and Ask Coder controls. These are useful when you need direct role-specific interaction instead of immediately driving the complete automated development sequence.

PerformanceLab import

OpusAI can read the integrated PerformanceLab configuration and import selected profile values. Current source behavior can bring in CPU-thread information and can offer to apply the PerformanceLab model to the Coder, Architect, or both. Benchmark output-token length is deliberately not imported because a benchmark generation length is not the same thing as an implementation budget.

Window and tray behavior

Closing the main window with the window X hides OpusAI to the system tray rather than immediately terminating the suite. The tray menu provides access to show the application again, About, and Quit.

Using OpusAI