Skip to content

Reduce to the declarative provider, as the upstream review asked - #4

Merged
Lookoff-AIMLAPI merged 2 commits into
mainfrom
chore/aimlapi-declarative-only
Sep 2, 2026
Merged

Reduce to the declarative provider, as the upstream review asked#4
Lookoff-AIMLAPI merged 2 commits into
mainfrom
chore/aimlapi-declarative-only

Conversation

@Lookoff-AIMLAPI

Copy link
Copy Markdown
Member

Summary

Reduces this fork's main to what the upstream review asked for:

could you make it just use the api key one, that would be simpler and cleaner I think for this. Declarative only - should be a much smaller change

Upstream PR aaif-goose/goose#11758 is open from this fork's main, so merging this updates that PR in place.

Effect on the upstream PR

before after
files 13 4
lines +801 +75

What remains:

File
crates/goose-providers/src/declarative/definitions/aimlapi.json the provider definition
crates/goose-providers/src/declarative.rs one line in expose_declarative_providers!
crates/goose/src/providers/init.rs registry wiring test
documentation/docs/getting-started/providers.md one docs row

Authentication is a plain AIMLAPI_API_KEY. The headers block follows the convention the other routers here already use — http-referer and x-title identifying goose — plus the two headers AI/ML API reads to attribute traffic.

Removed

The browser sign-in flow and everything that reached it: the signup_aimlapi module with its loopback server and HTML templates, the example, the config module wiring, and the setup-menu entry with its handler. The setup menu therefore returns to its original ordering and labels.

The flow is not lost — it is kept on pkce/agent-signin (e55acdbd), where it stays available to this fork.

Also trimmed

The registry wiring test additionally asserted where AI/ML API lands in the sorted provider list. That is not what a wiring test is for, it is brittle against any future provider sorting nearby, and asserting our own placement in someone else's suite is not ours to do. What is left mirrors test_gondola_provider_registry_wiring exactly.

Verification

  • cargo build -p goose-cli — succeeds. (--no-default-features minus local-inference, which needs libclang for bindgen and is unrelated to this change.)
  • cargo test -p goose --lib providers::init10 passed, including test_aimlapi_provider_registry_wiring.
  • cargo fmt --check — clean.
  • Live: goose run on this build answers on aimlapi openai/gpt-5-5 with only AIMLAPI_API_KEY set — no sign-in flow involved.
  • All 8 bundled model ids were checked against the live catalog; none are stale.

Lookov and others added 2 commits September 2, 2026 15:45
The upstream review asked for the API-key path only: "could you make it
just use the api key one ... Declarative only - should be a much smaller
change".

Removes the browser sign-in flow and everything that reached it — the
signup_aimlapi module with its loopback server and templates, the example,
the config module wiring, and the setup-menu entry with its handler. The
menu therefore returns to its original ordering as well.

What remains is the declarative provider: the definition, its line in
expose_declarative_providers!, and the docs row. Authentication is a plain
AIMLAPI_API_KEY.

The removed flow is kept on the pkce/agent-signin branch, where it stays
available for this fork if it is ever wanted again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The test also asserted where "AI/ML API" lands in the sorted provider
list. That is not what a wiring test is for, it is brittle against any
future provider whose display name sorts nearby, and asserting our own
placement in someone else's suite is not ours to do.

What is left mirrors test_gondola_provider_registry_wiring exactly:
the provider resolves from the registry, and its name, default model and
API key config are what the definition declares.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Lookoff-AIMLAPI
Lookoff-AIMLAPI merged commit d7a66af into main Sep 2, 2026
11 checks passed
@Lookoff-AIMLAPI
Lookoff-AIMLAPI deleted the chore/aimlapi-declarative-only branch September 2, 2026 10:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants