# usehaze.ai (Haze AI) — protocol, autoreg, status

## Architecture (reversed from Tauri desktop app)

- Desktop app = Tauri + WebView2 wrapper over plain HTTP APIs; page URL `tauri.localhost`.
- Chat gateway: `https://v1.usehaze.ai/ai/v1` — OpenAI-compatible (`/models`, `/chat/completions`), auth = Bearer WorkOS access token (~24h expiry).
- Auth API: `https://usehaze.ai/api`
  - `POST /auth/bootstrap {email, password, create:true}` → register → `{status:"verification_required", pendingToken}` (or `{status:"authenticated", accessToken}` if already verified).
  - `create:false` = login → 401 if unknown email.
  - OTP: 6 digits from `welcome@workos.dev`, read via IMAP (t-online.de pool works: secureimap.t-online.de:993).
  - `POST /auth/verify-code {code, pending_authentication_token}` → `accessToken`.
- Cloudflare blocks bare python-urllib (403); curl with browser UA passes.
- Free accounts get the free-tier catalog; paid models answer `upgrade_required`.

## Reg limits

- Per-network daily cap: 429 "Too many accounts were created from this network today" → rotate IP via own-VPS SOCKS tunnel (see `references/ssh-socks-ip-rotation.md`).
- Dash-alias t-online emails are dead for delivery; use canonical addresses only.

## Local assets

- Farm dir: `C:/Users/User/tmp/haze_farm/` — `mass_reg_px.py` (proxy rotation), `reg_one_socks.py` (single reg through SOCKS tunnel + chat test), pool `tokens.json`, mail pool `Desktop/avtoreg/working_mails.txt` (~17K).
- Public repo: `gbonnet65923/haze-toolkit` (gateway proxy + mass-reg + RE helpers). Dashboard rebuild: `tmp/haze_public/dashboard.py` (stdlib-only, paste-token UI, channel footer).

## Service status (verified Oct 2026)

- `/v1/models` = 200 with catalog (gpt-6-luna/sol/6.1-sol, hy3, step-5-preview), tokens valid.
- BUT chat = 502 on every gpt-6/hy3 model and `upstream_rate_limited` on step-5 — on ALL tokens INCLUDING freshly registered ones. Registration works, the model upstream is dead. Frontend bundle lists stale models (gpt-5.6-*, claude-*) that return `unknown_model`.
- UI shows newer models ("Kimi K3", "GLM 5.3", "DeepSeek V4 Pro/Flash") that `/v1/models` does NOT list. Real wire ids — capture from the app's WebSocket (CDP `Network.webSocketFrameSent/Received`, doc-op frames carry `modelId`): `kimi-k3`, `glm-5-3`, `deepseek-v4-pro`, `deepseek-v4-flash`. Display name ≠ id ("GLM 5.3" → `glm-5-3`); don't guess from UI labels.
- Those ids are accepted by the router (NOT unknown_model) but every `/v1/chat/completions` variant returns `{"error":"Internal error"}` — chat for the new models runs over the app's WS agent protocol, the OpenAI-compat REST path never serves them. A public proxy build is impossible for them.
- Final liveness test: send a message in the app's own UI — session stays `running:true` with no assistant reply → upstream dead for everyone, not a token/account problem. Fresh reg via SOCKS tunnel bypasses the 429 cap but cannot revive a dead backend.
- Lesson applied: do NOT publish a channel post for a service whose chat probe fails on every model — verify per Phase 2.7 of `ai-proxy-authenticity`. Full CDP/WS capture recipe: skill `ide-reverse-engineering` → `references/tauri-webview2-cdp-runtime-extraction.md` §2b.