Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add 9Router aggregator provider

Aperta
  • Qualcosa non va?
#103 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
api, authentication, desktop-dev

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
10
Fork
2
Merge medio
3h 22m
PR unite (30g)
87

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di egdev6/quorb

Tutte le issue di egdev6/quorb

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.