Missing API Logs when calling from OpenClaw

[wandering_husky]

I’m new to using OpenAI API and have been having trouble tracking its usage a lot. Mainly, I can’t find any logs of API usage through OpenClaw.

What I observe:

1. The API key is in usage: I’m being billed for the usage of the API key used by my OpenClaw projects. (Bill is significant and irregular, which is why I’m eager to understand the usage).

2. There are responses: I’ve been getting responses from the API and OpenClaw functions mostly normal. Except:

   1. it gets very slow sometimes - it can take half a day to get back to me.
   2. Every success responses comes with a message: "auth or provider access failed for openai-codex. Run /auth openai-codex to refresh credentials; if you already re-authed, switch models/providers because this account may still be blocked for inference. "

3. Other-than OpenClaw usage produced logs correctly: I’ve been using different API keys as well as the same API key for other projects than OpenClaw and the logs showed up correctly

What I have tried:

1. browser through different projects and keys in the Logs UI. I can confirm that I’m looking at the correct key, but not seeing any logs.
2. Uninstall and reinstall OpenClaw, connect with a brand new API key. No luck.
3. Use different CLI as well as the Chat UI on OpenAI, they all produced logs correctly.

Has anyone else got the same issue? Would really appreciate some help and pointers please.

[_j]

bottom at the tip:

API defaults:

Responses: "store":true
Chat Completions: "store":false (on all but new accounts)

The default on OpenAI’s Chat Completions is not to store logs or artifacts of a chat, and if they are stored, they are under “completions” and not “logs” of Responses.

Not storing server data retention is the pattern you want for self-managed chats, code where you have your own logging and even telemetry reporting. Not to have personal data persisted, unreliably in a way that can’t be trusted for auditing.

This is controlled by the “store” API parameter that you send in a call to override the default. What does OpenClaw even do or what endpoint is it using - can you answer about the calls the software you are using is actually making?

You will note in packages/llm-core/src/types.ts:

/**
 * Compatibility settings for OpenAI-compatible completions APIs.
 * Use this to override URL-based auto-detection for custom providers.
 */
export interface OpenAICompletionsCompat {
  /** Whether the provider supports the `store` field. Default: auto-detected from URL. */
  supportsStore?: boolean;
  /** Whether the provider supports the `developer` role (vs `system`). Default: auto-detected from URL. */
  supportsDeveloperRole?: boolean;
  /** Whether the provider supports `reasoning_effort`. Default: auto-detected from URL. */
  supportsReasoningEffort?: boolean;
  /** Whether the provider supports `stream_options: { include_usage: true }` for token usage in streaming responses. Default: true. */
  supportsUsageInStreaming?: boolean;
  /** Which field to use for max tokens. Default: auto-detected from URL. */
  maxTokensField?: "max_completion_tokens" | "max_tokens";
  /** Whether tool results require the `name` field. Default: auto-detected from URL. */

There’s your store parameter mentioned. Chat Completions parameters like “max_completion_tokens” and “reasoning_effort” are seen.

Then you go down to more types, shapes for the code running API calls itself - no store option.

---

In the API platform management:

That is not a “force a store override” and doesn’t seem to do much. You still would need to be looking in “completions” with calls using store:true to see any Chat Completions calls that were made (and have lower quality because you can’t repeat back a past turn’s reasoning).

I do not have that issue because I do not want stored “chat” products, which on Responses seems a leak that persist forever, as I still have release day logs.

That’s enough “clawing” through that code for me for a while - you can have an AI find where, how, what, etc about the underlying API call after you have done the “configure”. And looking through my own logs, cases where storing is purposefully turned on, hopefully the answer is not…