ZacharyZhang-NY 03ca35763f Give wordless pictures a way to be found
A screenshot with no OCR-able words used to be a memory nothing could
reach. It now has a vector, and a question can be asked with it.

- picture space: Xenova/chinese-clip-vit-base-patch16 fp16 ONNX, 361MB,
  sha256 0fad978faa89b85f…, CPU-runnable on the onnxruntime the repo
  already ships. Text 76ms, image 29ms/image at batch 8. The ONNX contract
  was measured, not assumed: it is the fused contrastive graph, so the
  unused tower is fed a placeholder row, and the tokenizer must be
  BertTokenizer — a CLIP tokenizer emits ids past the embedding table.
- visual_index.py keeps picture vectors in their own family beside the
  text ones, keyed by atom id, and refuses to answer when the map and the
  array disagree. retrieval.py stays under 500 lines.
- a search can be asked with a picture, and when the words come up thin
  the picture ranking joins the fusion — but only then, so a text query
  never pays for the encoder.
- visual tokens are counted at 32x32 patches (migration v7): 21,325 image
  atoms went from 5,331 to 34,618 tokens, and the library from 29.9M to
  84.2M. The 100M capsule fits this 50,278-file corpus and nothing much
  larger — that is what the claim actually means.
- the vision-language describer is written and gated: with no snapshot an
  atom records "deferred: no vision-language model snapshot"; a broken
  model becomes a note on the atom instead of a dead ingest.
- forget now voids the picture index and the copy this process holds, so
  a forgotten picture stops answering from RAM.

Measured, six arms, ScreenSpot-v2 (554 icon crops, 408 whole screenshots),
bench/reports/VISUAL.md:
  icon pool      picture 0.208  words 0.175  chance 0.018
  screenshot pool words 0.384   picture 0.215
  screenshot to icon 0.108  — CLIP is a whole-image model, not a grounding
  model: it cannot point at one small icon inside a screen.
  within one screen MRR 0.908 (recall@10 is 1.000 there only because
  chance is 1.000 too, so MRR is the only honest number in that row).
ScreenSpot-v2 instructions are all English, so this run does not test the
bilingual claim and the report says so.

Gates: 199 tests, ruff clean on 17 files, mypy clean on 16 (fresh cache),
the repo's own pyright 0 errors on the 12 files touched.
2026-10-07 20:41:19 -04:00
2026-05-30 23:51:45 -04:00
2026-05-30 23:51:45 -04:00

Ely-Eye

Ely-Eye is a local multimodal context operating system built on Qwen3.5-9B. It runs on a single consumer GPU and gives a small model three tiers of context: a 262K native window, a 1.01M extended window, and a 100M-token memory capsule it can retrieve from, cite, and recall across sessions.

Under the hood it ingests PDFs, screenshots, video, and code into Evidence Atoms, packs them into a Context Cartridge, retrieves with sparse and Qwen embedding search, runs Qwen3.5-9B with trained LoRA adapters, and checks every answer with a verifier. A fifteen-check proof suite exercises the whole thing against the live model, so a real run can be told apart from a fabricated one.

The landing site lives at https://model.elydora.com/ (its source is under ely-eye-web/, which this repository does not track).

Requirements

  • Windows with an NVIDIA GPU and CUDA. Training and the proof suite were built on an RTX 4090; deployment targets a 16GB card such as an RTX 4080.
  • The extended-context runtimes (SGLang, vLLM, KTransformers, llama.cpp) are optional and run under WSL. The default Windows runtime uses Transformers and needs none of them.

Run it locally

.\scripts\install.ps1            # virtual env, PyTorch + CUDA, Transformers, PEFT, bitsandbytes
.\scripts\download-models.ps1    # Qwen3.5-9B, the 0.8B planner, Qwen3-VL-Embedding-8B
.\scripts\serve-backend.ps1      # API on http://127.0.0.1:8765
.\scripts\serve-frontend.ps1     # dashboard on http://127.0.0.1:5173

When ELY_EYE_ADAPTER_DIR is empty, the runtime picks the latest trained HME-Core-LoRA adapter for Qwen/Qwen3.5-9B on its own; ely-eye status prints which adapter it resolved.

For the 262K and 1.01M extended-context profiles, set up the Linux runtimes once and launch one:

.\scripts\setup-linux-runtimes.ps1
.\scripts\launch-sglang-live.ps1       # 262K
.\scripts\launch-sglang-extreme.ps1    # 1.01M via YaRN

Core commands

.\.venv\Scripts\ely-eye.exe status
.\.venv\Scripts\ely-eye.exe ingest C:\path\to\package --cartridge-name project
.\.venv\Scripts\ely-eye.exe hashhop --kind visual --hops 2 --token-equivalent 262144
.\.venv\Scripts\ely-eye.exe proof-suite

Every command has an HTTP equivalent under /api/..., and the dashboard shows the same state: Adapter Matrix, Proof Suite, Memory Map, Cache Trace.

Fine-tuning

Training runs real BF16 LoRA updates on the GPU through Unsloth-patched Transformers, PEFT, and bitsandbytes with paged 8-bit AdamW. Each run writes the PEFT adapter alongside a manifest, a per-step training trace, a summary, and a proof file that records dataset and weight hashes, per-step loss, optimizer-update norms, and the CUDA/BF16 environment.

The adapter set:

HME-Core-LoRA      Qwen3.5-9B attention/MLP
HME-Vision-LoRA    Qwen3.5-9B visual projector and selected vision layers
HME-TTT-VL         Qwen3.5-9B mutable MLP and visual adapter
HME-Visual-MTP     Qwen3.5-9B draft-head LoRA
HME-Router         Qwen3.5-0.8B context planner
HME-Retrieval      Qwen3-VL-Embedding-8B contrastive retrieval adapter

Proof suite

ely-eye proof-suite runs fifteen checks against the live model and writes the evidence under .ely_eye/data/eval_proofs/. Among them:

  • real CUDA BF16 LoRA training — changed weight hashes, nonzero optimizer updates, per-step loss
  • the runtime loading the model and adapter and generating a cited answer
  • Visual HashHop: multi-hop visual addressing the model has to actually solve, with no OCR shortcut
  • the 100M-token memory capsule committing to a reproducible Memory DNA
  • the Visual Contradiction Lens localizing cross-version drift (design-token, layout, typography, copy, visual-code, temporal) at >=80% recall with no false positives
  • standard benchmark samples (MMMU-Pro, OCRBench, and others) scored against ground truth
.\.venv\Scripts\ely-eye.exe proof-suite
.\.venv\Scripts\ely-eye.exe latest-proof-suite
.\.venv\Scripts\ely-eye.exe runtime-generation-proof
.\.venv\Scripts\ely-eye.exe visual-contradiction-proof

MCP server for coding agents

ely-eye-mcp/ is a local Model Context Protocol server that exposes the .ely_eye memory store to coding agents such as Codex and Claude Code. One command builds a native Go binary (or downloads a prebuilt one), installs it under .ely_eye/bin/, and registers it with both clients. No Docker.

Windows:

powershell -ExecutionPolicy Bypass -File .\ely-eye-mcp\install.ps1 -Client both

Linux and macOS:

bash ./ely-eye-mcp/install.sh --client both

The agent then has nine read-only tools over the live memory — status, cartridge listing and detail, Evidence Atom search and fetch, evidence-pack compilation, proof suites, and HashHop proofs. The server opens the database read-only and never writes to it. The same installer works against any .ely_eye store, not only this repository. See ely-eye-mcp/README.md for the full tool list and the release pipeline.

Data layout

Runtime state lives under .ely_eye/ (git-ignored):

.ely_eye/
├─ adapters/     trained LoRA adapters
├─ data/         sqlite database and eval proofs
├─ training/     datasets and training traces
├─ objects/      ingested source files
├─ cache/        cache fabric
└─ cartridges/   materialized Context Cartridges

A Context Cartridge is a self-contained memory package: the Evidence Atoms, a sparse index and vector indexes, a temporal graph, KV snapshots, the memory capsule, any attached adapters, and the eval proofs.

Project layout

backend/      Python: ingestion, retrieval, runtime, training, proof suite, FastAPI
frontend/     the local dashboard (Vite + React)
scripts/      PowerShell: install, model download, serving, runtimes, fine-tuning
ely-eye-mcp/  Go: local MCP server exposing the memory store to coding agents
S
Description
Ely-Eye: a local memory store for AI. Every memory carries who it belongs to, where it came from, when it was true, and who may read it. Coding agents reach the same store over MCP.
Readme AGPL-3.0
2.8 MiB
0 Stars 1 Watchers 0 Forks
Languages
Python 83.2%
Go 7.4%
Shell 3.6%
TypeScript 3.4%
PowerShell 1.1%
Other 1.2%