aaif-goose / aaif-goose/goose

DaoXE as a declarative OpenAI-compatible provider

未关闭
#11,986 0 条评论 0 个 reaction 已指派 1 人 已被 @michaelneale 认领 在 GitHub 查看
主要语言
Rust
星标
54.2k
派生
6.2k
平均合并
3 天 2 小时
30 天内合并 PR
262

描述

**What problem would this solve?**

Goose users who already hold a DaoXE API key currently have to configure it through the generic OpenAI-compatible custom-provider path by hand. A declarative entry would let them pick it like any named provider — same as the existing entries for AIML API, OrcaRouter, TrustedRouter, OpenCode Zen and others in `crates/goose-providers/src/declarative/definitions/`.

**What would a good outcome look like?**

`goose configure` lists DaoXE among the declarative providers. Auth via `DAOXE_API_KEY` (Bearer), OpenAI engine. `dynamic_models` enabled — the live catalog is account-scoped and changes over time, so Goose reads `GET /v1/models` rather than trusting a hard-coded list (a small fallback list covers first-run UX before the request is made). Streaming supported.

**Possible approaches**

A single JSON definition following the existing schema — I had a working two-file implementation (definitions JSON + one line in `expose_declarative_providers`) up as PR #11920, which maintainers asked to route through an issue first, so here it is. That branch still exists (`seven7763:feat/daoxe-declarative-provider`, rebased on current main, full CI green) and I'm glad to reopen the PR against this issue or adjust scope/ownership/verification as you see fit.

**Additional context**

Disclosure: I'm affiliated with DaoXE (OpenAI-compatible multi-model gateway, https://daoxe.com). Happy to answer anything about the implementation or shape the definition differently — the maintainers' process doc asks for product-fit agreement here first, so no implementation until this reaches Ready.

- [x] I have verified this does not duplicate an existing feature request

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。