• v2.3.0-ew-3 72bcd92ae5

    Bifrost v2.3.0-ew-3 (EW Fork)
    All checks were successful
    Docker Build / docker (push) Successful in 10m1s
    Docker Release / release (push) Successful in 8m27s
    Stable

    engel75 released this 2026-10-16 10:23:00 +02:00 | -4349 commits to 1.4.23-ew since this release

    Bifrost v2.3.0-ew-3 (EW Fork)

    Feature-Release auf 2.3.0-ew1 (8 Commits): EW als Base-Provider (Spec 13) — Partner betreiben Bifrosts EW-Features unter ihrem eigenen Provider-Namen.

    Änderungen

    • Custom Provider auf EW-Basis: "custom_provider_config": { "base_provider_type": "ew" } unter beliebigem Namen (z. B. acme) — Routing via acme/<model>, Einträge in /v1/models unter dem eigenen Namen (owned_by: "everyware"), eigene Key-Liste mit vollem ew_key_config (URL, ModelName, Capacity, AllowedRequests)
    • Alle EW-Features folgen dem Base-Typ: Response-Sanitizer (inkl. x-smg--Denylist), Entry-Lanes (Pro-Key-Capacity), RoutingInfo-Key-Gate, x-ewcs-Branding, Spec-09-Image-Edit-Gates (multipart-Passthrough, url/url[]-Input, dual mask), Per-Key-API-Toggles, Decisions via acme/<model>-Prefix
    • Kern-Fix: EWProvider.GetProviderKey() löst den Namen jetzt dynamisch auf (providerUtils.GetProviderName-Muster) — Key-Ziehung, Modell-Listen-Präfix und Identity-Felder folgen dem Custom-Namen statt hartcodet ew
    • UI: Keys-Form rendert die ew_key_config-Felder auch für EW-basierte Customs (API-Key-Guard unangetastet); Icons erben das Base-Provider-Icon (bereits vorhanden)

    Kompatibilität / Operator-Hinweise

    • Keine Breaking Changes, keine Migration, kein Config-Eingriff — der plain-ew-Provider verhält sich byte-identisch wie bisher (Vertrag, Spec-Sektion 7, durch 6 Test-Pins + Live-Smoke abgesichert)
    • Plain ew und Custom-Namen laufen parallel (eigene Queues, eigene Keys, eigene Lanes)
    • Randfall dokumentiert: bare /v1/systemone ohne Model-Prefix routet weiterhin auf das Literal ew — Partner-Namen nutzen den expliziten Prefix (acme/<model>)
    • Harness Case 8.5.V (FEATURE="custom_naming", live-only) verlangt Operator-Config mit beiden Providern

    Qualität

    • make build LOCAL=1, ew/openai/handlers-Suiten grün, go vet clean; neue Tests: GetProviderKey-Semantik, createBaseProvider-Custom-Pin, Gate-Tabelle (8 Cases), Custom-URL-Input-Akzeptanz + Standard-Provider-Rejection-Regression
    • Benchmark: GetProviderKey 0 allocs/op auf beiden Pfaden (plain 1.0 ns, custom 2.1 ns) — Common Case zahlt nichts
    • Gotcha-20-Pin (payload_ordering_test.go) unberührt und grün; Harness 8.5.V in beiden 8.5-Positionen, augment/filter validiert (6 Requests custom_naming / 2 sanitization)
    • Unabhängige Verifikation: Backward-Compat-Vertrag durch Reviewer bestätigt, Live-Smoke mit plain-ew + Custom-Config (Routing, per-Key-Dialing, Parallelbetrieb per curl belegt)

    Details: specs/13-ew-as-base-provider.md
    Image: forge.engelmann.me/engel75/bifrost:v2.3.0-ew-3

    Downloads