Context 0% | Friends of the Crustacean 🦞🤝 | Page 1

blazing pier Mar 9, 2026, 8:59 AM

#

După update la 2026.3.8 am bug cu context tracking - /status arată mereu Context: 0/256k (0%) și compaction nu merge.

deep pumiceBOT Mar 9, 2026, 9:06 AM

#

În 2026.3.8, linia aia din /status („Context: X/256k”) vine din token counters salvați în sessions.json (best‑effort) și se actualizează doar dacă agentul primește usage (input/output/cache tokens) de la provider. Dacă providerul nu mai raportează usage (sau raportează mereu 0), /status rămâne blocat la 0/256k (0%), iar auto‑compaction (care depinde de estimări) poate să nu mai declanșeze.

Ca să triem rapid:

Dă paste la output complet de la /status (în special liniile cu 🧠 Model: și ⚙️ Runtime:).
Vreau să văd dacă rulezi pe un provider de tip CLI/local (unde usage poate lipsi) vs API (Anthropic/OpenAI etc).
Rulează /usage tokens, apoi trimite un mesaj normal (nu comandă).
Spune-mi dacă apare footer cu tokens nenuli. Dacă nu apare / e 0 → nu primim usage de la model.
Rulează /compact ca mesaj standalone și dă paste la răspunsul lui (ex: „Compacted …”, „Compaction skipped”, sau „Compaction failed: …”).
(Mulți zic „compaction nu merge” când de fapt merge, dar /status nu reflectă token count.)
În terminal: openclaw --version (și dacă poți, și openclaw status), ca să verificăm exact build-ul + dacă e ceva update disponibil.

Docs relevante (ca referință pentru ce verificăm):

Context: https://docs.openclaw.ai/concepts/context

#

Token use: https://docs.openclaw.ai/reference/token-use
Compaction: https://docs.openclaw.ai/concepts/compaction

Cu cele 3 paste-uri de mai sus (status + usage + compact) îți pot spune imediat dacă e:

limitare de provider (usage lipsă), sau
regresie în 2026.3.8 pe un provider care ar trebui să raporteze usage (caz în care merită deschis issue pe GitHub cu log/versiune).

blazing pier Mar 9, 2026, 9:14 AM

#

🦞 OpenClaw 2026.3.8 (3caab92)
🧠 Model: ollama/qwen3.5:cloud · 🔑 api-key (env: OLLAMA_API_KEY)
📚 Context: 0/256k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:main • updated just now
⚙️ Runtime: direct · Think: off
🪢 Queue: collect (depth 0) nu apare nimic in footer iar comanda /compact imi da asta ⚙️ Compacted • Context ?/256k Pan ala update ul asta contextul crestea

deep pumiceBOT Mar 9, 2026, 9:18 AM

#

Asta explică perfect ce vezi: ești pe ollama/..., dar nu vine deloc usage (tokens) de la provider, de-aia:

/status rămâne blocat la Context: 0/256k
nu apare nimic în footer la /usage tokens
/compact poate rula, dar context-ul rămâne ?/256k fiindcă nu are din ce să calculeze

La Ollama, token tracking se bazează pe câmpurile din răspuns (prompt_eval_count / eval_count). Când OpenClaw e configurat pe Ollama OpenAI-compat (/v1 + api: "openai-completions") sau printr-un proxy, de multe ori câmpurile astea lipsesc → usage devine 0.

Fix-ul cel mai probabil (remote/proxy Ollama):

Verifică dacă ai models.providers.ollama.baseUrl cu /v1 sau api: "openai-completions".
Dacă da, schimbă pe native Ollama API:

{
  models: {
    providers: {

#

      ollama: {
        baseUrl: "http://<host>:11434", // FĂRĂ /v1
        api: "ollama"
      }
    }
  }
}

Docs: https://docs.openclaw.ai/providers/ollama (are warning explicit “no /v1”).

Apoi restart la gateway și testezi iar /status + /usage tokens.

Dacă trebuie să rămâi pe `/v1` (OpenAI-compat)

Încearcă să dezactivezi streaming pe model (altfel multe servere nu trimit usage în stream):

#

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://<host>:11434/v1",
        api: "openai-completions",
        models: [
          {
            id: "qwen3.5:cloud",
            name: "qwen",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 256000,
            maxTokens: 4096,

#

            params: { streaming: false }
          }
        ]
      }
    }
  }
}

Întrebare rapidă ca să confirm:

Poți să dai paste doar la secțiunea ta din config pentru models.providers.ollama (fără chei secrete)? Mai ales baseUrl și api. Dacă văd /v1 acolo, e 99% cauza.

blazing pier Mar 9, 2026, 9:45 AM

#

Am testat ce mi-ai zis - config-ul meu e:

JSON

{
"baseUrl": "http://192.168.1.102:11434/v1",
"api": "openai-completions"
}

Dar când am schimbat pe API nativ (fără /v1 + api: "ollama") am primit HTTP 404 pe toate modelele.

Motiv: 192.168.1.102 nu e Ollama local - e Ollama Cloud Proxy care vorbește DOAR OpenAI-compat API.

Întrebare: Cum facem token tracking să meargă cu Ollama Cloud providers? Pentru că cloud proxy-ul nu trimite usage tokens prin /v1 indiferent dacă streaming e on sau off.

Modelele afectate: qwen3.5:cloud, minimax-m2.1:cloud, etc. Toate arată Context: 0/256k mereu.

deep pumiceBOT Mar 9, 2026, 9:47 AM

#

Dacă proxy-ul tău OpenAI‑compat nu trimite deloc usage (nici în non‑stream), atunci în momentul ăsta OpenClaw nu are de unde să știe câți tokens au fost folosiți → /status rămâne la 0 și /usage tokens nu are ce footer să afișeze. Nu e ceva ce putem “repara” doar din config, e o limitare de date: fără usage, nu există token tracking real.

Ce putem face practic:

1) Confirmare rapidă: există vreun token count în răspuns?

Dacă poți, fă un request de test către proxy (non‑stream) și uită‑te dacă răspunsul conține unul din:

usage: { prompt_tokens, completion_tokens, total_tokens } (OpenAI standard)
sau orice alternativ (ex: prompt_eval_count, eval_count, etc.)

Dacă ai un sample JSON response (redactezi content dacă vrei), dă-mi paste aici. Dacă proxy-ul trimite token counts sub alte chei, OpenClaw poate fi patch-uit să le recunoască (dar asta înseamnă fix în cod).

2) Dacă răspunsul chiar nu conține nimic (cel mai probabil)

Atunci ai doar opțiuni de workaround:

Proxy fix (recomandat): să adauge el usage în răspuns (măcar aproximativ). OpenAI‑compat “corect” include usage în non‑stream, iar multe servere îl pot calcula.
- OpenClaw știe deja să citească prompt_tokens / completion_tokens / total_tokens.

#

Accept “unknown tokens”: practic token tracking & auto-compaction “by threshold” nu vor funcționa corect pe providerul ăsta. Manual /compact poate să meargă, dar /status n-are cum să arate corect “Context used”.
Folosești un backend care raportează usage (Ollama nativ /api/chat, vLLM/llama.cpp cu usage, OpenAI/Anthropic API, etc.) pentru sesiunile unde vrei tracking.

3) Ce e totuși bug/UX în OpenClaw aici

Faptul că /status îți arată 0/256k e înșelător — ar trebui să fie mai degrabă ?/256k când nu există usage. Asta merită issue.

Te rog deschide un GitHub issue

Include:

versiunea: 2026.3.8 (3caab92)
provider config (cum ai pus aici)
1 sample response JSON de la proxy (sau confirmare că nu are usage deloc)
output-ul /status + /usage tokens (că nu apare footer)

Issue: https://github.com/openclaw/openclaw/issues

Dacă îmi dai un sample response de la proxy, îți pot spune imediat dacă e “nu există usage deloc” (doar proxy fix/feature) sau “există, dar pe alte chei” (patch simplu în OpenClaw ca să-l parseze).

blazing pier Mar 9, 2026, 9:58 AM

#

Am testat cu curl. Răspunsul proxy-ului NU are câmp usage deloc!

{"id":"chatcmpl-171","object":"chat.completion",...}
// No "usage" field anywhere

Deci OpenClaw nu are de unde să citească tokeni.

Întrebări:

Putem patch-ui OpenClaw să afișeze ?/256k când lipsește usage (nu 0/256k care e misleading)?
Deschid GitHub issue pentru UX fix?
Trebuie vorbit cu maintainer-ul Ollama Cloud să adauge usage în răspunsuri?

deep pumiceBOT Mar 9, 2026, 9:59 AM

#

Da — ai diagnosticat corect: fără usage în răspunsul OpenAI‑compat, OpenClaw nu are ce să “numere”.

1) Putem patch-ui OpenClaw să afișeze `?/256k` când lipsește usage?

Da, și chiar ar fi un UX fix bun.

Acum /status ajunge să afișeze 0/256k pentru că în src/auto-reply/status.ts (în buildStatusMessage) se face fallback la 0 când nu există counters:

let totalTokens = entry?.totalTokens ?? (entry?.inputTokens ?? 0) + (entry?.outputTokens ?? 0);

Iar formatter-ul știe deja să arate ? dacă primește null/undefined (vezi formatTokens() din același fișier). Deci fix-ul e să nu mai “inventăm 0” când nu avem date, ci să păstrăm “unknown”.

Un loc și mai “corect” de fix e și în src/commands/agent/session-store.ts (updateSessionStoreAfterAgentRun): dacă nu există usage non‑zero, să marcheze token snapshot ca necunoscut (ex: totalTokensFresh=false și să nu lase totalTokens=0 rămas din /new).

2) Deschizi GitHub issue pentru UX fix?

Da, merită 100%. Include exact ce ai aici:

#

versiune 2026.3.8 (3caab92)
provider config (baseUrl: .../v1, api: openai-completions)
exemplu curl response fără usage
output /status (cu 0/256k) + mențiunea că e misleading

Link: https://github.com/openclaw/openclaw/issues

3) Trebuie vorbit cu Ollama Cloud Proxy maintainer să adauge usage?

Da — asta e singura cale să ai token tracking real + auto-compaction “by threshold” pe un OpenAI‑compat backend.

Le poți cere să adauge în response standardul OpenAI:

"usage": { "prompt_tokens": X, "completion_tokens": Y, "total_tokens": X+Y }

Fără asta, orice soluție din OpenClaw va fi doar estimare (care e posibilă, dar mai complicată și model-dependent).

#

Dacă vrei, îți formulez textul pentru issue (OpenClaw) + pentru request-ul către provider-ul proxy (Ollama Cloud).

blazing pier Mar 9, 2026, 10:03 AM

#

ok

deep pumiceBOT Mar 9, 2026, 10:04 AM

#

Ți-am pregătit textul pentru ambele (OpenClaw issue + request către Ollama Cloud Proxy). Copiază-le și ajustează ce vrei.

A) GitHub issue (OpenClaw) — `/status` arată `0/ctx` când usage lipsește (misleading)

Title:
/status shows Context: 0/… when provider returns no usage (should show ?/… / unknown)

Body:

### Problem
After updating to OpenClaw 2026.3.8, `/status` always shows:

`📚 Context: 0/256k (0%)`

even after multiple turns. `/usage tokens` shows no footer, and `/compact` shows `Context ?/256k`.

#

This is misleading: the provider does not return any token usage, so OpenClaw should display `?/256k` (unknown) rather than `0/256k`.

### Version
OpenClaw 2026.3.8 (3caab92)

### Model/provider setup
Using an OpenAI-compatible proxy that does NOT return `usage` in responses.

Provider config:
```json
{
  "baseUrl": "http://192.168.1.102:11434/v1",
  "api": "openai-completions"
}

#


Model example: `ollama/qwen3.5:cloud` (same behavior for multiple `*:cloud` models)

### Evidence
- `curl` to proxy returns `object: "chat.completion"` JSON with **no `usage` field anywhere** (non-stream as well).
- Therefore OpenClaw cannot read tokens.

### Expected behavior
When token usage is missing:
- `/status` should show `Context: ?/256k` (or `unknown/256k`) instead of `0/256k (0%)`.
- Percent used should be unknown (not 0%).
- (Optional) session store should not keep `totalTokens=0` as a “fresh” value after turns without usage.

### Actual behavior
- `/status`: `Context: 0/256k (0%)` permanently

#

- `/usage tokens`: no footer
- `/compact`: `Context ?/256k`

### Suggested fix direction
`src/auto-reply/status.ts` currently falls back to `0` when token counters are missing:
```ts
let totalTokens = entry?.totalTokens ?? (entry?.inputTokens ?? 0) + (entry?.outputTokens ?? 0);

The formatter already supports ? when total is null/undefined. Consider treating missing usage as unknown (null) instead of 0, and/or clearing totalTokensFresh when a turn completes with no usage.


Issue link: https://github.com/openclaw/openclaw/issues

---

## B) Request către “Ollama Cloud Proxy” maintainer — adăugați `usage` în răspuns

#

Subject / Title:
Please add OpenAI-compatible "usage" fields (prompt_tokens/completion_tokens/total_tokens)

Message:

We are using your OpenAI-compatible endpoint (`/v1/chat/completions`). Responses contain no `usage` field at all (even in non-stream mode).

This breaks token tracking and context/compaction UX in clients like OpenClaw, which rely on standard OpenAI usage fields.

Could you please add the standard OpenAI response field:
```json
"usage": {
  "prompt_tokens": <int>,
  "completion_tokens": <int>,
  "total_tokens": <int>
}

#


If streaming is supported, also consider supporting `stream_options: { "include_usage": true }` and emitting usage in the final chunk (OpenAI behavior).

We don’t need perfect accounting/costing — just token counts so clients can show context usage and trigger compaction reliably.

Dacă vrei, îți adaptez textele în engleză “mai formală” sau “mai scurtă”, depinde unde le trimiți.

blazing pier Mar 9, 2026, 10:09 AM

#

o sa intru pe discordul lor

deep pumiceBOT Mar 9, 2026, 10:10 AM

#

Sună bine. Pe Discord-ul lor, cel mai util e să întrebi direct dacă pot adăuga în response-ul /v1/chat/completions câmpul OpenAI standard:

usage.prompt_tokens
usage.completion_tokens
usage.total_tokens

(sau suport pentru stream_options: { include_usage: true }).

Dacă îți răspund ceva de genul “avem X field alternativ” / “nu suportăm usage”, dă paste aici și vedem ce workaround merită (sau dacă e cazul de issue doar pe OpenClaw pentru ?/ctx UX).

blazing pier Mar 9, 2026, 10:42 AM

#

Update: Am testat cu curl și Ollama Cloud CHIAR TRIMITE usage în răspuns:

Fields: ['id', 'object', 'created', 'model', 'system_fingerprint', 'choices', 'usage']
Usage present: True

Deci problema e că
OpenClaw 2026.3.8 nu parsează/citește câmpul usage din răspunsurile Ollama Cloud.

deep pumiceBOT Mar 9, 2026, 10:43 AM

#

Asta schimbă situația: dacă răspunsul non‑stream chiar are usage, atunci nu e “providerul nu trimite usage”, ci e foarte probabil una din astea:

OpenClaw folosește streaming către proxy-ul tău, iar în streaming proxy-ul nu include usage (sau OpenClaw nu îl cere / nu îl procesează).
În 2026.3.8 există un guard care pentru endpoint-uri non‑OpenAI native setează supportsUsageInStreaming=false (ca să evite “usage-only chunks” care sparg parserele). Asta poate face ca usage din stream să fie ignorat.

Workaround imediat (de test, fără patch)

Setează pe model params: { streaming: false } (pe model entry-ul folosit prin proxy) și restart la gateway.
Pe non‑stream, dacă proxy-ul trimite usage, OpenClaw ar trebui să înceapă să umple counters și /status nu mai rămâne la 0.

Docs (exact cazul ăsta, OpenAI‑compat Ollama):
https://docs.openclaw.ai/providers/ollama#legacy-openai-compatible-mode

De ce cred că e streaming-related

În OpenClaw există cod care, pentru openai-completions pe endpoint-uri non-native, forțează:

supportsDeveloperRole: false
supportsUsageInStreaming: false

#

Fișier: src/agents/model-compat.ts (comentariul zice explicit că “stream usage chunks” sunt OpenAI-native și pot strica parserele pe backends compat).

Asta se potrivește cu “în curl (non-stream) văd usage, dar OpenClaw nu îl vede” dacă OpenClaw face stream.

Ce să pui în GitHub issue (acum e mult mai clar)

Da, deschide issue, dar acum focus-ul e:

“OpenClaw doesn’t record token usage from OpenAI-compatible providers even when responses include usage (at least in non-stream). In streaming, usage is disabled/ignored for non-native endpoints → /status stuck at 0.”
Include: config provider + faptul că curl (non-stream) returnează usage.

Dacă vrei, ca să nu bâjbâim: poți să dai paste la config-ul modelului pentru unul din *:cloud (doar partea cu params, dacă există) ca să văd dacă rulezi streaming acum. În 2 minute îți zic exact unde să pui streaming:false ca să fie luat în calcul.

blazing pier Mar 9, 2026, 10:45 AM

#

Am încercat params: { streaming: false } dar OpenClaw 2026.3.8 respinge config-ul:

Invalid config at /root/.openclaw/openclaw.json:

models.providers.ollama.models.0: Unrecognized key: "params"

Schema din 2026.3.8 nu acceptă
params la nivel de model.

Cum pot dezactiva streaming în 2026.3.8? Există altă cale (global, la agent default, etc.)?

deep pumiceBOT Mar 9, 2026, 10:47 AM

#

Corect — în 2026.3.8 params nu e acceptat în models.providers.<id>.models[]. Acolo ai doar catalog (id/name/cost/contextWindow/compat etc). Parametrii runtime (inclusiv streaming on/off) se pun în agent model overrides, adică agents.defaults.models[...].

Cum dezactivezi streaming în 2026.3.8 (per model)

Pune streaming: false aici:

{
  agents: {
    defaults: {
      model: { primary: "ollama/qwen3.5:cloud" },

      models: {
        "ollama/qwen3.5:cloud": { streaming: false },
        "ollama/minimax-m2.1:cloud": { streaming: false }
      }
    }

#

}
}

Cheia din map e exact model ref-ul provider/model.

După asta: restart la gateway → trimite un mesaj → /status ar trebui să înceapă să arate context > 0 (și /usage tokens să prindă footer), dacă proxy-ul trimite usage în non-stream (cum ai văzut la curl).

Atenție (important): `agents.defaults.models` devine allowlist

Dacă până acum nu aveai agents.defaults.models, adăugarea lui înseamnă că /model și selecția de modele vor fi limitate la ce listezi acolo.
Dacă folosești mai multe modele, trebuie să le adaugi și pe ele în map (măcar ca entry gol/alias), altfel nu vor mai fi “permise”.

De ce asta ajută

Pe openai-completions, streaming-ul e exact zona unde compat-ul poate să nu transporte usage (sau e dezactivat pentru endpoint-uri non-OpenAI native). Forțând non-stream, ai cele mai mari șanse să primești usage consistent și să se actualizeze token counters.

Dacă vrei, dă-mi paste la secțiunea ta existentă agents.defaults (doar partea cu model / models, fără secrete) și îți spun exact cum s-o aranjezi ca să nu-ți blocheze alte modele.

blazing pier Mar 9, 2026, 10:49 AM

#

Perfect! Înțeleg acum. Hai să încerc varianta cu agents.defaults.models.

Configul meu actual:

JSON

"agents": {
"defaults": {
"model": {
"primary": "ollama/minimax-m2.1:cloud",
"fallbacks": ["ollama/minimax-m2.1:cloud", "ollama/qwen3.5:cloud"]
}
// NU am "models" map aici
}
}

Pot să adaug doar:

JSON

"models": {
"ollama/qwen3.5:cloud": { "streaming": false },
"ollama/minimax-m2.1:cloud": { "streaming": false }
}

Întrebare: Dacă nu listez celelalte modele (deepseek, kimi, etc.) în agents.defaults.models, le mai pot folosi manual sau devin indisponibile?

deep pumiceBOT Mar 9, 2026, 10:51 AM

#

Da — dacă adaugi agents.defaults.models, atunci devine allowlist pentru:

/model (picker + /model <ref>)
session overrides (adică “folosesc manual modelul X din chat”)

Asta înseamnă:

Dacă pui în agents.defaults.models doar cele 2 modele Ollama Cloud, atunci deepseek/kimi/etc nu le vei mai putea selecta manual prin /model (îți va da “Model … is not allowed”), chiar dacă ele există în models.providers.

Ce să faci ca să nu pierzi accesul la celelalte modele

Le adaugi și pe ele în agents.defaults.models, dar pot fi entry-uri “goale” (fără alias/params/streaming):

agents: {
  defaults: {
    model: {

#

      primary: "ollama/minimax-m2.1:cloud",
      fallbacks: ["ollama/qwen3.5:cloud"]
    },
    models: {
      // cele pentru care vrei non-stream (ca să prinzi usage)
      "ollama/minimax-m2.1:cloud": { streaming: false },
      "ollama/qwen3.5:cloud": { streaming: false },

      // celelalte modele pe care vrei să le poți alege manual
      "openrouter/deepseek-r1": {},
      "openrouter/kimi-k2": {},
      "anthropic/claude-sonnet-4-5": {}
      // ...etc (exact refs pe care le folosești tu)
    }
  }

#

{} e valid (schema permite obiect gol; e strict dar cu toate câmpurile opționale).

Rezumat

Da, poți adăuga doar cele două ca să testezi rapid — dar atunci restul devin indisponibile pentru /model.
Dacă vrei să le păstrezi disponibile manual, listează-le și pe ele în agents.defaults.models (măcar cu {}).

După ce pui asta + restart gateway: trimite un mesaj normal și verifică /status dacă începe să arate context > 0. Dacă tot rămâne 0, următorul pas e să vedem dacă OpenClaw chiar trimite stream=false către proxy (dar de obicei streaming:false pe model rezolvă fix cazul ăsta).

blazing pier Mar 9, 2026, 10:58 AM

#

Update final: După aplicat streaming: false + restart:

/usage tokens arată: ⚙️ Usage footer: tokens. dar footer-ul e GOL (niciun număr).

Deci OpenClaw PARSEAZĂ usage, dar nu extrage valorile corect. Parser-ul are un bug.

Întrebare: Există logging sau debug mode să vedem ce primește OpenClaw de la Ollama Cloud? Sau direct fix în 2026.3.9?

deep pumiceBOT Mar 9, 2026, 10:59 AM

#

Două posibilități aici, și le putem separa foarte rapid:

usage există, dar valorile sunt 0 (sau string-uri) → OpenClaw îl “vede”, dar hasNonzeroUsage() îl tratează ca “no usage”, deci nu actualizează counters.
usage are valori nenule, dar OpenClaw nu le extrage → bug de parsing / wiring.

Primul pas (cel mai rapid): poți da paste doar la obiectul `usage` din curl?

Exemplu (redactezi restul):

"usage": { ... }

Important: să văd cheile exacte și dacă valorile sunt numere sau string-uri.

Dacă e ceva gen {"prompt_tokens":0,"completion_tokens":0,"total_tokens":0} → problema e upstream: proxy-ul pune usage dar nu îl calculează.
Dacă e ceva gen {"prompt_tokens":"123" ...} → parsing-ul pică fiindcă OpenClaw așteaptă number, nu string.
Dacă e standard numeric nenul și tot nu apare → e bug în OpenClaw.

Logging ca să vezi exact ce primește OpenClaw de la proxy

#

Da, există. Pentru openai-completions cel mai util e PI raw chunk logging (înainte să fie “interpretate” evenimentele):

Din docs: https://docs.openclaw.ai/help/debugging

Setezi pe procesul gateway:

PI_RAW_STREAM=1
# opțional:
PI_RAW_STREAM_PATH=~/.pi-mono/logs/raw-openai-completions.jsonl

Apoi restart la gateway și verifici fișierul:
~/.pi-mono/logs/raw-openai-completions.jsonl

Acolo ar trebui să vezi payload-urile/chunks și dacă usage e prezent + cum arată.

Notă: logurile pot conține prompturi/PII — nu le posta integral public; dacă trebuie, postează doar liniile cu usage (scrub).

#

“direct fix în 2026.3.9?”

Nu pot promite fără changelog/issue, dar cu 1) usage object din curl sau 2) o linie relevantă din raw-openai-completions.jsonl, putem spune clar dacă:

e un bug de tip “values are strings” (fix mic în normalizeUsage), sau
e “usage always zero” (trebuie fix la proxy), sau
e “wiring bug” (fix în pipeline).

Dă-mi usage-ul din curl și îți spun imediat în care din cele 3 suntem.

blazing pier Mar 9, 2026, 11:02 AM

#

Usage din Ollama Cloud:

JSON

{
"prompt_tokens": 11,
"completion_tokens": 229,
"total_tokens": 240
}

───

Ce îi răspunzi lui Krill:

Usage object din curl:

JSON

{
  "prompt_tokens": 11,
  "completion_tokens": 229,
  "total_tokens": 240
}

Deci:

•  Cheile sunt corecte (prompt_tokens, completion_tokens, total_tokens)
•  Valorile sunt NUMERE (nu string-uri)
• Valorile sunt NON-ZERO (11, 229, 240)

deep pumiceBOT Mar 9, 2026, 11:05 AM

#

Super clar: usage-ul tău e exact în formatul pe care OpenClaw îl știe (prompt_tokens, completion_tokens, total_tokens, numere, non‑zero). Deci nu e “config”, e bug pe traseul:

HTTP response (are usage) → adapter (openai‑completions) → runResult.meta.agentMeta.usage → /usage tokens + /status

În momentul de față, OpenClaw își ia tokenii din runResult.meta.agentMeta.usage (nu parsează direct JSON-ul HTTP din gateway). Asta înseamnă că undeva în layer-ul OpenAI‑compat, usage nu e propagat în meta.

1) Logging/debug ca să vezi ce primește OpenClaw de la proxy

Da — și e exact pentru cazul ăsta.

Din docs: https://docs.openclaw.ai/help/debugging

A) Raw chunk logging (pi-mono) — cel mai util pt `openai-completions`

Setează env var pe procesul gateway și restart:

PI_RAW_STREAM=1

#

# opțional:
PI_RAW_STREAM_PATH=~/.pi-mono/logs/raw-openai-completions.jsonl

Apoi verifici:
~/.pi-mono/logs/raw-openai-completions.jsonl

Caută linia/chunk-ul final și vezi dacă usage apare acolo (și cum arată exact).

B) (opțional) Raw stream logging (OpenClaw)

OPENCLAW_RAW_STREAM=1
OPENCLAW_RAW_STREAM_PATH=~/.openclaw/logs/raw-stream.jsonl

2) “Fix în 2026.3.9?”

#

Nu pot garanta (fără release notes/issue), dar cu ce ai acum aș face direct GitHub issue: e reproductibil și ai deja dovada că upstream trimite usage corect.

În issue include:

versiune 2026.3.8
config provider (baseUrl, api)
usage object (ăla de 11/229/240)
și ideal 5-10 linii relevante din raw-openai-completions.jsonl (doar partea cu usage, fără prompt/PII)

Asta îi lasă pe maintainers să repare exact mapping-ul (cel mai probabil: parserul openai-completions nu atașează response.usage în agentMeta.usage / assistantMessage.usage).

Dacă pui aici (scrubbed) 1-2 evenimente din raw-openai-completions.jsonl în care apare usage, îți pot spune și mai precis dacă e:

“usage vine doar în final chunk și e ignorat”
sau “usage e prezent, dar într-un loc pe care OpenClaw nu-l citește”.

blazing pier Mar 9, 2026, 11:56 AM

#

Am scris pe github https://github.com/openclaw/openclaw/issues/40918

deep pumiceBOT Mar 9, 2026, 12:02 PM

#

Perfect — cu usage-ul ăsta (numeric, non‑zero, chei standard), OpenClaw ar trebui să-l prindă. Asta confirmă că problema e 99% “wiring” pe path-ul openai-completions din runtime (nu config/proxy).

Ce i-aș răspunde lui Krill / ce e util pentru issue:

1) `normalizeUsage()` deja suportă exact formatul ăsta

OpenClaw știe să parseze:

prompt_tokens (→ input)
completion_tokens (→ output)
total_tokens

Deci dacă /usage tokens rămâne fără numere, înseamnă că runResult.meta.agentMeta.usage ajunge undefined/zero (adică usage-ul nu e propagat până la meta).

2) Logging ca să vezi ce primește efectiv OpenClaw

Da, folosește PI raw chunk logging (docs: https://docs.openclaw.ai/help/debugging):

#

PI_RAW_STREAM=1
# opțional:
PI_RAW_STREAM_PATH=~/.pi-mono/logs/raw-openai-completions.jsonl

Restart gateway → apoi caută în:
~/.pi-mono/logs/raw-openai-completions.jsonl

Ținta e să găsești chunk-ul/răspunsul final și să confirmi:

există usage în payload-ul pe care îl vede runtime-ul, sau nu?

Dacă usage apare acolo dar tot nu ajunge în /usage tokens, atunci e clar bug de mapping intern.

3) Despre “streaming: false”

Un heads‑up: în 2026.3.8, există șanse mari ca agents.defaults.models["..."].streaming=false să nu fie încă wired până la stream: false în request (am văzut schema, dar nu e evident din cod că e aplicată). Deci e posibil să fii încă pe streaming, iar usage-ul tău (din curl cu stream:false) să nu fie comparabil 1:1 cu ce face OpenClaw.

#Context 0%

Fix-ul cel mai probabil (remote/proxy Ollama):

Dacă trebuie să rămâi pe /v1 (OpenAI-compat)

Întrebare rapidă ca să confirm:

1) Confirmare rapidă: există vreun token count în răspuns?

2) Dacă răspunsul chiar nu conține nimic (cel mai probabil)

3) Ce e totuși bug/UX în OpenClaw aici

Te rog deschide un GitHub issue

1) Putem patch-ui OpenClaw să afișeze ?/256k când lipsește usage?

2) Deschizi GitHub issue pentru UX fix?

3) Trebuie vorbit cu Ollama Cloud Proxy maintainer să adauge usage?

A) GitHub issue (OpenClaw) — /status arată 0/ctx când usage lipsește (misleading)

Workaround imediat (de test, fără patch)

De ce cred că e streaming-related

Ce să pui în GitHub issue (acum e mult mai clar)

Cum dezactivezi streaming în 2026.3.8 (per model)

Atenție (important): agents.defaults.models devine allowlist

De ce asta ajută

Ce să faci ca să nu pierzi accesul la celelalte modele

Rezumat

Primul pas (cel mai rapid): poți da paste doar la obiectul usage din curl?

Logging ca să vezi exact ce primește OpenClaw de la proxy

“direct fix în 2026.3.9?”

1) Logging/debug ca să vezi ce primește OpenClaw de la proxy

A) Raw chunk logging (pi-mono) — cel mai util pt openai-completions

B) (opțional) Raw stream logging (OpenClaw)

2) “Fix în 2026.3.9?”

1) normalizeUsage() deja suportă exact formatul ăsta

2) Logging ca să vezi ce primește efectiv OpenClaw

3) Despre “streaming: false”

Dacă trebuie să rămâi pe `/v1` (OpenAI-compat)

1) Putem patch-ui OpenClaw să afișeze `?/256k` când lipsește usage?

A) GitHub issue (OpenClaw) — `/status` arată `0/ctx` când usage lipsește (misleading)

Atenție (important): `agents.defaults.models` devine allowlist

Primul pas (cel mai rapid): poți da paste doar la obiectul `usage` din curl?

A) Raw chunk logging (pi-mono) — cel mai util pt `openai-completions`

1) `normalizeUsage()` deja suportă exact formatul ăsta