[Bug]: token usage rows always have model=NULL for local-runtime-v2 sessions (modelIdentity reads id, projected model carries model_id)

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#507 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
78/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
sqlite, typescript
Bereich
backend, database

Rechercherichtung

Lies packages/local-runtime-v2/src/service/session-system/owner.ts im Umfeld von modelIdentity() und verfolge, wie dessen Ergebnis die Usage-Zeilen in pi-usage.ts erreicht. Prüfe die projizierte Modellstruktur in packages/local-runtime-v2/src/service/turn-system/agent-host/assembly-context.ts; der Issue benennt die Abweichung beim Feld model_id. Bestätige den Fix, indem du den v2-Pfad zur Usage-Erfassung ausführst und überprüfst, ob neue Zeilen in local_runtime_token_usage das Modell enthalten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Product or interface

Desktop app (also affects CLI TUI / headless / ACP — all paths that record usage through local-runtime-v2)

Version

Desktop 3.1.3 (macOS); source analysis at main 9a93560 (v0.6.5)

Platform

macOS

OS version and architecture

macOS 26 arm64

Issue area

Other (local usage ledger / local_runtime_token_usage)

Steps to reproduce
  1. Use MiniMax Code desktop 3.1.3 (or any build recording usage via local-runtime-v2) for a normal coding session with a MiniMax model (e.g. minimax/MiniMax-M3.1-Flash).
  2. Inspect ~/.minimax/v2/sqlite/runtime-state.sqlite:
SELECT model, count(*) FROM local_runtime_token_usage GROUP BY model;
-- after upgrading to 3.1.3: every new row has model = NULL

On my machine: 1314 rows written by the previous version all have model = 'minimax/MiniMax-M3'; all 7 rows written after the 3.1.3 upgrade have model = NULL (session layout v2-final-dated-session, so they went through the v2 runtime).

Expected and actual behavior

Expected: the model column records the model used for each turn (as the v1 runtime path did, and as the model column, the idx_local_runtime_token_usage_model_ts index, and the group=model query path in usage/repo/drizzle.ts all imply).

Actual: rows written by local-runtime-v2 always have model = NULL.

Downstream impact: every tool that reads this table for statistics (including the built-in summarizeGroupBy('model') API, which falls back to coalesce(model, 'unknown')) can only show "unknown" for new sessions. See also cc-switch #7705 where a third-party importer hits the same thing ("mcode session 用量导入模型恒为 unknown").

Root cause analysis (source at main 9a93560)

The v2 write chain feeds modelIdentity() a model object whose keys can never match:

  1. packages/local-runtime-v2/src/service/turn-system/agent-host/assembly-context.ts — projectResolvedModel() returns { provider, model_id: resolved.id, context_window, max_tokens, … }. MODEL_ALLOWLIST (lines 42–58) contains model_id/modelId but no id key, so the projected object can never carry id.
  2. That object flows to executionModel (local-agent-host.ts:231) and then to the usage projector (committed-history-writer.ts:321 → owner.ts:697).
  3. packages/local-runtime-v2/src/service/session-system/owner.ts:802-808 — modelIdentity() reads Reflect.get(model, 'id') only. With the model_id-shaped object it always returns null, and pi-usage.ts writes model: null into local_runtime_token_usage.

modelIdentity() matches the pi framework's Model shape ({ id, provider, … }, third_party/pi-mono/packages/ai/src/types.ts:593), which is why the compat layer's modelIdentity(turn.model) calls still produce correct provider/id strings. Only the v2 projected shape is broken — the same function consumes two shapes and one of them silently degrades to null.

Additional notes:

  • Both files are unchanged since the initial import commit (c59cf53, 2026-09-18), so this is not a recent regression in the public history — it has been there since the first snapshot.
  • The assistant messages themselves carry the model (e.g. messages.jsonl entries have "model": "MiniMax-M3.1-Flash" keyed by the same turnId), so a fallback at committedPiUsageRows would also work.
Suggested fix (either or both)
// owner.ts
function modelIdentity(model: unknown): string | null {
  if (!model || typeof model !== 'object') return null;
  const provider = Reflect.get(model, 'provider');
  const id = Reflect.get(model, 'id') ?? Reflect.get(model, 'model_id') ?? Reflect.get(model, 'modelId');
  if (typeof provider === 'string' && typeof id === 'string') return `${provider}/${id}`;
  return typeof id === 'string' ? id : null;
}

or in pi-usage.ts committedPiUsageRows: fall back to the assistant message's own model field when input.model is null.

Before submitting
  • I have searched existing issues.
  • I have included my version and removed sensitive information.
Vorherrschende Sprache
TypeScript
Sterne
2.2k
Forks
281
Ø Merge
14 Std. 26 Min.
Gemergte PRs (30 T.)
38

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus MiniMax-AI/minimax-code

Alle Issues in MiniMax-AI/minimax-code

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.