vlad/autoreg-skills-max
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
autoreg-skills-max/skills/ai-provider-autoreg/references/haze-usehaze-autoreg.md

3.2 KiB
Raw Permalink Blame History

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.