Artificial intelligence / Software & Backend
An alpha assistant combining Ollama and optional MLX models with rule-based routing, memory, tool experiments, voice and a React/Three.js interface.
Original code-generated category illustration; not a product screenshot.
J.A.R.V.I.S brings several model and interface components into one assistant prototype. Its Python package includes routing and orchestration, Redis/ChromaDB/SQLite memory, and tool and voice modules. A React/Three.js visual client accompanies the FastAPI backend. The MLX path requires supported Apple hardware. This repository is separate from jarvis-core and its deterministic policy-centered runtime.
An assistant needs to handle short conversations, deeper analysis, tool use and user context within a coherent flow. Coupling every task to one model or module can mix hardware requirements with service failures. Adding memory, voice and powerful tools also makes data boundaries and execution limits more important. A modular prototype provides a place to explore these concerns without treating every integration as production-ready.
Development of assistant orchestration, model adapters, memory and visual interface components.
A rule-based router selects fast/deep flows from message length, keywords and complexity. Ollama and optional MLX adapters abstract model access, while orchestration connects memory and tool modules. Redis, ChromaDB and SQLite serve distinct memory concerns. FastAPI supports a React/Three.js client; voice and separate device clients remain experimental layers. Setup has explicit requirements for model services and platform-specific extras rather than assuming every dependency runs on every device.
Router evaluates Turkish/English deep-task keywords, message length and sentence count to select a fast or deep lane. Its decision includes a human-readable reason, and Orchestrator maps the lane to the selected model client. The code therefore exposes why a message took a heavier path. This avoids running a separate learned classifier for the choice, but does not establish semantic routing accuracy or a measured improvement in latency or cost.
For each request, Orchestrator assembles a system message, session history and the new user message. If short-term memory is absent or fails to read, it can continue stateless with empty history; after responding it attempts to store the user/assistant turn. Write failures are logged without canceling an already generated response. This defines behavior when memory is unavailable, while accepting possible conversational context loss. It is not a uniform continuity guarantee across every memory component.
The SQLite profile component stores key/value records; values written with encryption enabled use AES-GCM and are decrypted on reads. Schema and key names remain visible, and unencrypted records are also supported. Profile encryption therefore cannot be generalized to the entire database, logs, Chroma indexes or voice files. This distinction makes storage boundaries explicit during development. Key changes introduce availability and migration concerns; existing content is not assumed to be automatically re-encrypted.
React / Three.js client → FastAPI
Rule-based router → fast / deep flow
Ollama / optional MLX adapters
Orchestration → memory / tool / voice modules
Redis / ChromaDB / SQLite → context and response
Conceptual flow derived from project descriptions; not an application screenshot.
The technical account also draws on documentation in the open improvement PR. This does not imply that the PR has been merged or the product released.
A compact language-model study exposing Transformer internals through a custom BPE tokenizer, PyTorch components and local Apple Silicon training experiments.
A local-first agent core separating LLM proposals from deterministic risk policy, approval state and tool execution, with optional Apple integrations.