Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng Phù hợp với người mới
  • Có gì không ổn?
#1,191 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
88/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu trong core/session/store.go tại titleCandidate và fold của Store.Append, sau đó kiểm tra trường MaxTokens hiện có trong core/pipeline/extensions.go. Xác minh rằng ứng viên tiêu đề xem xét siêu dữ liệu suy luận trước nội dung tin nhắn. Hoàn thành khi một completion bị giới hạn ở một token không thể nhận là tiêu đề phiên, trong khi các prompt ngắn thông thường vẫn có thể.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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]

Ngôn ngữ chính
Go
Star
21
Fork
43
Merge trung bình
14 giờ 26 phút
Pull request đã merge (30 ngày)
239

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của rossoctl/cortex

Tất cả issue của rossoctl/cortex

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.