Local AI Development & Performance Laboratory
A controlled local environment for building with AI, separating model responsibilities, testing generated implementations outside the models themselves, measuring inference behavior, and deciding what survives the forge.
Crucible is designed around a simple principle: a language model should not be allowed to plan the work, write the implementation, judge its own result, and declare victory without independent evidence. The system separates those responsibilities into distinct stages so the human operator can observe the work, test it, reject it, repair it, and promote only the result that survives the process.
Architect and Coder models operate as separate local roles. A controller sits outside those roles and performs executable validation. PerformanceLab measures the local models and machine so runtime settings can be informed by actual inference behavior rather than hardware folklore.
Every development cycle moves through a defined chain. The models can propose, implement, inspect, and repair. The controller supplies external evidence. The human remains in command.
A dedicated local model converts the operator's request into implementation direction, then returns later as a reviewer. Planning and review are separated from the model doing the implementation work.
A separate local model performs implementation and correction passes. Its thread budget and output-token budget can be tuned independently from the Architect so each role can be matched to the model and hardware actually running it.
Controller-side checks operate outside the language models. Completion checks, Python compilation, and PySide6 offscreen runtime smoke testing can expose failures that polished model prose would otherwise conceal.
Benchmark local inference, compare cold and warm behavior, repeat measured runs, retain history, and use observed model performance to inform Crucible runtime configuration.
Crucible keeps the collaboration process separate from the deliverable. Planning discussion, implementation attempts, test failures, repair instructions, and reviewer commentary remain part of the working record. The dedicated Final Output area is reserved for the result that has made it through the controller and review sequence.
Once promoted, the result can be copied or saved with Save As instead of requiring the operator to excavate finished code from a conversation log.
Crucible is built around local Ollama model execution. Architect and Coder models are selected from the local environment, with role-specific CPU thread budgets and output-token budgets alongside shared context size, temperature, and Ollama keep-alive controls.
The goal is not to hide the machinery behind a generic chat box. Crucible exposes enough of the machinery to let the operator tune, observe, compare, and deliberately shape the local development environment.
PerformanceLab is integrated with Crucible to test actual local inference behavior. Benchmarks can record configuration, cold and warm model behavior, repeated measured runs, system state, history, and generated reports. Selected profile values can then be brought back into Crucible runtime settings.
That closes the loop between development and measurement: choose a model, observe how it behaves on the machine, adjust the environment, repeat the test, and keep the evidence.
The laboratory exists to examine the full local development chain: planning quality, implementation behavior, correction ability, controller pass/fail evidence, model-specific performance, resource use, and the practical relationship between two different AI roles working under human direction.
Compare models by task instead of assuming the same model is best at architecture, implementation, review, and repair.
Force generated work to encounter compilation and runtime checks before the development loop treats it as finished.
Use measured local behavior to tune threads, token budgets, context, and model selection for the workstation actually doing the work.
Crucible is human-directed. The system structures model collaboration and validation, but the operator chooses the task, the models, the configuration, whether a failed result receives another repair pass, and whether the final result is acceptable.
Crucible treats local AI development as an engineering process that can be inspected and measured. The interface is not meant to pretend the underlying system is magic. It is a forge, a test chamber, and a workbench for discovering what local models can actually do when they are given distinct responsibilities and held against executable evidence.
Start with installation, configure the local models, benchmark the environment, and send the first development task through the chamber.
