The setting that motivated Orbis is specific: a teacher preparing tomorrow's lesson on a school computer, and a student or researcher who needs to inspect sources and data without assuming a constant connection. A cloud chatbot does not solve either job reliably. It can fail on network access, overlook the Tanzanian curriculum, or lose the provenance of a research answer. Orbis groups two local workspaces around those different kinds of work rather than pretending one interface serves both.
Kairos is the teacher-facing workspace. It runs a compatible local model through llama.cpp or a configured Ollama endpoint and prepares lesson plans, exams, marking support and reports in TIE and NECTA formats. Prompts encode the expected objectives, marking conventions, language choice and classroom constraints. Generated work remains editable; a teacher still owns the educational judgment and the final material. The repository lists a 4 GB RAM minimum and initial installation requirements, so “offline” describes operation with the model present, not an installation that needs no preparation.
One Kairos development issue illustrates the unglamorous work needed for that promise. Streaming AI events originally reached pages that had not requested them, allowing lesson output to appear during exam generation. The application now carries feature context with stream events so lesson, exam and report screens handle only their own work. Settings are loaded before the model service starts, including the selected provider and GPU layers; changing these affects the local runtime rather than just a visual control.
Weave addresses a different continuity problem#
Weave serves a longer research workflow: source retrieval, datasets, Python analysis and a persistent task record. Its recent work replaced a loose post-generation repair step with a plan ledger that records dependencies, acceptance checks and evidence for completed steps. CSV, JSON, Excel and Parquet now pass through a shared parsing path, with sampling and truncation stated in the result rather than hidden.
Weave is bilingual at the stored-message level and keeps projects, chats, datasets and memory. Its retrieval path combines vector and keyword search over a source library, while analysis runs Python against a read-only dataset copy in a no-network sandbox. A separate developer workspace may persist files and run commands. That separation is intentional: a bounded analysis sandbox and an editable project workspace have different risk and lifetime requirements. A substantial task uses a durable plan ledger; a simple question does not need that machinery.
Weave's Docker default now starts Postgres and Redis because the earlier one-command SQLite default was quietly wrong for a class. SQLite serializes writers; per-process rate limits multiply when workers are added. The development-only SQLite path remains an explicit option for a small local setup. That is a deployment lesson as much as a database choice: a configuration that boots easily can still fail under the ordinary concurrency of the setting it claims to serve.
Local operation is meaningful in both products, but Kairos needs a compatible installed model and Weave's optional external providers and online tools need connectivity.
The immediate next evidence differs too. Kairos needs classroom review of generated material and marking behavior against actual teaching expectations. Weave's roadmap calls for task-completion sessions with Kiswahili-speaking students and researchers, and production fault drills for its multi-worker services. Local feature coverage is not a substitute for those observations.
The Orbis system record shows the two workspaces together.