Add 9Router aggregator provider
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
- Lĩnh vực
- api, authentication, desktop-dev
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/byModelbreakdownGET /api/usage/chart?period=…→ daily seriesGET /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
~/.9routerSQLite 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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của egdev6/quorb
-
status:approved type:bug
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
egdev6/quorb#109 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
odd type:feature
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 1 ngày
-
odd type:feature
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 1 ngày
-
odd type:feature
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
odd type:chore
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 22/100
egdev6/quorb#105 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
vercel/streamdown#673 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
docs(stream-protocol): document messageMetatadata on start/finish and the message-metadata chunkĐang mởfactory-active task-identify-harness-labels-done task-identify-issue-type-done
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
vercel/ai#23375 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
agilepathway/label-checker#721 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
CLI Empathy needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
chromaui/chromatic-cli#1524 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày