Elitza
The AI Enablement operator. Scout local clients, qualify them in a CRM, run the outreach cadence, and deliver implementation sprints from your terminal. Everything runs on your machine. Nothing sends without your approval.
By Dario Cositore · Last updated November 2026
What Elitza Is
Elitza is a local agentic operator for selling and delivering AI enablement work to local businesses. You give her a town and a trade. She scouts the businesses, scores them, writes the first touch for your approval, runs the four-touch cadence, and once a client says yes, drives the job through proposal, call, payment and handover. She does the scoping paperwork you would otherwise do by hand.
Elitza is a fork of the OpenCode terminal agent, rebranded and reworked end to end for one job: operating an AI enablement practice. New brain plugin, new CRM and outreach engine, new identity system, new defaults, new installer and a rebuilt command surface. The software is MIT licensed and costs nothing. Inference runs on your own Xiaomi MiMo key.
Elitza AI is available as elitza-code on GitHub and as a one-line install from elitza.life. The repo is public, MIT licensed, and built with Bun and TypeScript. Clone it, run bun install, and you are in the codebase.
The product thesis is simple: a personal AI agent should feel like a reliable desktop utility, not a weekend of terminal archaeology. Elitza keeps the installation path calm, visible, and repairable. Everything runs locally. Keys, config, sessions, memory and client records stay under ~/.elitza. There is no analytics or telemetry client in the tree.
Core Product Layers
Setup Wizard
Guides the user through profile creation, provider setup, engine installation, local gateway checks, and final readiness without pretending unfinished steps are complete. First boot opens a popup wizard that walks you through the MiMo account (invite code HFSR94, 10% off the first paid Token Plan order), the endpoint for your region, and your key. Masked as you type, stored mode 600, never echoed.
Provider Setup
Helps users configure their own model provider keys safely. Secrets are written to local configuration paths and are never displayed back in the interface. No provider sprawl, no fallback to debug, no key sprawl to manage.
Agent Engine
Installs and launches the local runtime in user space, then checks whether the gateway, profile files, and command-line tools are reachable. Everything runs locally. The only outbound traffic is to the model provider you configured, Places searches you run, Resend posts you approved, and release metadata.
Diagnostics and Repair
Surfaces gateway, service, provider, and workspace problems in plain language. Advanced repair paths explain exactly what will happen before anything sensitive runs. No fake green: if a probe fails, the UI says exactly what is known and what is unverified.
Native Channel Guidance
Guides Telegram and WhatsApp setup through native channels instead of rebuilding fragile custom messaging protocols.
Playbooks
Curated knowledge covering diagnosis, proposal, workbook library, call script, payment terms and handover. Seeded on load, never overwriting your edits, registered as skills so she pulls the right one in herself. Your own markdown files dropped in the procedural folder join the library.
Technical Architecture
System Design
Elitza is a terminal-first agentic operator. Three clients (terminal, browser, desktop) talk to one server. The server owns sessions, tools, providers and configuration. Plugins hang off the same host. The brain plugin adds the CRM house, memory system, identity and 26 tools.
Installer Architecture
- Runtime: Bun 1.4+, TypeScript. Installs via curl -fsSL https://elitza.life/install.sh | bash
- Default install mode: user-space install under ~/.elitza/agent, no sudo by default.
- Gateway: local loopback service on a high port, with diagnostics that do not fake success.
- Profiles: local agent profile files generated from user preferences.
- Packaging path: Linux x64/arm64 and Darwin x64/arm64 prebuilt binaries. Windows installer in progress.
- Storage: SQLite for memory (soul_v2.db) and CRM (crm.db), both under ~/.elitza/brain/.
Why Elitza Exists
Power users can tolerate broken setup instructions, mystery config files, and CLI repair rituals. Most people cannot. That is the gap Elitza targets: the trust layer between a powerful local agent and a user who just wants their computer to become more capable.
Elitza does not try to hide complexity. It makes it approachable by wrapping the operational surface area: installation, credentials, profile files, native channel setup, diagnostics, and recovery. Every step is visible, every failure is explained, and nothing is faked.
Design Principles
- No fake green: if a probe fails, the UI says exactly what is known and what is unverified.
- No silent escalation: Elitza should not require root access for the normal install path.
- No secret leakage: provider keys are handled locally and never rendered back to the user.
- No protocol cosplay: native Telegram and WhatsApp setup uses the agent's own channels instead of brittle custom clones.
- Nothing sends without you: every message is a file first. Only drafts you approve in a batch can be sent.
- Data stays local: keys, config, sessions, memory and CRM live under ~/.elitza. No analytics or telemetry client in the tree.
Current Status
Elitza is in public beta. The setup path is testable and honest: system check, runtime detection, profile source generation, provider setup, gateway diagnostics, diagnostics export, and release readiness checks. The installer downloads a prebuilt binary plus the brain plugin, installs them at ~/.elitza/agent, writes the elitza launcher into ~/.local/bin and seeds your config, SOUL.md and personas. It is safe to re-run.
Production blockers remain explicit: signed installers, native installers for Windows, production auto-update, restore flows, and provider probe verification across runtime versions. Linux x64/arm64 and Darwin x64/arm64 prebuilt binaries are available today. Windows is next.
Real Capabilities
Elitza currently focuses on the installer and control surface around the local agent:
- Setup wizard: guides the user through profile creation, provider setup, runtime installation, local gateway checks, and final readiness without pretending unfinished steps are complete.
- Agent profile generation: creates local profile source files for identity, preferences, boundaries, tools, and routines.
- Provider setup: writes provider configuration locally while avoiding secret exposure in the UI. Keys are stored mode 600 and never echoed.
- Gateway diagnostics: checks whether the local gateway appears active and explains blocked probes without pretending they passed. No fake green.
- Redacted export: creates bounded diagnostic bundles that can be shared without dumping private keys.
- CRM house: a zero-build dashboard on 127.0.0.1:8787 with a pipeline board, approval queue, scout screen, and client records with clickable contact details.
- Memory system: 4 typed memory stores (episodic, semantic, procedural, emotional) with importance scoring, decay, and consolidation.
- Outreach cadence: 4-touch outreach (+3, +7, +14 days) with batch approval. Every message is a file first. Nothing sends without you.
The long-term goal is bigger than setup: every serious operator should have a personal AI agent that follows them across contexts and massively increases what they can execute alone. Elitza is the trust layer that makes that possible.
How it works under the hood
Frequently asked
Do I need to be technical to use it?
No. The wizard guides you through profile creation, provider setup and gateway checks. Advanced repair paths exist for power users, but the default path is calm and visible.
Are my API keys safe?
Yes. Keys are written to local configuration paths and are never displayed back in the interface. Nothing leaves your machine. Provider keys are stored mode 600 and never echoed.
What is the current status?
Public beta candidate. Linux and source installs work today. Windows installer and signed production builds are in progress.
Related projects
The AI Enablement loop
Every step is a tool she calls. Exactly one step reaches a human being, and it only goes out after you approve the batch.
| Scout | Location + query into name, address, phone, website, rating, category. | client_scout |
| Qualify | Score 0-100, dedupe, find a public email on their own site, enrich from their own website. | crm, enrich_client |
| First touch | A draft file with the opt-out footer, waiting for your read. | outreach draft |
| Approve, send | Batch approval, then Resend posts it. Stage, last_contact and next touch are set. | outreach approve, outreach send |
| Cadence | +3, +7, +14 days. The heartbeat drafts each follow-up in the same thread. You approve again. | outreach due, outreach queue |
| Disposition | Yes goes to production. No or silence goes to the stale list for nurture. | outreach dispose, outreach sweep |
| Production | Diagnose, proposal, workbook, scheduled, payment, done. | production |
| Handover | CLIENT_SOP_HANDOVER.md written from git evidence and live gates. | handover |
Playbooks for all of it (diagnosis, proposal, workbook library, call script, payment terms, handover) ship as skills she pulls in on her own.
Highlights
- MiMo only, set up for you. First boot opens a setup wizard that walks you through the MiMo account (invite code HFSR94, 10% off the first paid Token Plan order), the endpoint for your region, and your key. Masked as you type, stored mode 600, never echoed. No provider sprawl.
- A CRM that is just a database. Clients, interactions and assets live in ~/.elitza/brain/crm.db with a shared status lifecycle from scouted to done. It never enters the memory index. Query it with crm search, patch it with crm update.
- A CRM house in the browser. The same records as a page: elitza serve starts a zero-build dashboard on 127.0.0.1:8787 with a pipeline board, approval queue, scout screen, and client detail where every contact field is a real link. Enrich scrapes their own site before running diagnosis and proposal.
- Nothing sends without you. Every message is a file under ~/.elitza/pipeline/ first. Only drafts you approve in a batch can be sent. An unapproved row is refused with a reason. The compliance footer is written in before you review.
- A memory that compounds. Memories are typed (episodic, semantic, procedural, emotional), scored for importance, decayed over time and consolidated when they prove useful. Personas, roles and hooks are plain directories of JSON and markdown.
- She tidies up on her own. A heartbeat runs between conversations: consolidates and prunes memory, polls the gapfeed radar into draft files, drafts due follow-ups, closes silent cadences. During a long silence she writes a reflection waiting in the next session's prompt.
- Real tools, real permissions. 26 tools exposed to the model: brain memory set, doctor repair, gapfeed queries, and the operator set (client_scout, crm, enrich_client, outreach, production, playbook, handover, task). Every shell command and file write can be gated by the permission policy you configure.
- More than a terminal. elitza serve starts the same API behind a browser UI. elitza pair prints one-time links to connect a browser or phone. An Electron desktop shell renders the same app. The brain plugin adds the CRM house to that same server.
The brain
The brain plugin gives Elitza a persistent self:
- Memory: SQLite at ~/.elitza/brain/soul_v2.db. Episodic (episodes, 1000 max), semantic (facts, 500), procedural (skills, 200) and emotional (300) memories, plus a full text index, recall log and session log. Memories carry importance and valence, decay on a schedule, and consolidate when they cross the threshold.
- CRM: SQLite at ~/.elitza/brain/crm.db: clients, client_interactions, client_assets and the pipeline table with cadence state. Deliberately a separate file so client data stays out of the memory index and can be backed up or wiped on its own.
- Identity: ~/.elitza/SOUL.md is her core personality in plain markdown. ~/.elitza/PERSONA.md is what guided setup wrote about your answers. Edit either and she changes.
- Personas, roles and hooks: directories of JSON and markdown under ~/.elitza for who she is talking to, how she should behave, and what she should do on an event.
- Playbooks: curated knowledge in ~/.elitza/brain/procedural/ covering diagnosis, proposal, workbook library, call script, payment terms and handover. Seeded on load, never overwriting your edits, registered as skills so she pulls the right one in herself.
- 26 tools: brain memory set, doctor check/repair/history, gapfeed query/build pipeline, and the operator set (client_scout, crm, enrich_client, outreach, production, playbook, handover, task).
Full reference: docs/reference/brain.md in the elitza-code repo.
Architecture
Three clients (terminal, browser, desktop) talk to one server. The server owns sessions, tools, providers and configuration. Plugins hang off the same host. The brain plugin adds the CRM house, memory system, identity and 26 tools.
Elitza is a fork of OpenCode, rebranded and reworked end to end for one job: operating an AI enablement practice. New brain plugin, new CRM and outreach engine, new identity system, new defaults, new installer and a rebuilt command surface. Upstream credit stays in the license.
Frequently asked
Do I have to live in the terminal?
No. elitza serve or elitza service start runs everything in the background and opens the CRM house in your browser: the pipeline board, the approval queue, the scout screen and every client record with clickable contact details. The CLI is the power surface and stays optional until you want it.
What does it cost?
The software is MIT licensed and costs nothing. Inference runs on your own Xiaomi MiMo key. The guided setup signs you up through invite code HFSR94, which takes 10% off your first paid Token Plan order. Google Places and Resend also run on your own keys.
Where does my data go?
Nowhere but your machine. Keys, config, sessions, memory and the CRM live under ~/.elitza. The only outbound connections are the model provider you configured, Places searches you run, Resend posts you approved, and release metadata.
Will it email people without me?
No. Every message is a file under ~/.elitza/pipeline/ first. Only drafts you approve in a batch can be sent. An unapproved row is refused with a reason. The compliance footer is written in before you review.
What is Elitza built on?
Elitza is a fork of OpenCode, rebranded and reworked end to end for one job: operating an AI enablement practice. New brain plugin, new CRM and outreach engine, new identity system, new defaults, new installer and a rebuilt command surface.
Can I use it with my own models?
The guided setup deliberately wires one provider, Xiaomi MiMo, so there is no fallback to debug and no key sprawl to manage. Underneath, the engine reads a standard OpenAI-compatible provider block. Elitza supports MiMo only, and that is the product decision.
Related projects
Follow the Beta
Elitza is moving from local beta candidate toward packaged installers and a clearer public onboarding path.
Visit Elitza →Stay in the loop.
Technical breakdowns, new system builds, and lessons from deploying autonomous AI. One email a week, direct to your inbox.
One email a week. Leave with one click.