Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#507 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
78/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
sqlite, typescript
Domaine
backend, database

Piste de recherche

Lisez packages/local-runtime-v2/src/service/session-system/owner.ts autour de modelIdentity() et suivez comment son résultat parvient aux lignes d’utilisation dans pi-usage.ts. Vérifiez la forme projetée du modèle dans packages/local-runtime-v2/src/service/turn-system/agent-host/assembly-context.ts ; l’issue identifie l’incohérence du champ model_id. Confirmez la correction en exécutant le chemin d’enregistrement de l’utilisation v2 et en vérifiant que les nouvelles lignes de local_runtime_token_usage contiennent le modèle.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
TypeScript
Étoiles
2k
Forks
259
Merge moyen
9 h 22 min
PR mergées (30 j)
105

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de MiniMax-AI/minimax-code

Toutes les issues de MiniMax-AI/minimax-code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.