openclaw - 💡(How to fix) Fix model-fetch logs lost in v2026.5.28 — degraded from log.info to log.debug behind env flag

Summary

In v2026.5.28, [model-fetch] request/response logs were moved from log.info to log.debug via a new emitModelTransportDebug wrapper. At the default log level, these logs no longer appear in gateway.log.

This is a regression from v5.19 where every API call was logged with provider, model, URL, status code, and latency.

Steps to Reproduce

1. Run OpenClaw gateway (v2026.5.28)
2. Send any message through any channel
3. Check gateway.log

Expected: [model-fetch] start and [model-fetch] response entries appear.

Actual: No model-fetch entries at all.

Root Cause

openai-transport-stream-N4q_7Mj8.js:55-63:

function isModelTransportDebugEnabled(env = process.env) {
  return isTruthyEnv(env.OPENCLAW_DEBUG_MODEL_TRANSPORT)
    || resolveModelPayloadDebugMode(env) !== "off"
    || resolveModelSseDebugMode(env) !== "off"
    || isTruthyEnv(env.OPENCLAW_DEBUG_CODE_MODE);
}

function emitModelTransportDebug(log, message) {
  if (isModelTransportDebugEnabled()) {
    log.info(message);   // needs env flag
    return;
  }
  log.debug(message);    // filtered at default log level
}

All [model-fetch] lines (start, response, error) now go through this wrapper and default to log.debug.

Impact

Model-fetch logs are critical for:

• Verifying the actual provider/model/api used for each request
• Catching baseUrl misconfigurations (e.g., double /v1 → 404)
• Monitoring API latency per request
• Diagnosing prompt cache behavior across protocols (openai vs anthropic)

Without them, debugging provider issues becomes guesswork.

Workaround

Set OPENCLAW_DEBUG_MODEL_TRANSPORT=true to restore logging. This requires a gateway restart.

Request

Restore model-fetch logs to log.info by default, or at minimum document the env flag prominently in release notes.