xtekky/gpt4free · error · TimeoutError

GLM captcha solving failed after {SOLVE_RETRIES} attempts: {

Error message

GLM captcha solving failed after {SOLVE_RETRIES} attempts: {last_error}

What it means

Terminal failure of the GLM captcha pipeline: _solve_with_retry() exhausted all SOLVE_RETRIES (3) attempts of _solve_once() (each attempt being a fresh tab solve) and re-raises as TimeoutError, chaining the last underlying exception. The message includes the last error so the root cause (SDK load timeout, invalid token, browser crash) is visible. Callers of get_captcha_verify_param() will see this bubble up when no cached token is valid.

Source

Thrown at g4f/Provider/glm/captcha_solver.py:304

        try:
            await tab.close()
        except Exception:
            pass


async def _solve_with_retry() -> str:
    """Solve the captcha with retry, matching SOLVE_RETRIES attempts."""
    last_err: Optional[Exception] = None
    for attempt in range(1, SOLVE_RETRIES + 1):
        try:
            debug.log(f"GLM captcha: solve attempt {attempt}/{SOLVE_RETRIES}")
            return await _solve_once()
        except Exception as err:
            last_err = err
            debug.log(f"GLM captcha: attempt {attempt} failed: {err}")
            if attempt < SOLVE_RETRIES:
                await asyncio.sleep(1)
    raise TimeoutError(
        f"GLM captcha solving failed after {SOLVE_RETRIES} attempts: {last_err}"
    ) from last_err


async def get_captcha_verify_param() -> str:
    """Return a fresh ``captcha_verify_param`` for the GLM API.

    A valid token is cached for ``TOKEN_TTL_S`` seconds (45s). Concurrent
    callers share a single solve to avoid spawning multiple browsers.
    """
    if _cached_token["verify_param"] and _cached_token["expires_at"] > time.time():
        return _cached_token["verify_param"]

    async with _get_solve_lock():
        # Re-check inside the lock — another coroutine may have just solved it.
        if _cached_token["verify_param"] and _cached_token["expires_at"] > time.time():
            return _cached_token["verify_param"]
        verify_param = await _solve_with_retry()

View on GitHub (pinned to 973504e177)

Solutions

Read {last_error} in the message — it names the real per-attempt failure; fix that underlying error (see errors for _solve_once: SDK load timeout / invalid token).
If last_error is browser-related, verify Chrome and zendriver are installed and launchable outside g4f first.
If last_error is captcha-related, update CAPTCHA_CONFIG and the bundled SDK to match the current z.ai page.
Increase SOLVE_RETRIES only after the per-attempt failure is transient (e.g. flaky network), not when attempts fail deterministically.

Defensive patterns

Strategy: fallback

Try / catch

try:
    token = await get_captcha_verify_param()
except TimeoutError:
    # captcha pipeline exhausted: fail over to another GLM access path or provider
    token = None

Prevention

Treat 3 consecutive identical failures as systemic — inspect last_error instead of retrying more.
Warm the captcha token before request bursts so solve failures happen outside critical paths.
Log the chained exception (__cause__) — it distinguishes config rot from environment breakage.

When it happens

Trigger: Any persistent failure inside _solve_once() repeated 3 times: SDK never loading (error 80), solver returning invalid tokens (error 81), browser launch failing entirely, or every attempt exceeding SOLVE_TIMEOUT_MS (40s). Transient single-attempt failures do NOT produce this error because of the retry loop with 1s backoff.

Common situations: Sustained Aliyun risk-control rejection of the headless environment (every attempt fails identically); broken Chrome/zendriver installation so each attempt dies at browser/tab setup; z.ai captcha config rotation making all retries useless until config is updated.

Related errors

AI-assisted analysis of xtekky/gpt4free@973504e177 (2026-08-14). Data as JSON: /api/errors/6ef80dccbd7415d3. Report an issue: GitHub.