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

Add 9Router aggregator provider

Đang mở
#103 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ó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript

Hướng nghiên cứu

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.

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

Mô tả

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.
Ngôn ngữ chính
TypeScript
Star
10
Fork
2
Merge trung bình
16 phút
Pull request đã merge (30 ngày)
51

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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

Tất cả issue của egdev6/quorb

Issue tương tự

Thêm issue về TypeScript

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.