You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decide what else moves into packages/llm once a second gateway consumer exists #325
Follow-up from #93 (shared gateway client package), promised in PR #321. Deliberately deferred, not forgotten: it needs a second consumer to exist before the right shape is knowable.
#93 moved build_gateway_client into packages/llm but left the settings side in each service. retriever.config.Settings still owns:
llm_gateway_base_url (the computed field resolving LLM_GATEWAY_URL, else CLOUDFLARE_ACCOUNT_ID + CLOUDFLARE_GATEWAY_ID, else ValueError)
gateway_token_for(scope) (scoped-token lookup with fallback to the shared llm_gateway_token)
the gateway fields themselves (llm_gateway_token, llm_gateway_auth_header, the per-scope tokens)
GatewaySettings in packages/llm is a structural typing.Protocol describing that surface, not an implementation of it. So the second service to call the gateway must reimplement all three, which is the copy-paste #93 set out to prevent, one layer up.
This was the right call for #93: with one consumer, any shared base class would be designed against a sample size of one, and a pydantic settings mixin would have coupled the package to pydantic-settings for no present benefit. The question is genuinely open until a second service has real requirements.
Do this when a second service (biowriter, per ADR 0028, or petdata if it starts making model calls) lands its first gateway call. Resolve then:
Whether the shared piece is a pydantic-settings mixin, a plain resolver function taking the env values, or documentation plus the Protocol as-is.
Activity