📈 GH Trending Explorer 🎲 Surprise me

← all repos

www222fff / muse2api

git clone https://github.com/www222fff/muse2api.git 0.2.0 · 18d ago

OpenAI-compatible async gateway for muse.ai with pluggable drivers (mock / browser-CDP / http)

+1
stars, 24h · #9,510
+~7
stars, 7 days · #10,158
+146
stars, 30 days · #3,684
150
★ total · +5% this week
41
forks · 0 open issues

Star history (as recorded here)

2026-10-20 · 145 ★ 2026-10-22 · 150 ★
LanguagePython
LicenseMIT
Created2026-09-27 (25d ago)
Last pushtoday
Watchers0
OwnerUser

Links

README excerpt
muse2api 
 An async gateway that exposes the muse.ai web app as an OpenAI-compatible API 
---
## Contents
- Overview
- Status
- Architecture
- Project layout
- Quick start
- API examples
- Configuration
- Roadmap
- Contributing
- Disclaimer
- Star History
## Overview
muse2api turns muse.ai's chat, text-to-image and text-to-video features into standard OpenAI endpoints (`/v1/chat/completions`, `/v1/images/generations`, ...). Existing OpenAI SDKs and clients such as ChatGPT-Next-Web, LobeChat or Cherry Studio work by just changing their `base_url`.
The project focuses on **clean engineering and easy collaboration**:
- **Pluggable drivers**: how we reach upstream is abstracted behind a `MuseDriver` interface. There are currently a mock driver and a browser (CDP) driver, plus a reserved slot for a direct-protocol (HTTP) driver. They are fully independent of each other.
- **Strict layering**: the protocol layer, service layer, account pool and drivers each have a single responsibility and can be developed and tested on their own.
- **Fully async**: built on FastAPI + asyncio; the CDP client uses `websockets`, so no request ever blocks a thread.
- **Account pool**: multiple scheduling strategies, per-account concurrency limits, cooldown after failures, automatic removal of expired sessions, and automatic failover to another account.
- **Offline development**: the mock driver needs no account and makes no network calls, so front-end and protocol work can move forward independently.
## Status
> **v0.1, framework stage**: the architecture and basic features are fully written, but the test suite has not been run yet and nothing has been tested against a real muse.ai account.
| Module | Status | Notes |
|---|---|---|
| OpenAI protocol layer (chat streaming/non-streaming, images, videos, models) | ✅ Implemented | Multi-turn chat, system prompts, image input, model aliases |
| Account pool (scheduling / cooldown / invalidation / failover) | ✅ Implemented | `lru`, `round_robin` and `affinity` strategies |
| Background tasks (video) | ✅ Implemented | Create a task, then poll for the result; unfinished tasks are marked interrupted after a restart |
| Admin API (account CRUD, renewal, reset, status) | ✅ Implemented | |
| Mock driver | ✅ Implemented | Offline fake data |
| Browser driver (Chromium + CDP) | 🧪 Needs live testing | Full chat, image and video flows are written |
| Session renewal / keepalive | 🧪 Needs live testing | Plain HTTP, disabled by default |
| Direct HTTP protocol driver | 🚧 Reserved | Returns 501 |
| `/v1/images/edits` (reference images) | ✅ Implemented | Images are references for a new image; `mask` is rejected |
| `/v1/responses` | 🚧 Reserved | Returns 501 |
| Web console, cookie import extension, quota lookup | 🚧 Reserved | |
## Architecture
 [code] 
**How a chat request is handled**: the route resolves the model alias and merges the multi-turn `messages` into a single prompt, then hands it to the Gateway. The Gateway leases an account fro