[PierreLeGuen]

Part of nearai/infra#264. Base: main (it builds on #1233, which is merged).

Seven commits:

1. feat(models): store which organizations may use a model: the table and its repository.
2. feat(models): restrict unlisted models to organizations that hold a grant: the rules and every call site.
3. feat(admin): manage model access grants and publish them for gateways: the admin routes and the internal document.
4. test(e2e): cover per-organization model access.
5. fix(models): close the review findings on model access: see "Review round" below.
6. test(e2e): give the routes added on main a model access decision: see "Rebase onto main" below.
7. fix(models): close the second review round on model access: see "Second review round" at the end.

What and why

#1233 added isListed. It keeps a model out of the public catalogs, but anyone who knows the model's name can still call it if it has a provider.

This PR makes an unlisted model a restricted model. An organization can use it through this API only while it holds a grant. Everyone else gets exactly the answer a model that does not exist gets. Grants are (organization, model) pairs, managed by admins.

Example: model X is unlisted and organization A holds a grant. A can call X. Nobody else can, and nobody else can tell that X exists.

Access rules

• A listed model is open to everyone. Grants on it are kept but have no effect, so access can be prepared before a model is unlisted.
• An unlisted model is usable only by organizations that hold a grant.
• A grant counts only while both the organization and the model are active.
• Allow-only. There are no deny rules for listed models, and no per-organization prices or limits.
• Usage recording is not affected. POST /v1/internal/usage still records usage on any active model for any organization: usage that was served is always billed.
• The public catalogs (GET /v1/models, GET /v1/model/list, GET /v1/model/{name}) are not affected. They stay public-only.

How it is enforced

Every lookup of a model for a request now states who is asking:

pub enum ModelCaller {
    Anonymous,          // no organization known: listed models only
    Organization(Uuid), // listed models, plus unlisted models it holds a grant for
    Trusted,            // the platform itself: every model
}

ModelsServiceTrait::resolve_and_get_model, get_model_by_name and resolve_alias_cached, CompletionServiceTrait::get_model and AttestationServiceTrait::get_attestation_report take the caller. A call site that does not say who is asking does not compile.

All of them end in one function, services::models::resolve_model_cached. It returns None both for an unknown name and for a model the caller may not use. The call sites cannot tell the two apart, so each route answers with the unknown-model response it already had. No new error variant, status, type or message.

Who asks what:

Call site	Caller
Inference routes with an API key: chat completions, completions, responses (legacy and native), Anthropic messages and count_tokens, embeddings, image generations and edits, audio transcriptions, rerank, score, privacy classify and redact, System One	the key's organization
Completion service (create_chat_completion, create_chat_completion_stream)	the request's organization
GET /v1/attestation/report	the key's organization
Deprecation response headers	the key's organization (anonymous if there is none)
GET /v1/attestation/ita-token (public)	anonymous
GET /v1/model/{name} (public)	anonymous (unchanged, resolve_public_model)
Conversation titles (the title model)	trusted, through PlatformModel (below)
Billing of the auto-redact classify pass	trusted: a constant the platform chose, already run
Usage recording, admin flows, startup jobs	not changed: they use their own repositories and apply no access rule

Paths that needed more than a new argument:

1. Attestation report cache. Reports without a nonce are cached by model name, and a cache hit skips the build where the model used to be resolved. The model is now resolved for the caller before the cache lookup. Otherwise a report cached for an organization with a grant would have been served to anyone.
2. Chat completions pre-dispatch checks. The route reads the catalog list before the completion service resolves the model, and can answer from it ("model X does not support video input"). The row is now read only if the organization may use the model.
3. Strict alias mode (x-no-aliasing) and the alias warning name the canonical model behind an alias. Both now resolve for the caller.
4. Responses API image dispatch. The service looks the model up and then calls the provider pool directly for image models. That lookup now takes the organization.
5. Deprecation headers. The middleware adds x-model-deprecation-date and x-model-successor to successful responses. A streaming POST /v1/responses answers 200 before its model is resolved and fails inside the stream, so "the response is a success" does not mean the caller may use the model. The middleware now resolves the model for the request's own caller.
6. Models the platform chooses. The title of a conversation is written by a model the platform picks (TITLE_GENERATION_MODEL), billed to the organization. It must not depend on that organization's grants. CompletionServiceTrait::create_platform_chat_completion runs a PlatformModel and resolves it as trusted. A PlatformModel cannot be built from a string: its constructors are a closed list that reads platform configuration, and it replaces whatever model the request names. A model name from a request cannot take that path.

GET /v1/attestation/report now runs under the API-key middleware variant that also hands the handler the key's organization. It is the same credential check (the two middlewares share one function).

Cost

• Listed model: nothing new on the hot path. No new database query and no new lock. The check is model.is_listed on the row that was already resolved.
• Unlisted model: one grant lookup per (organization, model), cached next to the existing resolve cache with the same 30 second TTL. Both answers are cached, so an organization that keeps asking for a model it may not use does not reach the database every time.
• Grant and revoke drop one cached answer, the one for that organization and that model. They do not clear the model list cache or the resolved models: a grant changes neither, and reloading the list asks every backend for its metadata. A grant or revoke that changes nothing invalidates nothing.
• invalidate_models_cache() (catalog writes) clears the grant cache with the others.

Admin API

Same authentication, token permissions and error shapes as the other admin model routes. Model names with a slash must be URL-encoded. Unknown model or organization: 404 (model_not_found, organization_not_found).

Route	Token permission	Answer
GET /v1/admin/models/{model_name}/access	read	the model (id, modelName, isListed, isActive) and the organizations that hold a grant
PUT /v1/admin/models/{model_name}/access/{org_id}	write	200 with the grant. Idempotent: a second PUT returns the same grant
DELETE /v1/admin/models/{model_name}/access/{org_id}	write	204. Idempotent
GET /v1/admin/organizations/{org_id}/model-access	read	the models the organization holds grants for

// GET /v1/admin/models/vendor%2Fmodel/access
{
  "id": "0b0e…",
  "modelName": "vendor/model",
  "isListed": false,
  "isActive": true,
  "organizations": [
    {
      "organizationId": "5f1c…",
      "organizationName": "…",
      "grantedAt": "2026-10-12T15:00:00Z",
      "grantedByUserId": "1111…",
      "grantedByUserEmail": "…"
    }
  ]
}

A model is looked up by canonical name, active or not, so a grant can be reviewed or revoked while its model is inactive. The organization must be active.

Internal API for gateways

GET /v1/internal/model-access, behind the service token of POST /v1/internal/usage (CLOUD_API_USAGE_TOKEN), answered with Cache-Control: no-store. 503 until the token is configured.

{
  "object": "model_access",
  "models": [
    { "id": "vendor/model", "organization_ids": ["5f1c…", "9a2e…"] },
    { "id": "vendor/other-model", "organization_ids": [] }
  ]
}

It lists every unlisted model, active or not, with the ids of the active organizations that hold a grant (an empty list when there are none). A model that is not in the document is unrestricted. That is why a model that was deactivated here stays in it: a lane may still be serving it. A gateway polls the document and enforces access per request. It is read from the database on every call, so a change shows on the next poll of any instance.

Storage

One migration file, two tables. It takes the next free number at merge time; it is V0097__add_organization_model_access.sql on the branch (main's highest is V0096).

CREATE TABLE organization_model_access (
    organization_id UUID NOT NULL REFERENCES organizations(id) ON DELETE CASCADE,
    model_id UUID NOT NULL REFERENCES models(id) ON DELETE CASCADE,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    created_by_user_id UUID REFERENCES users(id) ON DELETE SET NULL,
    PRIMARY KEY (organization_id, model_id)
);
CREATE INDEX idx_organization_model_access_model_id ON organization_model_access (model_id);

CREATE TABLE organization_model_access_log (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    organization_id UUID NOT NULL REFERENCES organizations(id),
    model_id UUID NOT NULL REFERENCES models(id),
    action VARCHAR(10) NOT NULL CHECK (action IN ('grant', 'revoke')),
    acting_user_id UUID REFERENCES users(id),
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Why a migration and not an existing column: a grant is a relationship between two rows, written by admins. organizations.settings is customer-editable, so it must not hold access state.

Audit. A revocation deletes its grant row, so the grants table cannot say who had access when. The log is append-only: one row per grant and one per revocation, with the organization, the model, the acting admin and the time. The row is written in the same statement as the change, and only when the change happened: granting a grant that exists, or revoking one that does not, writes nothing. Nothing in the API reads it. Its one text column (action) is registered as approved plaintext in the database-encryption field registry.

Deleting an organization removes its grants in the same transaction, like it revokes its reporting tokens, and logs each one as a revocation with no acting user.

User erasure needs no change. Both tables hold ids only, and the admin's email is read from users when grants are listed. The log's foreign keys carry no ON DELETE action, like the role audit log (V0077): erasure rewrites the users row in place and keeps its id.

Rollout

• A model that is already unlisted is restricted the moment this version starts, and the grants table starts empty. Nobody can call such a model through this API until a grant exists.
• Checked on 2026-10-21: this cuts nobody off today. Prod has one unlisted model, and the API sent it no provider request in the last 30 days. Its traffic goes through a gateway lane, whose usage is recorded through POST /v1/internal/usage and stays open. That lane's organization needs its grant before the gateway turns its own enforcement on.
• Order for a model that has a provider: grant, then unlist. Grants can be created for a listed model in advance. They have no effect until the model is unlisted, and they apply from that moment.
• A gateway must switch its own enforcement on only after the grants exist. Until then the document lists the model with an empty organization list, which a gateway that enforces it reads as "nobody".
• Rolling deploy. An instance that still runs the old version does not check grants: it serves an unlisted model to any caller that knows its name, as today. The restriction holds once every instance runs this version.
• A rollback reopens restricted models to any caller that knows their names. The two tables can stay.
• Delay on other instances. A grant or a revocation applies at once on the instance that served the admin request, and within 30 seconds (the resolve cache TTL) on the others. After isListed: false, enforcement also follows on the other instances within those 30 seconds. But the pre-dispatch metadata read from the 5 minute list cache (the alias name, the input modality answer) can linger there for a model that was public minutes earlier.
• One known race. A grant lookup that is in flight while a grant is revoked can put the old answer back in the cache after the invalidation. It is bounded by the same 30 seconds. The resolve cache has the same documented limit.
• Migration number. The runner refuses to start when it finds an unapplied migration older than the newest applied one. So the file takes the next free number when it merges, and no lower number may reach a database after it.
• Deprecation. Grants belong to a model. If an unlisted model is deprecated in favour of another unlisted model, the successor needs its own grants.

Behaviour changes for existing clients

• isListed: false through the existing PATCH /v1/admin/models now cuts off callers without a grant. Before, it only hid the model from the catalogs.
• The attestation report reports an unknown model before an invalid nonce. It used to be the other way round. Both are still a 400. (The model is now resolved before the report cache.)
• The public ITA token route never serves an unlisted model, even when the caller's organization holds a grant: the route has no caller.
• A successor is named only to a caller that may use it. x-model-successor is left out when the successor does not resolve for the caller, and the public catalogs keep a successor only if it is a listed model. A successor that is no longer active is left out the same way. The trusted GET /v1/internal/models keeps it.
• The attestation service resolves the model through the shared 30 second resolve cache, like the completion service, instead of reading the database on every report build.

Known limit

An unknown name and a refused name do different database work: the unknown name misses on every request, the refused one is answered from caches. A caller close enough to the database to measure that could tell the two apart by timing. The responses themselves are equal.

Tests

Unit:

• services::models: the public views name only a listed successor; the caller rules, the grant cache (both answers, TTL, full invalidation), access-only invalidation (one decision dropped, the list and the resolved model not read again), a failed grant lookup is an error and never an allow, the trait defaults fail closed.
• Admin service: a grant or a revocation drops exactly that one access decision and never the model caches; one that changes nothing invalidates nothing; a grant for an organization deleted meanwhile is organization_not_found.
• Completion service: a refused model gets the error of an unknown one (blocking and streaming); a granted organization is served; a platform model is served without a grant, and replaces the model the request names.
• Attestation: a report cached for a granted organization is not served to anyone else; the public ITA flow treats an unlisted model as unknown.
• Admin token policy: the two listings are reads, grant and revoke are writes.

E2E (organization_model_access.rs):

• A table over every inference route that takes a model name (20 cases), on models that have a provider, a planned deprecation and a successor. An organization without a grant gets a response equal to the unknown-model response: status, headers and body. With a grant the request is served and carries the deprecation headers. The same through the model's alias.
• Deprecation headers: none without a grant on any route of the table, the streaming Responses route included; present with a grant; gone after a revocation.
• A listed model with an unlisted successor: the header names the successor only to an organization that holds a grant for it, and the public catalogs leave it out until it is listed.
• A guard over every router builder in src/lib.rs, and over the attestation, credit transfer and organization credential routers it merges: each registered method and path is either in the table or listed with the reason it is not. A new route fails the test until that decision is made.
• Pre-dispatch checks (video modality, strict alias mode, attestation alias header) do not disclose an unlisted model.
• Grant, then revoke: both apply at once, also over a cached decision.
• Listing opens a model, unlisting restricts it, grants prepared while listed apply from then on.
• A grant on an inactive model has no effect here, and the model stays in the gateway document.
• The audit log: one row per grant and per revocation, none for a call that changes nothing, a revocation with no acting user when the organization is deleted.
• Admin routes: happy paths, idempotency, 404s, token permissions.
• GET /v1/internal/model-access: content and authentication.
• The public ITA token route treats an unlisted model as unknown.
• Usage is recorded for an organization without a grant.

Run locally on the last commit, against a fresh PostgreSQL database each:

Command	Result
cargo fmt --all -- --check	clean
cargo clippy --all-targets --all-features -- -D warnings	clean
cargo nextest run --lib --bins	2654 passed, 8 skipped
cargo nextest run --test e2e_all	1072 passed, 11 skipped
cargo nextest run --test integration_tests	8 passed, 1 skipped
cargo test --locked -p database --test hot_path_typed_queries --test billing_typed_queries --test credit_allocation --test session_rotation --test staking_wallet_binding -- --test-threads=4	46 passed
cargo test --locked -p database --test credit_transfers -- --test-threads=1	20 passed
cargo check --all-targets on each commit	clean

The existing suite is unchanged apart from test doubles that implement the changed traits. No existing assertion was weakened.

I also broke three checks on purpose to see the new tests fail: the embeddings handler asking as a trusted caller, the chat pre-dispatch gate disabled, and the deprecation middleware resolving as trusted again. Each time the matching tests failed.

Review round

The fifth commit closes the findings of an independent review:

• The deprecation headers leaked an unlisted model on the streaming Responses route (point 5 above).
• Grant and revoke cleared every model cache; they now drop one access decision.
• The title model depended on the caller's grants (point 6 above).
• The gateway document left out inactive unlisted models.
• Revocations left no record; the audit log was added.
• The route guard only looked at two router builders and at the path.

Rebase onto main

Rebased on 2026-10-21 onto main at 71bbb0b (24 commits). The merge commit of 10-12 is gone.

• Migration number. Main took V0094 (legacy_credit_reconciliations), V0095 and V0096, so the file is now V0097__add_organization_model_access.sql. Same content.
• routes/completions.rs was split into one module per endpoint (refactor(api): split routes/completions.rs into per-endpoint modules #1265). Each change moved with its code: reject_if_aliased in completions/mod.rs, the chat pre-dispatch checks in chat.rs, text completions in text.rs, the trusted lookup for the auto-redact classify billing in chat_auto_redact.rs, the per-route lookups in audio.rs, images.rs, embeddings.rs, rerank.rs, score.rs and privacy.rs, and GET /v1/internal/model-access in models.rs. No change in behaviour.
• Attestation routes (feat(attestation): admin-added Sigstore-verified Tinfoil model pins; provider-neutral pins listing #1263). build_attestation_routes now also takes the admin settings for GET /v1/attestation/pins. The report route keeps the workspace-context middleware from this PR.
• x-model-pricing-change-date (feat(models): announce scheduled pricing changes #1247) is added by the same middleware as the deprecation headers, after the lookup for the request's own caller. So a caller without a grant does not get it either; the table test compares every response header. The two new e2e lookups in model_pricing_notices.rs read the model as ModelCaller::Trusted.
• New routes on main. GET /v1/attestation/pins (feat(attestation): admin-added Sigstore-verified Tinfoil model pins; provider-neutral pins listing #1263) is public and takes no model name. The credit transfer and organization credential routes (feat: add single-hop credit transfers and scoped organization credentials #1271) take no model name either; their routers live in their own modules, so the guard now reads those files too. That is the sixth commit.
• No new way around the check. The call sites of the model lookups and of the provider pool are the same set as before the rebase, apart from one fewer in usage recording (refactor(usage): build billing records from one base; extract pricing and token guards #1269), which applies no access rule by design. fix(admin): merge providerConfig on model updates and keep the stored api_key #1276 (providerConfig merge) and feat: add single-hop credit transfers and scoped organization credentials #1271 merged without conflicts. Deleting an organization still removes its grants in the same transaction.

Second review round

The seventh commit closes the review threads of 10-12:

• A grant could outlive its organization. A grant raced with the organization's deletion could land after the deletion had removed the other grants. The grant now holds the organization row (FOR SHARE) and inserts only while the organization is active, in one transaction; otherwise it answers 404 organization_not_found.
• An unlisted successor was visible. A listed model could name an unlisted successor in x-model-successor and in the public catalogs. See "Behaviour changes" above.
• A failed access check during alias resolution is logged. The alias still stays unresolved.
• Docs: the four admin access routes document 403; revoke states that the organization must be active; the gateway document says its entries are canonical names.
• No backfill: see the rollout note checked on 2026-10-21.

[claude]

Review: per-organization access to unlisted models

No critical issues found. I checked these areas:

• Enforcement choke point: every request-path resolution goes through resolve_model_cached / caller_can_use_model. A failed grant lookup returns an error, never an allow. Listed models return early, so the hot path costs nothing new.
• Trusted call sites: there are only two in production. One is PlatformModel (title generation), whose name is never taken from the request. The other is billing for the auto-redact classify pass, where the model is the constant DEFAULT_PII_MODEL. Neither lets a model name from a request through.
• Attestation cache: resolving the model for the caller before the no-nonce cache lookup closes the cross-org cache-hit leak.
• Deprecation middleware: it resolves for the request's own caller, so the streaming Responses route (200 before resolve) no longer leaks headers.
• SQL: all queries are parameterized. Grant/revoke and their audit rows are written in a single statement via a CTE, so they cannot get out of step. The grant lookup is served by the PK; the reverse direction has its own index. I found no N+1 queries.
• Migration / rolling deploy: the migration only adds tables, so old instances are unaffected. The audit log FKs have no ON DELETE, which is safe because I found no hard deletes of organizations or models outside tests.

Non-blocking notes:

• GET /v1/internal/model-access lists models by canonical model_name only, and the contract is "a model that is not in the document is unrestricted". A gateway that receives a request by alias must map it to the canonical name (e.g. via /internal/models aliases) before checking. Otherwise the alias falls into the unrestricted case. Consider adding the aliases to each entry, or documenting this requirement for gateway owners.
• The rollout notes already cover the in-flight-load race on the access cache (bounded by the 30s TTL) and the fact that already-unlisted models are locked the moment this version starts. Make sure ops seeds grants before deploying if any unlisted model currently has live callers.

✅

[ironloopai]

Review · Status

🟩 Completed

IronLoop completed the review and posted it to GitHub.

Result

Open submitted review →

Run details

• Run: d54c39c1-957d-40e4-aa07-2a8893455da6
• Base: main at 34fba04
• Head: feat/organization-model-access at 5a858e0
• Created: 2026-10-12 17:30 UTC
• Updated: 2026-10-12 17:37 UTC

_{Automatic trigger · attempt 1 of 3 · completed in 6m 40s}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5a858e008f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T17:34:57.129389Z	5a858e0	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[ironloopai]

Review · Summary

🟢 No actionable findings

No actionable defects found in the reviewed pull-request change.

Validation

• ✅ Access-control paths — Static tracing found caller-aware model resolution and fail-closed grant checks across the changed inference, response, attestation, and administrative access paths.
• ✅ Change coverage — The changed grant lifecycle, cache invalidation, internal access document, and route-level coverage were inspected.

Review details

• Run: d54c39c1-957d-40e4-aa07-2a8893455da6
• Attempts: 1

[lloydmak99]

Per-organization access to unlisted models looks sound. Every request-path model lookup funnels through resolve_model_cached → caller_can_use_model (services/models/mod.rs): listed models short-circuit to allowed, unlisted models allow only Trusted or a granted Organization, failed grant lookups error rather than allow, and refused models return the same NotFound as an unknown name. All inference call sites pass Organization(api_key.org); public routes pass Anonymous; platform/title/auto-redact paths use Trusted on constants. Grant/revoke write the grant and audit rows atomically, the hot-path check filters o.is_active AND m.is_active, org deletion cascades with audit logging, and migration V0094 is additive (safe rolling deploy).

No blocking issues found. Minor notes, none blocking:

• The attestation report path resolves for the caller before the no-nonce cache lookup, and the deprecation middleware resolves per-request — worth a glance to confirm these close the cross-org cache/header leaks as intended.

Checks: git diff --check and cargo fmt --all -- --check passed; local cargo build/tests couldn't run (environment lacks the cc linker), but CI is fully green on head 5a858e0 — unit, integration, E2E, lint, cargo audit/deny all passing.

[github-actions]

🔍 OpenCodeReview found 5 issue(s) in this PR.

• ✅ 5 posted as inline comment(s)
• 📝 0 posted as summary

⚠️ 3 warning(s) occurred during review.

[PierreLeGuen]

On the non-blocking notes from the reviews of 10-12:

• Aliases and GET /v1/internal/model-access (review comment above). The gateway (Gateway mode: enforce cloud-api's per-organization model access inference-proxy#297) first resolves the requested model to the entry it serves, then checks that entry's canonical id, so an alias cannot bypass the check there. I added this to the endpoint's docs in 686cad7: entries are canonical names, and a gateway checks the model an alias stands for.
• Grants before deploy. Prod has one unlisted model today, and no request for it goes through this API's inference path, so the deploy cuts nobody off. Details are in the migration thread.
• Attestation report cache and deprecation headers (Lloyd). Both are covered by e2e tests: the access table compares the full response of a refused request with an unknown model's, on the report route with and without a nonce, and deprecation_headers_are_only_added_for_a_caller_that_may_use_the_model covers the headers, the streaming Responses route included. Unit tests check that a report cached for an organization with a grant is not served to anyone else.

[lloydmak99]

This PR turns isListed: false into a real access boundary: unlisted models are usable only by organizations with an explicit grant, and refusals are indistinguishable from "model not found." The access-control logic is sound and fail-closed, and all previously raised blocking items are addressed.

• services/models/mod.rs: resolution funnels through a single choke point (resolve_model_cached → caller_can_use_model) — listed/Trusted allowed, Anonymous denied, Organization grant lookups fail-closed (a failed lookup returns Err, never an allow), and refusals return the same NotFound as unknown names.
• Grant/revoke vs. org-deletion race is handled: grant_model_access takes FOR SHARE on the org row and org deletion removes grants inside the FOR UPDATE deletion transaction, so the two serialize; grant/revoke+audit are atomic single-statement CTEs.
• Attestation report cache no longer leaks — the model is resolved for the caller before the no-nonce cache lookup, so a disallowed caller errors out before any cache hit.
• Deprecation/successor disclosure only names a successor the caller may actually use, including the streaming-200 path.
• Migration V0097 is additive (two tables + indexes), safe for rolling deploy. Note: flipping an existing model to isListed: false is a hard access cutover — an operational rollout matter the author verified against prod (one unlisted model, no direct API inference traffic), not a code defect.

Checks: git diff --check and cargo fmt --all -- --check both clean; local compilation unavailable here (no cc linker), relied on reported-green CI (unit, integration, lint, audit/deny) on head 5a858e0.