Studiu · 29 iulie 2026 · voost vision
Memoria din cloud vs. memoria de pe masa ta
Am mutat toată memoria Honcho (560 de sesiuni, 84.159 de concluzii) pe Mac Mini și am pus cele două instanțe față în față: aceleași 45 de întrebări, aceleași 20 de căutări, aceleași măsurători — cap la cap.
- Capcane de halucinație5/5 curate
- Search relevant20/20
- Erori pe durata testului0
- Capcane de halucinație4/5 1 inventat
- Search relevant13/20 + 4 erori quota
- Erori pe durata testului5 (toate 429, reparabile)
Scor calculat live din datele brute ale benchmark-ului, încorporate în pagină. Apasă pe orice întrebare mai jos ca să vezi ambele răspunsuri reale.
De ce a existat studiul
Pe 29 iulie, contul Honcho cloud era pe minus (−$0.16): memoria nu mai răspundea la întrebări, iar 1.847 de fragmente de conversație așteptau neprocesate — adică memoria era și moartă, și rămasă în urmă. Întrebarea: dacă tot plătim abonamente AI, poate memoria să trăiască pe propriul Mac Mini, pe creditele incluse în abonamentul Google AI Pro, fără să depindă de un cont cu credite care se termină?
Ce s-a mutat (și cât de fidel)
Cum s-a evitat re-derivarea (economie ~20×)
În loc să trecem tot istoricul din nou prin LLM (~$5–15 și observații reformulate), concluziile gata derivate au fost exportate prin API și inserate direct în baza locală, cu ID-uri, timestamps și nivel păstrate. Singurul cost: recalcularea embeddings-urilor pe Vertex AI (~$3–4, un singur model pentru tot spațiul vectorial — cerință explicită din documentația Honcho). Mesajele s-au reimportat pe calea oficială („replay via normal application path”).
Duelul 1 · Aceleași 45 de întrebări, ambele memorii
Cinci categorii + cinci întrebări-capcană despre lucruri care nu există în memorie (testul de halucinație). Barele arată procentul de răspunsuri corecte pe categorie; apasă pe o întrebare ca să compari răspunsurile reale.
Verdictele: potrivire automată pe fapte-cheie + arbitraj manual pe răspunsurile complete. O întrebare a fost eliminată din scor (ground truth defect). Fiecare parte a avut victorii unice: localul a știut perfect STRIKE 1v1 și tenant-ul Răzvan/epgmktg (cloud-ul nu), cloud-ul a știut contabila UNEX și structura de prețuri (localul nu) — varianță de căutare internă, nu superioritate sistematică.
Duelul 2 · Căutarea semantică
20 de căutări identice; verde = primele 5 rezultate conțin conținutul așteptat. Aici cloud-ul a câștigat clar: 20/20 vs. 13/20 — plus 4 erori locale de quota (galben), toate în rafală.
De ce a pierdut localul aici (și ce e reparabil)
Cele 4 erori galbene: quota Vertex de embed_content tokens/minut, lovită de rafala de 40 de query-uri consecutive — se rezolvă cu o cerere de mărire de quota sau backoff în client, nu e un defect al arhitecturii. Cele 3 ratări de relevanță sunt însă reale: modelul de embeddings diferă (gemini-embedding-001 local vs. text-embedding-3-small pe cloud) și pe câteva query-uri scurte a adus rezultate mai slabe. Reparația de fond ar fi re-embedarea cu alt model — operațiune „destroy & rebuild” conform documentației.
Duelul 3 · Viteza
Fiecare punct = o întrebare dialectic. La mediană sunt egale; localul are coada mai lungă (p90).
Citirile pure sunt însă net mai rapide local: reprezentația în 0,02s vs. 0,33s, peer card în 0,01s vs. 0,17s — fără drum până în cloud.
Duelul 4 · Scrierea și prospețimea
Costurile, pe curat
| ☁ Cloud | ⌂ Local | |
|---|---|---|
| Cost lunar de funcționare | $13–25 (credite Honcho) | $2–8 API brut — acoperit de creditul GDP de $10/lună din Google AI Pro |
| Costul migrării (o dată) | — | ~$4–5 (embeddings + test), fără re-derivare |
| Spațiu | 0 local | 1,26 GB DB + 0,9 GB cod (SSD) + 111 MB backup |
| Când se termină banii | memoria moare + rămâne în urmă (s-a întâmplat) | derivarea așteaptă în coadă; citirile merg în continuare |
| Operare | zero (a lor) | 2 procese + backup pg_dump — pe agenți |
| Datele și modelele | la Plastic Labs, modele fixe | pe mașina ta, modele configurabile per funcție |
Verdictul
Calitate: egalitate practică (85% vs. 82%), cu două rezerve oneste pentru local — o halucinație la capcane („ce mașină conduce Radu”) și un search mai slab pe 3 query-uri. Controlul, costul și imunitatea la „s-au terminat creditele” sunt ale localului; disciplina la capcane, search-ul impecabil și zero operare sunt ale cloud-ului.
Localul era gata de adopție după trei reparații punctuale — toate executate pe 30 iulie:
- Quota Vertex ✓ — cerere de mărire depusă + backoff prelungit în client (1-2s → până la 45s, traversează fereastra de minut a quotei).
- Delta-sync ✓ — +15.808 concluzii noi preluate din backlog-ul procesat de cloud, +59 mesaje reale; pe drum am descoperit și reparat un gotcha nedocumentat (ID-urile mesajelor nu supraviețuiesc importului prin API — diff-ul corect e pe conținut).
- Curățarea peer card-urilor ✓ — identitatea și relațiile consolidate pe peer-ul radu; întrebarea cu contabila, ratată de local în benchmark, acum primește răspunsul corect.
Cutover executat: CLI-ul honcho și hermes rulează pe instanța locală (verificat cu loader-ul de config al lui hermes); cloud-ul a rămas fallback legacy pe honcho-cloud. Serviciile locale sunt permanente: 4 LaunchAgents (api, deriver, health-guard cu alertă Telegram la 15 min, backup zilnic pg_dump cu retenție 7 zile).
Epilog · Ce a urmat după studiu (30 iulie)
Cutover-ul a fost partea ușoară. Interesant a fost ce am găsit în memorie odată ce am început să ne uităm cu atenție — trei straturi de poluare, fiecare cu altă cauză.
1. Junk de degenerare LLM, fabricat de deriver-ul cloud
Creditul de $10 abia adăugat pe cloud s-a evaporat procesând backlog-ul — și o parte din ce a produs era gunoi curat: bucle de enumerare în care modelul repetă aceeași „observație” cu fiecare unitate de timp sau geografie posibilă. Mostre reale:
462 de asemenea concluzii ajunseseră și în copia locală prin delta-sync — șterse, cu dovezile arhivate. Pe cloud rămân: acolo nu mai plătim curățenia.
2. Poluare de staging: 30% din toată memoria
Junk-ul avea o sursă precisă: sesiunile de staging — rulările de test ale extracției de apeluri din Voost Control, care ar fi trebuit să fie complet izolate, dar scriau în memoria reală. Valurile repetate de teste re-derivaseră aceleași apeluri de 3-5 ori.
Gaura de izolare a fost închisă la sursă (hermes nu mai scrie în memorie în rulările de staging), într-o sesiune separată de fix.
3. Fapte de clienți atribuite lui Radu
Cel mai subtil strat: transcripturile apelurilor de vânzare au fost ingerate sub identitatea lui Radu, deci afirmațiile clienților despre propriile afaceri deveniseră „fapte despre Radu” — care s-ar fi trezit în memorie cu flotă de curieri, magazin lângă Lidl și farfurii de desert. Fiecare din cele 26.562 de conținuturi distincte despre Radu a fost clasificat cu un LLM (profil + exemple, 5 fluxuri paralele, ~$1,5 din creditele incluse):
Tăietura a fost chirurgicală: au zburat buchetele florarului și geamurile clientului, dar a rămas munca lui Radu pe app-ul florăriei („stil vizual ca Glovo” = referința lui de design). Verificarea finală: „Are Radu magazin fizic, curieri sau livrări?” → „Nu — VOOST VISION, dezvoltare software, lucrează de acasă.” ✓
Starea finală a memoriei
Morala epilogului: mutarea pe local nu a adus doar controlul costurilor — a făcut memoria inspectabilă și reparabilă. Toate cele trei straturi de poluare existau și în cloud; acolo doar le-am fi plătit derivarea, la nesfârșit.
Metodologie & limite
45 de întrebări dialectic (5 categorii × 8 + 5 capcane) și 20 de căutări, rulate alternat cloud/local în aceeași fereastră de timp; 5 extrageri de reprezentare per parte; test de ingestie cu sesiune dedicată, ștearsă după, pe ambele părți. Verdicte: potrivire automată pe fapte-cheie + arbitraj manual (Claude) pe răspunsurile complete; o întrebare eliminată (ground truth defect). Limite: o singură fereastră orară; cloud-ul procesa backlog în timpul testului (întrebările au vizat fapte istorice stabile, nu ultimele zile); modelele dialectic diferă între părți (config propriu local: gemini-2.5-flash pe Vertex); arbitrul e un singur model. Datele brute: bench-results/results.jsonl pe mini.