binary-husky/gpt_academic · error · RuntimeError

API异常,请检测终端输出。可能的原因是:{finish_reason}

Error message

API异常,请检测终端输出。可能的原因是:{finish_reason}

What it means

While consuming the OpenAI-compatible SSE stream, if a decoded chunk's response_text equals 'API_ERROR' and the finish_reason condition holds, the code fetches the full error body via get_full_error, logs it with logger.error, and raises RuntimeError('API异常...可能的原因是:{finish_reason}'). The real error body is only in the log; the exception carries just the finish-reason hint.

Source

Thrown at request_llms/oai_std_model_template.py:238

            try:
                chunk = next(stream_response)
            except StopIteration:
                if result == "":
                    raise RuntimeError(f"获得空的回复,可能原因:{finish_reason}")
                break
            except requests.exceptions.ConnectionError:
                chunk = next(stream_response)  # 失败了,重试一次?再失败就没办法了。
            response_text, reasoning_content, finish_reason, decoded_chunk = decode_chunk(chunk)
            # 返回的数据流第一次为空,继续等待
            if response_text == "" and (reasoning == False or reasoning_content == "") and finish_reason != "False":
                continue
            if response_text == "API_ERROR" and (
                finish_reason != "False" or finish_reason != "stop"
            ):
                chunk = get_full_error(chunk, stream_response)
                chunk_decoded = chunk.decode()
                logger.error(chunk_decoded)
                raise RuntimeError(
                    f"API异常,请检测终端输出。可能的原因是:{finish_reason}"
                )
            if chunk:
                try:
                    if finish_reason == "stop":
                        if not console_silence:
                            print(f"[response] {result}")
                        break
                    result += response_text
                    if reasoning:
                        reasoning_buffer += reasoning_content
                    if observe_window is not None:
                        # 观测窗,把已经获取的数据显示出去
                        if len(observe_window) >= 1:
                            observe_window[0] += response_text
                        # 看门狗,如果超过期限没有喂狗,则终止
                        if len(observe_window) >= 2:
                            if (time.time() - observe_window[1]) > watch_dog_patience:

View on GitHub (pinned to d6bde0fa54)

Solutions

  1. Read the logger.error output — it contains the full decoded error chunk with the provider's message.
  2. Test the same key/model/base-URL with curl to confirm access and quota.
  3. Correct the model name or base URL in config.py to one the provider supports.
  4. If behind a proxy/relay, top up its quota or bypass it.
Defensive patterns

Strategy: try-catch

Try / catch

try:
    result = predict_no_ui_long_connection(...)
except RuntimeError as e:
    if 'API异常' in str(e):
        detail = read_last_logged_chunk()  # logger.error captured the full body
        route_to_key_or_quota_fix(detail)
    else:
        raise

Prevention

When it happens

Trigger: Upstream relays an error payload that decode_chunk maps to the literal 'API_ERROR' text: invalid request (bad model name), authentication failure, rate limit, or a relay/proxy returning an OpenAI-style error object mid-stream.

Common situations: Custom API_URL_ORIGINAL pointing at a relay (e.g. one-api/openai-forward) whose quota is spent; model name not supported by the endpoint; key lacking access to the requested model; version drift where decode_chunk's expectations no longer match the provider's error format.

Related errors


AI-assisted analysis of binary-husky/gpt_academic@d6bde0fa54 (2026-08-14). Data as JSON: /api/errors/2a86b69dc091fe9b. Report an issue: GitHub.