18 KiB
name, description, category, triggers, pitfalls
| name | description | category | triggers | pitfalls | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| conol-automation | Mass-register Conol.ai accounts via Chrome CDP, farm onboarding quests for credits, and run an OpenAI-compatible pool gateway across all accounts. Use when the user says "conol", "регистрируй", "сфарми квесты", "запусти шлюз", "авторег", or wants to scale Conol.ai API access. | automations |
|
|
Conol.ai Full Automation
Fully autonomous system for Conol.ai account management: registration → quest farming → API gateway.
Quick Start
cd C:\Users\User\Desktop\conol_autoreg
USE_PYTHON="/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe"
# Check pool status
$USE_PYTHON eni_conol.py status
# Register N accounts (⚠️ currently blocked by conol.ai anti-bot, see pitfalls)
$USE_PYTHON eni_conol.py reg 5
# Farm quests on all accounts
$USE_PYTHON eni_conol.py quests
# Start API gateway (port 9999)
$USE_PYTHON eni_conol.py gateway
# Multi-threaded registration from email queue (v2.0 — detailed errors)
$USE_PYTHON multi_reg.py 3 2
# Full cycle: register + quests + gateway
$USE_PYTHON eni_conol.py all 10
# Test all accounts for liveness
$USE_PYTHON eni_conol.py test
Auto-Repair Daemon
Self-healing daemon that monitors all accounts, detects Conol.ai outages, and auto-recovers. Full docs: references/auto-repair-daemon.md.
What it does every cycle (default 5 min):
- Health-checks all accounts (parallel, semaphore=5)
- Detects server-wide outages (>80% HTTP 500) → skips repairs, logs
server_down - Individual repairs: re-login via CDP on 401/cookie errors, re-register on dead cookies
- Auto-farms quests when credits < 100
- Restarts gateway if dead
When to use:
- Gateway keeps dying → daemon auto-restarts it
- Accounts losing credits → daemon auto-farms
- Conol.ai backend goes down → daemon detects and waits, then auto-recovers
Architecture (2026-07-30)
conol_autoreg/
├── eni_conol.py # Master orchestrator (575 lines) — reg, quests, gateway, status, test
├── gateway.py # OpenAI-compatible pool gateway v6.1 (697 lines) — streaming + tool use
├── multi_reg.py # Multi-threaded parallel registration v2.0 (411 lines) — detailed errors
├── config.json # All settings (password, Gmail, CDP, port, site_key)
├── conol_accounts_pool.jsonl # Account database (~31 accounts)
├── email_queue.jsonl # Email queue for multi-threaded registration
├── cookies_*.json # Session cookies per account (~31 files)
├── chrome_cdp.bat # Chrome CDP launcher
└── start_all.bat # Unified launcher with menu
Removed (2026-07-30 cleanup): dashboard_server.py, eni_repair_daemon.py, quests.py, config.example.json, state JSON files. Gateway v6.1 features: token-level SSE streaming (10-30ms micro-delay), XML-based tool use emulation, round-robin pool with automatic failover.
Registration Flow (Chrome CDP)
page.clear_cookies()+ clear localStorage/sessionStorage- Navigate to
/sign-up - Solve reCAPTCHA v3 natively:
grecaptcha.execute('6Lc3wmAtAAAAAB9YBPXQtT9uGGsH3ul6LQBc5AUu', {action: 'sign_up'}) POST /api/invites/registerwith captcha inx-captcha-responseheaderPOST /api/auth/send-verification-email- IMAP wait for verification email (Gmail:
[REDACTED-NAME]@gmail.com, App Password in config) - `GET /api/auth/verify-email?token=[REDACTED]
- Login:
POST /api/auth/sign-in/email - Extract cookies → save as
cookies_<name>.json - Append to
conol_accounts_pool.jsonl
Chrome CDP command:
chrome.exe --remote-debugging-port=9228 --user-data-dir=C:\Users\User\Desktop\conol_chrome_profile
Quest Farming
Six onboarding quests worth ~300 credits each:
| Quest ID | Action | Credit |
|---|---|---|
note_written_by_agent |
Create note "ENI Log" | ~300 |
memory_written |
Save to persistent memory | ~300 |
note_edited_by_agent |
Edit the note | ~300 |
timer_scheduled |
Schedule a timer | ~300 |
note_shared |
Share note publicly | ~300 |
skill_installed |
Install from marketplace | ~300 |
Each quest is triggered by sending a prompt to /api/sessions with gpt-5.6-luna and agentEffort: low.
Gateway API
OpenAI-compatible endpoint at http://127.0.0.1:9999/v1/chat/completions.
curl http://127.0.0.1:9999/v1/chat/completions \
-H "Authorization: Bearer test" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-5.5","messages":[{"role":"user","content":"Hello"}]}'
Endpoints:
GET /health— pool statusGET /v1/models— list 18 modelsPOST /v1/chat/completions— chat (streaming + non-streaming + tool use)POST /v1/images/generations— SVG generation via ClaudeGET /pool/stats— per-account statsPOST /pool/reload— hot-reload accounts file
18 models available — 5 support image/SVG generation (claude-opus-4-8, claude-fable-5, claude-opus-4-7, gemini-3-pro, gemini-3-flash).
Tool Use (v6.1 — XML Emulation)
Gateway supports OpenAI-compatible tool calling via XML emulation. Conol.ai models have built-in tools (WebSearch, Fetch, SetIntention) but do NOT natively accept user-defined tool_calls. Instead:
- Tool definitions are injected into the system prompt as XML schema
- Gateway parses model responses for
<function_call>XML tags - Emits standard OpenAI-format
tool_calls[]in the response
Verified working (2026-07-30): get_weather({"city": "London"}) on gpt-5.6-luna — finish_reason: tool_calls.
curl http://127.0.0.1:9999/v1/chat/completions \
-H "Authorization: Bearer test" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-luna",
"messages": [{"role": "user", "content": "Weather in London?"}],
"tools": [{"type": "function", "function": {"name": "get_weather", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}}],
"stream": false
}'
Both streaming and non-streaming modes support tool calls. Tool results can be sent back via role: "tool" messages for multi-turn tool loops.
Full protocol: references/conol-tool-use.md.
Hermes Integration
Once the gateway is running, add it as a Hermes provider. See also apioid-gateway skill for the ApiOid production gateway ([REDACTED-NAME].loc.cc) — this Conol pool runs on port 9999 as a SEPARATE gateway, not the main ApiOid one.
Follow the full integration workflow:
→ ai-config-optimization → references/provider-sync-workflow.md
Quick checklist (Conol-specific):
| # | File | What to add |
|---|---|---|
| 1 | ~/.omp/agent/providers.yml |
hermes-conol block (baseUrl: http://127.0.0.1:9999/v1, apiKey: [REDACTED]) |
| 2 | ~/.omp/agent/models.yml |
Same hermes-conol block |
| 3 | ~/.omp/agent/config.yml |
hermes-conol/* in enabledModels, hermes-conol in providerOrder |
| 4 | production/gateway.py |
"CONOL" in upstream prefix tuple (line ~191) |
| 5 | production/run_gateway.ps1 |
UPSTREAM_CONOL_URL + UPSTREAM_CONOL_KEY env vars |
| 6 | update_all_providers.py |
'hermes-conol' entry in updates dict |
All 6 files must be updated. Gateway restart required after changes.
Startup — Critical: Use System Python, NOT Hermes venv
The Hermes agent venv (C:\Users\User\AppData\Local\hermes\hermes-agent\venv\) has BROKEN pydantic_core and greenlet. Running the gateway or registration scripts inside it will crash immediately with:
ModuleNotFoundError: No module named 'pydantic_core._pydantic_core'
ModuleNotFoundError: No module named 'greenlet._greenlet'
The Windows Store python3 (3.14) also has broken playwright greenlet.
ALWAYS use system Python 3.11:
/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe eni_conol.py gateway
Or equivalently in batch:
C:\Users\User\AppData\Local\Programs\Python\Python311\python.exe eni_conol.py gateway
Do NOT use bare python or python3 — they may resolve to the broken venv or Windows Store Python.
If python otherwise works for you but Hermes venv crashes, explicitly start with:
/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe gateway.py
Conol.ai Backend Outage (HTTP 500 on /api/sessions)
When ALL accounts return HTTP 500 from POST /api/sessions with {"error":"Failed to create session"}, this is a Conol.ai server-side outage — NOT a cookie/auth/code issue.
Differential diagnosis — confirm server-down, not account issue:
- Test ONE account with valid payload → HTTP 500 = candidate outage
- Test MULTIPLE models (gpt-5.5, claude-opus-4-8, gemini-3-flash, etc.) → ALL 500 = confirmed server-wide
- Test with WRONG payload (missing required fields) → HTTP 400 (not 500) proves endpoint routing works, only session creation is broken
- Test RSC endpoint:
GET https://conol.aiwith headersAccept: text/x-component, RSC: 1→ also returns 500 HTML error page during server-side Next.js outages - Verify cookies valid:
GET /api/auth/get-session→ HTTP 200 confirms auth works, isolated to session creation
The auto-repair daemon handles this automatically: it detects >80% 500 failures and skips all repairs, logging server_down. When the backend recovers (sessions return 201), it logs server_up and resumes normal repair cycle. No manual intervention needed — just keep the daemon running.
Manual verification (if daemon not running):
/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe -c "
import json, httpx
with open('cookies_conol066427.json') as f:
cookies = {c['name']: c['value'] for c in json.load(f)}
r = httpx.Client(cookies=cookies).post('https://conol.ai/api/sessions', json={
'source': {'type': 'home'}, 'messages': [{'type': 'text', 'content': 'OK'}],
'agentModel': 'gpt-5.5', 'agentEffort': 'low',
})
print(f'HTTP {r.status_code}: {r.text[:100]}')
"
If HTTP 201 and sessionId present → backend is alive. If HTTP 500 → wait and retry in 30-60 minutes.
Model Downgrades (modelDowngraded: true)
When a requested model is unavailable or overloaded, Conol.ai silently downgrades to a fallback and returns "modelDowngraded": true with "effectiveModel" in the 201 session response. The session still works — it just uses a cheaper/smaller model. This is DIFFERENT from a server outage: with downgrades you get HTTP 201 + working sessions; with outages you get HTTP 500 for all models.
Known downgrade paths observed in production:
| Requested | Effective | When |
|---|---|---|
gpt-5.5 |
claude-haiku-4-5 |
GPT-5.5 overload/outage (July 2026) |
Detection: Check modelDowngraded field in POST /api/sessions 201 response:
{"sessionId":"j0c8y5kosm47bd1nsf2zlmrl","modelDowngraded":true,"effectiveModel":"claude-haiku-4-5"}
Gateway impact: The gateway forwards the response as-is — the model field in /v1/chat/completions response still shows the requested model (e.g. gpt-5.5), not the effective model. The downgrade is transparent to the caller. No code change needed.
Important: If you get 500 → wait (server outage). If you get 201 with modelDowngraded: true → the system works but the requested model is temporarily unavailable; you can still chat through the fallback model.
Gateway Crash + Recovery
When Conol.ai returns 500 errors, the gateway accumulates fail_count on each account. After 5 failures, account is deactivated (active = False). When all accounts deactivate, the gateway exits with code 1.
The auto-repair daemon handles this: it health-checks the gateway every cycle and auto-restarts it (up to 3 attempts, 30s apart). It also reloads the pool after restart to pick up any account changes. Keep the daemon running and the gateway stays alive.
Manual recovery (if daemon not running):
- Verify Conol.ai backend is alive (see above)
- Restart gateway with matching API key:
# Old stable gateway (conol_github) — was stable for 20+ hours
cd C:\Users\User\Desktop\conol_github
ENI_POOL_KEY=test /c/Users/User/AppData/Local/Programs/Python/Python311/python.exe conol_pool_gateway.py
# New gateway (conol_autoreg) — uses config.json
cd C:\Users\User\Desktop\conol_autoreg
/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe gateway.py
API key must match OMP: OMP at ~/.omp/agent/providers.yml has apiKey: [REDACTED] Gateway must run with that same key. The conol_autoreg/config.jsonhasgateway.api_key: test(correct). The oldconol_githubgateway usesENI_POOL_KEY` env var — must be explicitly set.
Common Pitfalls
Python Interpreter (Hermes venv broken)
# ❌ WRONG — Python from Hermes venv (broken pydantic/greenlet)
python eni_conol.py gateway
# ❌ WRONG — Windows Store Python 3.14 (broken playwright greenlet)
python3 eni_conol.py gateway
# ✅ CORRECT — system Python 3.11
/c/Users/User/AppData/Local/Programs/Python/Python311/python.exe eni_conol.py gateway
httpx Cookie Corruption
# ❌ WRONG — shared client, cookies mix up
async with httpx.AsyncClient() as shared:
tasks = [test_with(shared, acc) for acc in accounts]
await asyncio.gather(*tasks)
# ✅ CORRECT — each task gets its own client
async def test_one(acc):
async with httpx.AsyncClient(cookies=acc_cookies, ...) as client:
...
SSE Event Types
Conol.ai uses history_delta (NOT text-delta):
if ev.get("type") == "history_delta":
for stage in ev.get("stages", []):
for log in stage.get("logs", []):
for c in log.get("content", []):
if c.get("text"):
full_text += c["text"]
Account Liveness Check
Test each account by creating a session (HTTP 201 = alive):
r = await client.post("https://conol.ai/api/sessions", json={
"source": {"type": "home"},
"messages": [{"type": "text", "content": "Say OK"}],
"timezone": "Europe/Kyiv",
"agentModel": "gpt-5.5",
"agentEffort": "low",
})
# 201 = alive, 401 = expired cookies
Config
Key settings in config.json:
conol.password— account passwordgmail.address/gmail.app_password— IMAP verificationcdp.url— Chrome DevTools Protocol URLgateway.port/gateway.api_key— gateway settingsregistration.*— delays and timeouts
API key can be overridden via ENI_POOL_KEY environment variable.
Dependencies
pip install httpx fastapi uvicorn playwright requests
playwright install chromium