Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Served session title can be captured by a Claude Pro quota probe ("quota")

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#1,191 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
88/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend

Línea de trabajo

Comienza en core/session/store.go, en titleCandidate y el fold de Store.Append, y revisa después el campo MaxTokens existente en core/pipeline/extensions.go. Verifica que el candidato de título considere los metadatos de inferencia antes que el contenido del mensaje. Se considera hecho cuando una completion limitada a un token no puede reclamar un título de sesión, mientras que los prompts breves ordinarios sí pueden.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

A Claude Pro account's quota probe can claim a session's served title permanently. On a
178-event session the title is quota — the entire content of a one-token completion Claude Code
fires to check quota, which happened to be the first event through the proxy. Under the fold's
first-wins rule that named the session for the rest of its life.

quota is a poor title in general, but it is specifically poor for a Claude Pro account, where
this probe goes to api.anthropic.com on the same session id as the conversation. An account routed
through LiteLLM does not produce this shape at all, so the defect is invisible on those setups and
shows up only for direct-Anthropic (Pro/Max) users.

Observed

Session 0fac85c4-…, 178 events, title: "quota". The two events that carry it are seq 1 and 2 —
the first two events in the session:

seq=1 outbound POST api.anthropic.com/v1/messages
  model=claude-haiku-4-5-20251001  maxTokens=1  messages=1
  messages[0] = {role: user, content: "quota"}      # 5 bytes, the whole message

seq=2 (the response)
  completion="#"  finishReason=max_tokens  outputTokens=1  promptTokens=8

The rest of the session is 40 claude-opus-5-5 events. Model histogram: 4 haiku, 40 opus.

The fold behaves exactly as designed — there is no /rename and no <user_query> anywhere in this
session, so rankUserMsg (2) is the best rank any event offers, and seq 1 wins it first. Replaying
titleCandidate + the Store.Append fold against the live event stream reproduces quota from
seq 1, message 0, rank 2.

The harvest does not cover this session — ~/.cortex/session-metadata.json has no entry for
this id. So abctl's harvest-wins precedence has nothing to override with, and quota is what an
operator actually sees in the TITLE column.

Why titleFrom cannot catch it today

titleFrom already discards machinery it can recognise from the string: a <transcript> envelope,
a message that is nothing but <system-reminder> blocks, a /rename or <user_query> envelope
with a blank body. But a one-word user message is indistinguishable from a genuinely terse human
prompt at the string level, and titleFrom sees only content. Nothing about "quota" as a
string says it is machinery. Rejecting short messages would discard real prompts and is not the
answer.

Suggested server-side fix

The discriminating signal is not in the string, it is in the request metadata the event already
carries — and maxTokens is the decisive one:

  • MaxTokens == 1 — a completion capped at one token cannot be a conversational turn. It is a
    liveness/quota/classification probe by construction. Both quota events have maxTokens: 1 and
    finishReason: max_tokens with outputTokens: 1.
  • Supporting signals, weaker on their own: len(messages) == 1 on an event at seq 1 of a long
    session, and a model that differs from the session's dominant model (haiku against opus here).
    Neither should be needed if maxTokens is used, and the model comparison in particular is
    fragile — it needs session state the candidate extraction does not have and would misfire on a
    legitimately haiku-only session.

Cheapest correct change: have titleCandidate return rankNone when
e.Inference.MaxTokens != nil && *e.Inference.MaxTokens <= 1, before it scans messages.

Two things make this cheap:

  • MaxTokens *int is already on pipeline.InferenceExtension (core/pipeline/extensions.go:156),
    so there is no wire or schema change.
  • titleCandidate(&event) already takes the whole event (core/session/store.go:340), so it has
    the field in hand — no signature change, and the check is one pointer test in front of the scan
    it already does, i.e. strictly cheaper than today on exactly these events.

It should be <= 1 rather than == 1 for the same defensive reason the rest of this file uses
(a 0 or negative value is not a conversation either), and it must run before the message scan so
a probe never claims a rank at all — under first-wins, a rank claimed is a title locked in.

Scope note

This is server-side only (core/session). abctl's harvest-wins fallback happens to mask it on
sessions the harvester can name, but as this session shows, it does not always have one — so the
fix belongs in the store, not the client.

Assisted-By: Claude (Anthropic AI) [email protected]

Lenguaje dominante
Go
Estrellas
18
Forks
42
Merge medio
12 h 20 min
PR fusionados (30 d)
229

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rossoctl/cortex

Todos los issues de rossoctl/cortex

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.