At Cale Media, we see a groundbreaking direction for personal AI: a computer that becomes an active workshop for your ideas. Describe a useful tool. Work through a document. Create music. Build an interactive experience. Keep the project, its files, and its progress in a workspace you can return to.

Workbench is an open-source Windows application that connects local models with persistent tasks and practical tools. It also brings together local feedback learning, SQLite project memory, and optional automated specialist-model training. Its ambition is to make advanced AI workflows accessible through an everyday desktop experience, with offline operation as a core capability and optional cloud choices when wanted. Once the necessary models and tools are installed, the app can run its local task workflows without an internet connection.

The most exciting part is already tangible. Recorded local 9B-model runs have built an interactive calculator, repaired Python logic, completed saved task steps, and produced checks that caught deliberately introduced defects. These are bounded demonstrations, but they establish a real foundation for the next stage.

The model does not have to do everything in its own response. A CSV parser can handle rows precisely. A browser can execute an interface. A database can preserve completed steps. A verifier can test a result again. The model chooses and coordinates actions; the surrounding software performs operations and returns evidence.

This division of work is the opportunity. Instead of repeatedly asking a model to remember a whole project and judge its own answer, Workbench gives the task a persistent structure. Progress can survive a worker restart, source files remain available, and later checks can challenge an earlier result.

Local inference also creates a different relationship with the technology. Model processing can run on hardware under the user’s control, without a paid cloud inference call for each local step. That is not zero-cost computing: hardware, electricity, storage, and setup still matter. It is a route toward more personal control over where the work happens.

Offline by capability. Private by choice.

Local models are about more than model size: they let Workbench run offline and carry out tasks on the computer itself. With the required models, tools, and project files installed locally, a task can move from instructions to execution, saved output, and verification without a cloud inference service.

That gives privacy a strong foundation. In a fully local, offline workflow, prompts, working files, and results can stay on the device. Users control the machine doing the work and can choose when to connect to an outside service. Privacy still depends on the tools and settings in use; enabling a cloud provider or an online integration changes where data may go.

Offline work means using resources already on the device. Live web research, publishing to a website, fetching new models, and other actions that reach online services need a connection. The distinction is straightforward: local work can continue offline; network tasks require the network.

A working interactive application

A fresh local 9B run built an offline tip-splitting calculator in 304.72 seconds and completed all five saved task units. The grader confirmed calculations, invalid input handling, blank bills, fractional people, and mobile fit. Its saved verifier passed the correct app and rejected deliberately broken JavaScript and targeted behavior regressions.

No verifier was supplied for this run. The result therefore includes both the application and useful verification coverage produced through the workflow. It demonstrates a complete pass for this small app fixture. Inspect the app evidence ↗

Business logic that survived deliberate defects

A local 9B shipping-calculation repair completed in 203.05 seconds, with both saved task units finished. All 11 independent behavior cases passed, covering pricing zones, fractional weights, defaults, and invalid inputs. The saved verifier also rejected all four deliberately defective implementations.

The same report records a temperature-conversion repair completing in 72.65 seconds, passing four reference cases and rejecting the original regression. Neither of these runs began with a supplied verifier. Inspect the Python evidence ↗

Small steps that stayed connected to the goal

A separate trial explicitly identifies Qwen 3.5 9B. It repaired a small Python function and completed two SQLite task units in 50.85 seconds. A known verifier was supplied for this experiment; the worker preserved it, passed the corrected function, and rejected the original bug. This isolates evidence for repair and task coordination, rather than claiming autonomous test creation. Inspect the task-step evidence ↗

Local document work with a source-bound check

A separate automatic-local run summarized a two-page PDF in 106.87 seconds. It used the final terms instead of the superseded draft, calculated the net amount correctly, and produced a verifier that rejected both an incorrect total and a changed source. This is additional local-workflow evidence; its routed model aliases do not establish that it was a small-model-only run. Inspect the document evidence ↗

A real specialist-training experiment—with a quality gate

The November 4, 2026 training receipt records a CPU worker producing and evaluating a compact classifier in about 2.93 seconds. Its accuracy was 61.35%, below the 75.19% baseline that always predicted “out of scope,” so it failed screening. The candidate stayed local and inactive, with no upload.

This establishes that the training, evaluation, and rejection path ran. It does not establish an improvement to the assistant or a qualified routing model. Inspect the actual training receipt ↗

We also retain the failures. Earlier calculator runs missed test coverage, and larger expense-app and game trials did not complete successfully. Those gaps identify the next engineering work: stronger requirement coverage, more dependable planning, and repeatable completion as projects grow. Read the full benchmark record ↗

A passing test proves the behavior it covers. It cannot supply a requirement the model overlooked. That is why the benchmark work challenges verifiers with broken outputs, and why broader coverage remains a development priority. Explore the architecture ↗

Automatic training for small specialist models

With a separate opt-in, Workbench can schedule CPU training experiments for compact intent classifiers: models that learn to sort requests into defined categories. The current process uses reviewed public CLINC data, trains a local model, evaluates held-out examples, and records the result. Its TF-IDF and logistic-regression approach is established machine learning, packaged into an automated experiment workflow.

This classifier workflow does not retrain the main 9B assistant. A benchmark score alone does not make a candidate eligible to direct Workbench tasks. Read the training design ↗

Learning from your feedback

Explicit reviews are saved locally and matched to relevant later tasks using text similarity. This gives Workbench a way to retrieve lessons about what the user wanted. It is learning through remembered examples; the feedback store does not change the language model’s weights or upload those examples. Inspect local feedback learning ↗

SQLite: memory that survives the conversation

SQLite is the embedded database behind project memory, saved task steps, and execution checkpoints. Workbench can retain requirements, decisions, lessons, and searchable project material, then give a worker a focused briefing when it resumes. A separate experiment ledger records training conditions and outcomes, helping avoid repeating completed experiments after a restart.

For a small model, that structure matters: the software preserves state outside its limited conversational context. SQLite supplies storage and search; training changes a specialist model’s fitted parameters; feedback retrieval brings relevant past examples into new work. These are complementary capabilities. Explore the memory and experiment architecture ↗

The current automated public-data training process excludes private prompts and files. Acquiring datasets or submitting an optional contribution requires a connection; local training can use the verified dataset cache once the required runtime and data are installed.

Workbench already documents a wider toolset around that foundation: local image and music generation, speech, audio and video editing, document extraction, small-model training, and public-source research. Recent release notes include a four-deck DJ controller and local webcam tracking. The AI Print Farm workspace also brings connected-printer status, temperatures, camera views, AI bed-inspection annotations, and automatic-printing controls into the same application. The interface capture above shows four printers online; completed unattended production is not established by that screenshot. These are product capabilities with their own hardware and runtime requirements; they are not all established by the 9B coding benchmarks.

The exciting connection is that these tools live alongside ongoing projects. A task can have a brief, intermediate files, a finished artifact, and a path for further work. The long-term opportunity is a workspace where creation feels continuous, from the first idea through revisions.

Offline operation is a core part of the local workflow: the app can keep working with installed models, local tools, and files without an internet connection. Downloads, live web research, updates, and enabled cloud services use the network. An agent with terminal access can modify files with the Windows user’s permissions, so project selection and backups matter. Users should inspect important outputs before relying on them.

The roadmap below proposes the next development priorities from the evidence available today. It describes direction and success criteria, not announced delivery dates or guaranteed features.

If you find a repeatable success, document the conditions. If you find a failure, make it reproducible. Both help turn a promising technology into a better workbench.

Our direction is clear: make small local models more useful through better engineering around them, and show the work. The demonstrations already exist. The roadmap is about widening what they make possible.

The Cale companion source is MIT licensed; third-party runtimes and model weights retain their own licenses. Demonstrated outcomes are specific to the recorded tasks. Proposed roadmap items are future work.