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

Usage pane (u) mixes traffic across inference servers now that sessions can switch servers

Abierto
  • ¿Algo no está bien?
#1,465 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
observability

Línea de trabajo

Start with cmd/agentop/tui/usage_pane.go and trace fetchUsage, readUsage, renderUsage, and cycleGroup; then read core/cost/usage/usage.go for how foldInto aggregates usage. Check cmd/agentop/servers.ForHost and its use in cmd/agentop/tui/server_route.go to understand host-to-server mapping. The issue lists design questions to settle; done means usage views distinguish server traffic and handle latency, tokens, and non-server hosts, with behavior defined for router-off and single-server cases.

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

Descripción

enhancement laptop

Summary

With the inference-router, an agent can be pointed at another server (S on the agents pane), and since #1435 a running session can be moved too, mid-conversation. The usage pane (u) did not change with it. It still adds up every request it sees, whichever server answered. So its headline figures (requests, errors, latency, tokens, cost) describe a mix of servers, and nothing on the pane says which part came from which server.

"Server" here means a named entry in the inference-router config (agentop server add <name> <url>), such as glm or ete-int. The router refuses two servers on one host, so a request's host identifies its server.

The problem

  1. No scope isolates a server. The pane can be scoped to all sessions, one session, or one agent (A). Before switching, an agent or a session meant one server. Now neither does: an agent's window holds its traffic to every server it was pointed at, and a moved session's chart joins its time on the old server to its time on the new one.

  2. A failing server is hidden by a healthy one. From a live laptop proxy, last 6 hours (/v1/usage?window=6h&group=host):

    host server requests errors
    ete-litellm.ai-models.vpc-int.res.ibm.com ete-int 823 23 (2.8%)
    litellm.cb.ete.res.ibm.com glm 6 3 (50%)
    mcp.ete-server.vpc-int.res.ibm.com (MCP, not a server) 16 6
    others 5 0

    The pane's headline says ERRORS 32 (3.8%). The fact that glm failed half its requests appears nowhere.

  3. Latency is one mean across all servers. Latency is kept per bucket and per agent, not per host (usage.Counts has no latency fields, and the pane prints "no breakdown for latency"). Different servers run different models on different hardware, so a mean across them describes no server. This is the number someone checks to decide whether to switch servers, and it cannot answer that question.

  4. Tokens are added across tokenizers. A GLM token and a Claude token are different units, so a total across both has no meaning. Cost is already guarded: a window that mixes billing units withholds the cost chart. Tokens have no such guard.

  5. g → by host comes close, but does not fill the gap:

    • It shows raw hostnames (41 columns for ete-int's host), not server names. The sessions and agents panes already name servers through servers.ForHost.
    • It counts every host, including MCP servers and other non-inference traffic, so it does not show inference servers alone.
    • It is not available under an agent scope, which takes over the one group axis /v1/usage has (fetchUsage forces GroupAgent). "How is my agent doing on glm" has no view.
    • Latency has no breakdown at all (point 3).

What a fix needs to decide

Questions to settle, not a design:

  • Is "server" a scope (like A), a grouping (like g), or both? A scope answers "how is glm doing"; a grouping answers "how do my servers compare".
  • Does the aggregator need latency per host, or per server? Both #1400 (alerts when a backend gets slower) and point 3 need per-server latency, so the answer probably serves both.
  • What does the pane show when the router is off, or has one server? (The sessions table hides its SERVER column in both cases.)
  • How should traffic to a host with no server be shown, such as a direct api.anthropic.com call or an agent the router does not route?
  • Should agentop cost get the same axis? Its ledger windows (today, month, 7d) group by endpoint but not by server name.

Pointers

  • Pane: cmd/agentop/tui/usage_pane.go (fetchUsage, readUsage, renderUsage), with grouping in cycleGroup.
  • Aggregation: core/cost/usage/usage.go (foldInto: byHost, byEndpoint, per-agent rings in Aggregator.agents).
  • Host-to-server mapping: cmd/agentop/servers.ForHost, used by sessionServerCell in cmd/agentop/tui/server_route.go.
  • Related: #1400 (per-backend performance baseline and alerts), #1435 (moving a running session).

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

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

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.