GreenCube

A personal AI assistant that runs entirely on your own computer.

GreenCube is like having a smart helper that lives inside your laptop instead of
on someone else's servers. You can talk to it, and it can actually do things for
you — make and edit files, organize documents, browse the web, and connect to apps
you already use like Gmail, Google Calendar, GitHub, Notion, Slack, and Dropbox.

The difference from every other AI assistant: nothing leaves your machine. The
model runs locally, your data stays with you, it works offline, and there's no
monthly subscription. You buy it once and it's yours.

This repository is private. Our public marketing lives at
greencube.app. This README is for collaborators — it's
meant to help you understand and work on the code, not to sell anything.

Philosophy

Every other AI assistant is rented. This one is yours.

The big AI products are something you rent forever: you pay every month, your
conversations live on their servers, and the company learns everything about you to
make money. The moment you stop paying, you lose it all. And it never really
belonged to you in the first place.

GreenCube is built on the opposite belief: people should own their tools, not rent
them. A tool should serve the person using it, fully under their control. So we
made an assistant that:

• Runs locally. The AI model lives on your computer and does its thinking there.
• Is fully private. Your data never leaves your machine. No cloud, no harvesting.
• Works offline. No internet required for the core assistant.
• Is owned, not rented. One-time purchase. No subscription, ever.

Everything we build is measured against that idea. If a feature would mean sending
your private data somewhere or locking you into a recurring bill, it doesn't fit.

Tech stack

Versions below are taken straight from the project files, not guessed.

GPU acceleration (Vulkan) is an optional compile-time feature. The default build
is CPU-only so it compiles cleanly on any machine; shipped installers are built with
Vulkan turned on in CI, and the app detects the right path at runtime. See
Build modes below.

Project structure

A short map so a new collaborator can find their way around fast.

greencube/
├── src/                         # Frontend — React + TypeScript
│   ├── App.tsx                  # Root component / app state
│   ├── main.tsx                 # Entry point
│   ├── types.ts                 # Shared TS types
│   ├── components/              # UI screens & widgets
│   │   ├── MainArea.tsx         #   main chat / work area
│   │   ├── Sidebar.tsx          #   conversation list & nav
│   │   ├── SetupScreen.tsx      #   first-run setup
│   │   ├── WizardScreen.tsx     #   guided onboarding wizard
│   │   ├── SplashScreen.tsx     #   loading splash
│   │   ├── MemoryVaultTab.tsx   #   the assistant's memory UI
│   │   └── ...                  #   dialogs, licenses, etc.
│   ├── lib/                     # Frontend helpers
│   └── styles/                  # Tailwind + design tokens
│
├── src-tauri/                   # Backend — Rust (the engine)
│   ├── src/
│   │   ├── commands.rs          #   Tauri command surface (what the UI can call)
│   │   ├── inference.rs         #   local model inference loop
│   │   ├── models.rs            #   model catalog / download / load
│   │   ├── agent*.rs            #   agent loop, KV-cache, UIA agent variants
│   │   ├── browser.rs           #   web browsing
│   │   ├── vision.rs            #   screenshot understanding
│   │   ├── uia.rs / input.rs    #   reads/controls the desktop (UI Automation, input)
│   │   ├── capture.rs           #   screen capture
│   │   ├── hardware.rs          #   GPU/VRAM detection
│   │   ├── db.rs                #   SQLite storage
│   │   └── ...
│   ├── capabilities/            # Tauri permission config
│   ├── icons/                   # App icons
│   ├── Cargo.toml               # Rust dependencies & feature flags
│   ├── tauri.conf.json          # App/window/bundle config
│   └── google_workspace.config.example.json   # Template for the real (gitignored) config
│
├── scripts/
│   └── check-no-secrets.mjs     # Scans release binaries for leaked keys (CI/release guard)
│
├── site/                        # Landing site — SEPARATE repo, gitignored here
├── package.json                 # Frontend deps + the tauri:* build scripts
└── README.md

site/ is the marketing landing page. It has its own git repo and Vercel
deployment and is gitignored here — don't edit it from this repo.

Getting started

Prerequisites

• Node.js (LTS) and npm
• Rust toolchain (rustup, stable, ≥ 1.77.2)
• Tauri prerequisites for your OS — on Windows that's the WebView2 runtime and
  the MSVC build tools. See the
  Tauri prerequisites guide.

Setup

# 1. Clone
git clone https://github.com/greencube-ai/greencube.git
cd greencube

# 2. Install frontend dependencies
npm install

# 3. Create your local integrations config from the template
#    (the real *.config.json is gitignored — it holds your own keys)
cp src-tauri/google_workspace.config.example.json src-tauri/google_workspace.config.json
#    then fill in only the keys you actually need

# 4. Run the app (CPU build — works on any machine)
npm run tauri:dev:cpu

⚠️ Gotcha worth remembering: whenever you pull a branch where someone added an
npm package, run npm install before starting the dev server. If you skip it,
the dev server crashes on a missing dependency. When in doubt, npm install first.

Build modes

GPU acceleration is optional. Use the CPU path by default; it's the one that builds
cleanly everywhere.

Notes:

• Vision support is on in both modes.
• The CPU build is the path for CI and fresh dev machines. Vulkan needs local
  GPU/Vulkan tooling set up correctly (MSVC + shader compiler) and is meant for CI
  release builds, where the environment is controlled.
• After any release build, check-no-secrets.mjs runs automatically (it's wired as a
  post* hook) and fails the build if it finds a leaked key.
• Don't put custom Cargo --target-dir folders inside src-tauri; Tauri's dev
  watcher can mistake compiler output there for source changes and loop forever.

Integrations

GreenCube can connect to external apps. OAuth handshakes go through Nango; the full
list of connectable services and the keys they need lives in
src-tauri/google_workspace.config.example.json.

Currently supported connectors include:

• Google — Gmail, Calendar, Drive (and Places for location data)
• Microsoft 365
• GitHub
• Notion
• Dropbox
• Slack
• Web search / data providers — Brave, Tavily, Exa, Jina, Firecrawl, and others

API keys for billable services are user-supplied, never embedded in the app. A
user adds their own keys through Settings (or their local config file). This is a
deliberate part of our security model — see below.

Security notes

The short version: secrets never get baked into the shipped binary.

• No embedded secrets. API keys and OAuth client secrets are not compiled into
  the app. They come from the user's local config / environment / Settings at
  runtime.
• Release scanner. scripts/check-no-secrets.mjs scans the built binary for
  known secret patterns (Google/OpenAI/Anthropic/GitHub/Slack/Nango tokens, PEM
  blocks, AWS keys, etc.) and fails the release if any are found. It runs
  automatically after every tauri:build:*.
• Local config is gitignored. Real config files (src-tauri/*.config.json) are
  ignored by git; only the *.config.example.json templates are committed. Never
  commit a filled-in config.
• Private repos. This code is private and shared only with chosen collaborators.

If you're adding a new integration, follow the same rule: ship the example template,
keep the real keys out of the binary, and add the new secret's pattern to
check-no-secrets.mjs if it has a recognizable format.

Who's building this

Two people:

• Hector — product, vision, business
• Pawel — engineering / CTO