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

Add 9Router aggregator provider

Abierto
  • ¿Algo no está bien?
#103 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, authentication, desktop-dev

Línea de trabajo

The payload names no source files, so start with the existing NaN provider, which uses the same dashboard-login pattern, and the extra-account model it reuses. Check the 9Router endpoints POST /api/auth/login, GET /api/usage/stats and GET /api/usage/chart against a local instance. Done means a read-only aggregate orb with per-provider sub-orbs, tested against mocked responses. Wait for product review before starting, since the issue says it needs it.

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

Descripción

Provider / plan: 9Router — local self-hosted AI gateway (9router, decolua/9router). Runs at http://localhost:20128 and routes traffic across 40+ upstream providers.

What limits does it have? No fixed quota of its own; it aggregates the usage/cost of every upstream provider it routes to. 9Router already tracks requests, tokens and estimated cost per provider, over selectable periods (today, 24h, 7d, 30d, 60d, all), plus a daily time series.

Where can you see your usage today? In the 9Router dashboard (http://localhost:20128/dashboard › Statistics), which reads its own local SQLite store (~/.9router).

Does it have an official usage API? Not sure / undocumented. It exposes a local JSON API used by its own dashboard:

  • POST /api/auth/login → session cookie (auth_token, JWT, 24h)
  • GET /api/usage/stats?period=… → totals + byProvider / byModel breakdown
  • GET /api/usage/chart?period=… → daily series
  • GET /api/usage/providers → provider list

These are not documented as a public API and sit behind the dashboard auth guard, but the access pattern is the same one Quorb already uses for NaN (log in, store the session, read usage). For requireLogin: false dashboards they are readable with no session at all.

Problem to solve

For anyone who routes their AI traffic through 9Router, the usage and spending of the whole layer is invisible to Quorb. Quorb only sees the direct subscriptions/APIs it knows about, so there is no single place to watch the aggregated 9Router consumption.

Proposed solution

Add 9Router as an aggregator provider. Quorb reads 9Router's local usage API using a dashboard session (password login, stored in Windows Credential Manager, same as NaN), and shows:

  • one aggregate orb: period spend (optional budget bar), total tokens and number of active providers;
  • one sub-orb per upstream provider with spend in the period (auto-discovered from byProvider, ordered by cost, with an optional minimum-spend threshold so free models don't flood the strip);
  • the daily series in the detail panel.

The upstream ids are shown as extra accounts (nine_router:<id>), reusing the existing extra-account model; provider logos are taken from 9Router's own public/providers/ set.

Affected area: Application behavior

Scope and non-goals

In scope: read-only usage/cost from the local 9Router instance.

Non-goals: managing 9Router (providers, combos, routing), starting/stopping the gateway, writing anything to ~/.9router, or exposing 9Router's own /v1 endpoint.

Alternatives considered

  • Treating each upstream provider as a separate native provider in Quorb: rejected, it would duplicate dozens of integrations and lose the aggregation 9Router already provides.
  • Reading ~/.9router SQLite directly: rejected as more coupled to 9Router internals than its own dashboard API.

Pre-flight checks

  • I searched existing issues and found no duplicate.
  • I understand that this proposal requires product review before implementation.
Lenguaje dominante
TypeScript
Estrellas
10
Forks
2
Merge medio
16 min
PR fusionados (30 d)
51

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 egdev6/quorb

Todos los issues de egdev6/quorb

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.