Skip to content

add AnyAPI sync provider#3230

Open
es697 wants to merge 1 commit into
anomalyco:devfrom
es697:feat/anyapi-sync-provider
Open

add AnyAPI sync provider#3230
es697 wants to merge 1 commit into
anomalyco:devfrom
es697:feat/anyapi-sync-provider

Conversation

@es697

@es697 es697 commented Jul 13, 2026

Copy link
Copy Markdown

Adds AnyAPI (https://anyapi.ai) sync provider module. The /v1/models endpoint returns model IDs documented in the AnyAPI docs: https://docs.anyapi.ai.

Verified against the live AnyAPI API on 2026-07-13:

  • present in /v1/models: anthropic/claude-haiku-4.5
  • present in /v1/models: anthropic/claude-sonnet-4.5
  • present in /v1/models: anthropic/claude-sonnet-4.6
  • present in /v1/models: anthropic/claude-opus-4.6
  • present in /v1/models: anthropic/claude-opus-4.7
  • absent from /v1/models: anthropic/claude-opus-4-6
  • absent from /v1/models: anthropic/claude-opus-4-7
  • present in /v1/models: google/gemini-3-pro-image
  • absent from /v1/models: google/gemini-3-pro-preview
  • present in /v1/models: x-ai/grok-4.3

Verified against the live chat endpoint with the same API key:

  • anthropic/claude-opus-4.6 -> HTTP 200
  • anthropic/claude-opus-4-6 -> HTTP 400
  • anthropic/claude-opus-4.7 -> HTTP 200
  • anthropic/claude-opus-4-7 -> HTTP 400

That is why the existing AnyAPI file paths were renamed to the dot-form Opus IDs and why the sync should treat those dot-form IDs as authoritative.

Changes

  • packages/core/src/sync/providers/anyapi.ts — fetches from https://api.anyapi.ai/v1/models
  • Registered in aggregators group
  • Auth via ANYAPI_API_KEY
  • deleteMissing: false — never removes hand-authored models missing from API response
  • skipCreates: true — does not auto-create new models from the thin ID-only endpoint
  • Existing authored AnyAPI model TOMLs are preserved byte-for-byte, except for explicit file-path renames that align them with current API IDs

Usage

ANYAPI_API_KEY=sk-... bun models:sync anyapi --dry-run
ANYAPI_API_KEY=sk-... bun models:sync anyapi

This is a conservative thin-endpoint sync: it uses the API as catalog availability input, but keeps existing hand-authored AnyAPI model files unchanged unless future provider metadata becomes authoritative enough for richer syncing.

@es697 es697 force-pushed the feat/anyapi-sync-provider branch from 7fd588f to f46ef22 Compare July 13, 2026 10:19
@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] packages/core/src/sync/providers/anyapi.ts:174 - Check: reasoning_options must reflect the provider's actual API surface, not be unconditionally emptied. Why: translateModel sets result.reasoning_options = [] for every reasoning model. Because the field is defined, the runner's preserveReasoningOptions keeps [] and never falls back to existing values, so documented controls are wiped: providers/anyapi/models/openai/gpt-5.toml and o3.toml carry reasoning_options = [{ type = "effort", values = ["low", "medium", "high"] }] and claude-opus-4-7.toml carries [toggle, effort], all backed by the provider.toml citation that AnyAPI accepts reasoning_effort = "low"|"medium"|"high" and thinking = { type = "enabled", budget_tokens }. [] means "no verified control," which contradicts that evidence and the checklist requirement. Action: Omit reasoning_options from the translated model so the runner preserves existing authored options and defaults only new reasoning models to [] (or explicitly carry forward existing.reasoning_options).

  • [high] [violation] packages/core/src/sync/providers/anyapi.ts:157 - Check: Preserve hand-authored fields the API is not authoritative for. Why: translateModel ignores _context and returns only base_model + base_model_omit. The runner only preserves base_model/base_model_omit, description, and reasoning_options, so everything else is dropped on rewrite. Existing files lose [interleaved] field = "reasoning_content" (deepseek-r1.toml) and the entire [experimental.modes.fast] block with its cost and provider body/headers (claude-opus-4-7.toml); any status would also be lost. The /v1/models endpoint returns only { id }, so it is not authoritative for these fields and sync.md requires preserving them. Action: Read context.existing(model.id) and carry forward interleaved, experimental, status, and any other non-authoritative provider-specific fields into the returned model.

  • [high] [violation] .github/workflows/sync-models.yml:65 - Check: New sync providers requiring auth must wire their secret into the workflow (sync.md step 6). Why: fetchModels (anyapi.ts:144) throws when ANYAPI_API_KEY is unset, but the sync-models.yml env block passes ANTHROPIC_API_KEY, OPENROUTER_API_KEY, etc. and not ANYAPI_API_KEY. The matrix auto-discovers anyapi, so the hourly CI job will throw immediately and never open a sync PR. Action: Add ANYAPI_API_KEY: ${{ secrets.ANYAPI_API_KEY }} to the Sync model catalogs step's env (and ensure the secret is configured in the repo).

  • [high] [possible mistake] packages/core/src/sync/providers/anyapi.ts:77 - Check: The override map must be reachable, and base_model resolution must match the hand-authored intent. Why: resolveBaseModel returns canonicalID as soon as modelMetadataByID.has(canonicalID) is true, before consulting the overrides map. Because models/deepseek/deepseek-r1.toml exists, the entry "deepseek/deepseek-r1": "deepseek/deepseek-reasoner" (anyapi.ts:90) is dead code. The existing providers/anyapi/models/deepseek/deepseek-r1.toml deliberately uses base_model = "deepseek/deepseek-reasoner" (1M context, attachment true, knowledge 2025-09); the sync would switch it to deepseek/deepseek-r1 (128K context, attachment false, knowledge 2024-07), changing the model's facts. Action: Consult the override map before the canonical-existence check (or remove the dead entry) and confirm which base model AnyAPI's deepseek/deepseek-r1 ID should inherit.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [medium] [violation] providers/anyapi/models/anthropic/claude-opus-4-7.toml, providers/anyapi/models/openai/gpt-5.2.toml, providers/anyapi/models/openai/gpt-5.4.toml (existing files interacting with new sync) - Check: Source citations and rationale must be in a leading comment block above the first key. Why: These files place reasoning_options rationale and docs.anyapi.ai citations between base_model and reasoning_options, not in the leading block. The sync runner (leadingComments + formatToml in packages/core/src/sync/index.ts) preserves only comments before the first key and re-serializes the rest. Registering the anyapi sync module causes the hourly CI sync to rewrite these files and silently delete the inline rationale, destroying the reasoning_options evidence trail. Action: Move the rationale comments to a leading comment block above base_model in these files before merging so the sync preserves them.

  • [low] [possible mistake] packages/core/src/sync/providers/anyapi.ts override map (lines adding "openai/gpt-audio": "openai/gpt-5", "openai/gpt-audio-mini": "openai/gpt-5", "openai/gpt-5.3-chat": "openai/gpt-5.2") - Check: Override mappings must point to the correct canonical model. Why: These three overrides map distinctly different models to unrelated canonical entries whose models/ TOMLs exist (models/openai/gpt-5.toml, models/openai/gpt-5.2.toml). If the AnyAPI API serves any of these IDs, the sync creates provider files with incorrect base_model references, attributing the wrong model's context limits, modalities, and capabilities to the served model. Action: Verify each mapping against AnyAPI's actual model catalog, or remove the incorrect entries so unresolvable models are skipped rather than misattributed.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] packages/core/src/sync/providers/anyapi.tstranslateModel, base_model_omit: ["cost"]Check: base_model_omit should target fields that actually exist on the base model metadata. Why: ModelMetadataBase (in packages/core/src/schema.ts) has no cost field — cost is provider-specific — so base_model_omit = ["cost"] is always a no-op. However, it injects a new key into every translated model, which makes the runner's sameModel comparison (packages/core/src/sync/index.ts) detect a difference on every existing file and trigger a full rewrite. That rewrite reformats the TOML via formatToml and re-attaches only the leading comment header, permanently deleting all non-leading comments — including hand-authored source citations and reasoning-option API documentation in 13 existing files (e.g., providers/anyapi/models/anthropic/claude-opus-4-6.toml:2, providers/anyapi/models/openai/gpt-5.toml:2). Action: Remove base_model_omit: ["cost"] from the translated model so unchanged files are not rewritten.

  • [medium] [violation] providers/anyapi/models/**/*.tomlCheck: Source citations and rationale comments must live in a leading comment block above the first key, per the AGENTS.md "In-file comments" rule, because sync serialization discards comments elsewhere. Why: The existing AnyAPI model files place documentation comments after base_model (line 2+). Any sync rewrite — whether triggered by the no-op omit above or by a future legitimate model change — will delete these comments, which document reasoning-option API syntax and cite https://docs.anyapi.ai/guides/parameters. Affected files: anthropic/claude-opus-4-6.toml, claude-sonnet-4-6.toml, claude-sonnet-4-5.toml, claude-haiku-4-5.toml, claude-opus-4-7.toml, openai/gpt-5.toml, gpt-5.1.toml, gpt-5-mini.toml, gpt-5.2.toml, gpt-5.4.toml, o3.toml, o3-mini.toml, o4-mini.toml. Action: Move each comment block above base_model so it is preserved as the leading header.

  • [low] [possible mistake] packages/core/src/sync/providers/anyapi.tsCANONICAL_PROVIDER_PREFIXES / overrides map — Check: Override keys must use a provider prefix that exists in CANONICAL_PROVIDER_PREFIXES. Why: The overrides meta/llama-4-maverick, meta/llama-4-scout, and upstage/solar-pro-3 can never be reached: meta and upstage are not in the prefix map (only meta-llama is), so resolveBaseModel returns undefined before consulting the overrides. The target metadata files (models/meta/llama-4-maverick-17b-instruct.toml, models/meta/llama-4-scout-17b-instruct.toml) do exist, so if AnyAPI serves these models they will be silently skipped instead of synced. Action: Either add meta and upstage entries to CANONICAL_PROVIDER_PREFIXES (with the correct metadata directory) or correct the override keys to use meta-llama/ and remove the unreachable upstage entry.

  • [low] [possible mistake] PR body — Check: Data-changing PRs should cite direct provider documentation for material factual claims. Why: The override map makes non-obvious identity claims that cannot be verified from the diff alone (e.g., deepseek/deepseek-r1deepseek/deepseek-reasoner, where models/deepseek/deepseek-r1.toml and models/deepseek/deepseek-reasoner.toml are distinct models with different context limits and release dates; openai/gpt-chat-latestopenai/gpt-5). The PR body names the endpoint but does not cite the AnyAPI models documentation or explain what each override supports. Action: Add citations (e.g., https://docs.anyapi.ai) to the PR body mapping specific overrides to the model IDs they cover.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [high] [possible mistake] packages/core/src/sync/providers/anyapi.ts:68 (resolveBaseModel) and :162 (translateModel) - Check: Sync deletion behavior vs. the actual /v1/models response shape. Why: resolveBaseModel splits each id on / and requires the first segment to be a CANONICAL_PROVIDER_PREFIXES key; an unprefixed id (e.g. gpt-5, the format OpenAI-compatible /v1/models endpoints normally return) fails the prefix check, translateModel returns undefined for every model, and because deleteMissing is not set to false the runner deletes every existing hand-authored anyapi TOML — including curated reasoning_options, [experimental.modes.fast], and [interleaved] data. The Zod schema only requires id, and the PR provides no sample response or docs citation confirming the id format or that the endpoint authoritatively lists all served models. Action: Run bun models:sync anyapi --dry-run and share the report / cite the AnyAPI API docs confirming prefixed, authoritative ids; otherwise set deleteMissing: false (and skipCreates: true if bare-id models should not be auto-created), matching the thin OpenAI sync in openai.ts that preserves hand-authored files byte-for-byte.
  • [medium] [violation] packages/core/src/sync/providers/anyapi.ts:162 (translateModel result) - Check: Preservation of hand-authored provider-specific fields per sync.md. Why: The translated model carries only base_model plus interleaved/experimental/status/reasoning_options; the runner only adds description and reasoning_options on top. cost (and name/limit/modalities overrides) is not preserved. sync.md requires preserving hand-authored fields the provider API is not authoritative for, and this endpoint returns only id, so it is non-authoritative for every field. Any hand-authored [cost] for an anyapi model — the standard way to publish gateway pricing — would be silently stripped on the next sync. Action: Preserve all hand-authored fields for existing entries (e.g. return the existing authored model as openai.ts's preserveAuthoredModel does, or explicitly carry cost and other overrides through).
  • [low] [possible mistake] .pr-review/pull-request.json - Check: PR body accuracy and source citations for a data-changing sync PR. Why: The body states base_model_omit = ["cost"], which patch 4 removed from the code, and does not cite the AnyAPI API documentation supporting the /v1/models response shape, id format, or endpoint authoritativeness — the facts needed to verify the high-severity deletion behavior above. Action: Update the description to match the final code and add a first-party citation (e.g. docs.anyapi.ai) stating what the endpoint returns and that it authoritatively represents the served catalog.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] packages/core/src/sync/providers/anyapi.ts translateModel (patch 5, existing?.limit/modalities/name/family blocks) - Check: base_model factoring — provider TOMLs must not duplicate provider-agnostic facts that are inherited from models/ metadata (AGENTS.md "New models" blocker; README base_model rules). Why: translateModel preserves name, family, limit, and modalities from context.existing(model.id), but the runner's context.existing returns the base-model-resolved (deep-merged) shape, not the raw authored file (context.authored does). All four of those fields live in ModelMetadata, so the resolved existing object always carries the inherited values from models/<provider>/<model>.toml. Copying them back writes inherited name, family, [limit], and [modalities] explicitly into every provider TOML — e.g., providers/anyapi/models/deepseek/deepseek-v4-pro.toml (currently just base_model + reasoning_options = [] + [interleaved]) would gain name = "DeepSeek V4 Pro", family = "deepseek-thinking", the full [limit], and [modalities] already provided by base_model = "deepseek/deepseek-v4-pro". The sameModel comparison then flags every already-factored file as changed and rewrites it, permanently un-factoring all 30 existing files and deleting their non-leading comments (including the source-citation and reasoning-option-syntax comments in anthropic/claude-opus-4-6.toml, openai/gpt-5.toml, etc.). (cost, interleaved, experimental, and status are not in ModelMetadata, so preserving those from context.existing is harmless.) Action: Preserve name, family, limit, and modalities from context.authored(model.id) (the raw authored TOML) instead of context.existing, so only provider-specific overrides are emitted and inherited values stay factored. Alternatively, route the full value set through the shared factorBaseModel helper (used by venice.ts and chutes.ts), which strips any value matching the inherited metadata.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [low] [possible mistake] packages/core/src/sync/providers/anyapi.ts:107 - Check: Override-map keys for Mistral models must use the same provider prefix the AnyAPI /v1/models endpoint actually returns, because resolveBaseModel builds the lookup key as cleanID = provider + "/" + cleanModel from the raw API prefix. Why: Every existing AnyAPI Mistral file lives under the mistralai/ path (providers/anyapi/models/mistralai/mistral-large-2512.toml, providers/anyapi/models/mistralai/devstral-2512.toml), indicating the API emits mistralai/ IDs, but the override keys are written as mistral/… (e.g. "mistral/mistral-large-2407", "mistral/mistral-large", "mistral/codestral-2508"). If the API returns mistralai/, none of these overrides can ever match, so the version-variant mappings are dead code and those models will be skipped instead of resolved. If the API returns mistral/ for current models, translateModel returns id: "mistral/…" and the runner writes new files under providers/anyapi/models/mistral/… while the existing mistralai/… files are retained (deleteMissing: false), producing duplicate catalog entries for the same model. Action: Verify which prefix(es) the AnyAPI endpoint uses for Mistral models and align the override keys to that prefix (or confirm the existing file paths), so the overrides fire and no duplicate model paths are created.

@github-actions

Copy link
Copy Markdown
Contributor

Based on my analysis of the PR, the existing provider infrastructure, sync patterns, and the AGENTS.md guidance, here is my review:

Action items

  • [medium] [violation] packages/core/src/sync/providers/anyapi.ts (provider object, near deleteMissing: false) - Check: Thin-endpoint sync must not auto-create incomplete models. Why: The /v1/models endpoint only returns model IDs — the Zod schema is z.object({ id: z.string() }) with .passthrough() — so the sync cannot populate cost, limits, modalities, or verify reasoning controls. AGENTS.md states "a thin endpoint that cannot populate required fields should stay hand-authored." Google and OpenAI both set skipCreates: true for comparable ID-only endpoints. Without skipCreates, any API model that resolves to a models/ entry but has no existing provider TOML is created with only base_model + reasoning_options = [], shipping an incomplete entry. Action: Set skipCreates: true and add sourceID/skippedNotice (following the google.ts/openai.ts pattern) so new API models are reported for manual metadata creation instead of being auto-created incomplete.

  • [medium] [possible mistake] packages/core/src/sync/providers/anyapi.ts (translateModel, result.reasoning_options = [] in the else branch) - Check: The reasoning_options default for new reasoning models must reflect the provider's actual API surface. Why: providers/anyapi/provider.toml documents that AnyAPI accepts reasoning_effort = "low" | "medium" | "high" and thinking = { type = "enabled", budget_tokens = <integer> }. Existing hand-authored models reflect these controls (e.g., providers/anyapi/models/openai/gpt-5.toml has reasoning_options = [{ type = "effort", values = ["low", "medium", "high"] }]). Defaulting new models to [] claims "no verified control" when the provider documents controls at the API level, contradicting the AGENTS.md rule that options describe controls exposed by the inference provider. Action: If new model creation is retained, default reasoning_options to the documented effort/budget controls instead of []. Setting skipCreates: true (previous item) also resolves this by preventing the [] default from being applied to new models.

@github-actions

Copy link
Copy Markdown
Contributor

I now have a complete picture. Let me verify my understanding of one edge: confirm that factorBaseModel is the established pattern by checking how LLMGateway handles the existing-factored path, and confirm the base-model metadata schema excludes provider-specific fields (so existing.* for those equals authored.*).

I've confirmed:

  • ModelMetadataBase (schema.ts:188-208) excludes cost, interleaved, status, experimental, reasoning_options, provider — so for base_model files, existing.<provider-specific> always equals authored.<provider-specific>.
  • LLMGateway (lines 169-198) and CrossModel (lines 242-258) both route existing fields through factorBaseModel to preserve overrides while factoring inherited values.
  • The AnyAPI translateModel only copies interleaved, experimental, status, cost, reasoning_options onto the result and omits all inheritable field overrides.
  • All current anyapi files are clean base_model + provider-specific fields (no inheritable overrides), so the sync is idempotent today and no current data is lost — but the preservation gap is a latent data-integrity risk that contradicts sync.md.

Action items

  • [medium] [violation] packages/core/src/sync/providers/anyapi.ts:177 - Check: Sync providers must preserve hand-authored fields when the provider API is non-authoritative for them (sync.md "Provider Modules": "Preserve existing hand-authored fields only when the provider API is not authoritative for that field"). Why: translateModel builds result from only base_model plus interleaved, experimental, status, cost, and reasoning_options. The AnyAPI /v1/models endpoint returns only model IDs, so it is non-authoritative for every other field; a hand-authored override of an inheritable field (e.g. a provider-specific [limit] or [modalities] override, which README explicitly supports for wrapper providers) would be silently dropped on the next sync — the runner's preserveBaseModel only re-attaches base_model/base_model_omit, not the omitted overrides. The other aggregator providers (OpenRouter, CrossModel, LLMGateway) avoid this by routing the resolved existing fields through factorBaseModel, which keeps overrides and drops only values that match the base. Action: Pass the resolved existing fields through factorBaseModel (from ./openrouter.js) — or otherwise copy every hand-authored field onto the result — so provider-specific overrides survive sync while matching inherited values stay factored out.

@github-actions

Copy link
Copy Markdown
Contributor

Based on my thorough analysis of all 9 patches in the diff, the provider directory, schema, sync infrastructure, and related provider modules, here is my review:

Action items

  • [medium] [possible mistake] packages/core/src/sync/providers/anyapi.ts:3,9-10,12-33,68-105 - Check: Remove dead code left behind by the patch 9 simplification of translateModel. Why: The final translateModel only calls preserveAuthoredModel, which uses AuthoredModel and the context.authored() callback — it no longer resolves base models or reads model metadata from disk. As a result, readFileSync (line 3) is a completely unused import, and path/readdirSync (lines 2-3), MODELS_DIR (line 9), modelMetadataByID (line 10), CANONICAL_PROVIDER_PREFIXES (lines 12-33), loadModelMetadata, normalizeModelName, and the entire resolveBaseModel function (~70 lines including the override map) are never called. This is roughly 75% of the file. The leftover override map is especially misleading because it implies the sync maps API IDs to canonical base_model references, but the shipped behavior is byte-for-byte preservation of authored models (matching the OpenAI thin-endpoint pattern). The PR body also still claims the sync "maps known IDs to canonical base_model," which no longer matches the code. Action: Delete the unused imports (path, readFileSync, readdirSync) and all unreferenced helper code (MODELS_DIR, modelMetadataByID, CANONICAL_PROVIDER_PREFIXES, loadModelMetadata, normalizeModelName, resolveBaseModel), and update the PR body to reflect that the sync preserves existing authored TOMLs without ID-to-base_model mapping.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [medium] [possible mistake] packages/core/src/sync/providers/anyapi.ts:translateModel - Check: API model IDs must exactly match existing file paths for the thin-endpoint sync to correlate API responses with authored TOMLs. Why: translateModel calls context.authored(model.id) with the raw API ID, and the runner looks up ${id}.toml in providers/anyapi/models/. The PR body states the API returns IDs like anthropic/claude-opus-4.7 (dot-separated version), but every existing Anthropic file uses dash-separated names (e.g., anthropic/claude-opus-4-7.toml, anthropic/claude-sonnet-4-5.toml), matching the repo-wide models/anthropic/ convention. Early commits in this PR included a normalizeModelName function that converted Anthropic dot versions to dashes, and an overrides map handling claude-3.5-haikuclaude-3-5-haiku; both were removed in the final refactor. Without normalization, every Anthropic API model fails the context.authored lookup, translateModel returns undefined, and the model is reported as skipped — while the corresponding local file is silently retained as "missing from source." The sync becomes a no-op for all Anthropic models and produces misleading skip/missing notices on every run. The same risk applies to Cohere and Perplexity if the API returns short names (e.g., cohere/command-r-plus) that don't match dated file names (e.g., cohere/command-r-plus-08-2024.toml). Action: Verify the actual ID format returned by https://api.anyapi.ai/v1/models against every existing providers/anyapi/models/**/*.toml path. If the API returns dot-separated Anthropic versions (or any other format that diverges from the file names), add an ID normalization step in translateModel before calling context.authored, or confirm the API returns dash-separated IDs and correct the PR body example.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] providers/anyapi/models/google/gemini-3-pro-image.toml:1 - Check: base_model must reference the matching models/ metadata entry for the underlying model after the file rename. Why: Commit 11 renames gemini-3-pro-preview.tomlgemini-3-pro-image.toml (100% content preserved) but the file still declares base_model = "google/gemini-3-pro-preview". A separate models/google/gemini-3-pro-image.toml metadata entry exists and describes a completely different model ("Nano Banana Pro" — image-generation, 65K context, modalities.output = ["text", "image"], tool_call = false) versus models/google/gemini-3-pro-preview.toml ("Gemini 3 Pro Preview" — text reasoning, 1M context, text-only output, tool_call = true, structured_output = true). After the rename, the generated AnyAPI entry for google/gemini-3-pro-image inherits the wrong name, description, limits, modalities, tool_call, and structured_output. Action: Update base_model to "google/gemini-3-pro-image" in the renamed file.

  • [low] [possible mistake] .pr-review/pull-request.json (PR body) - Check: The PR body should describe and cite evidence for the 7 model file renames in commit 11. Why: The PR body claims "Existing authored AnyAPI model TOMLs are preserved byte-for-byte" but commit 11 renames 7 files, changing model IDs (e.g. anthropic/claude-sonnet-4-6anthropic/claude-sonnet-4.6, xai/grok-4.3x-ai/grok-4.3, google/gemini-3-pro-previewgoogle/gemini-3-pro-image). The general https://docs.anyapi.ai citation does not establish that the /v1/models endpoint returns these exact IDs, nor whether google/gemini-3-pro-preview is still served alongside gemini-3-pro-image. Without this, the disappearance of gemini-3-pro-preview from the AnyAPI catalog and the correctness of every rename cannot be fully reviewed. Action: List the exact API model IDs returned for each renamed file and confirm whether google/gemini-3-pro-preview was replaced by google/gemini-3-pro-image.

@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [low] [possible mistake] providers/anyapi/models/google/gemini-3-pro-image.toml:1 - Check: base_model changed from google/gemini-3-pro-preview to google/gemini-3-pro-image. Why: This is the only renamed file whose base_model changes (all other renames keep their existing pointer). It re-points the AnyAPI entry from a 1M-context, tool_call = true, structured_output = true reasoning preview to "Nano Banana Pro" — a 65K-context image-generation model with tool_call = false and no structured output. That is a material capability, limit, and modality change, and the PR body only cites the /v1/models endpoint generally without confirming this specific ID, so the change cannot be reviewed from the diff alone. Action: Confirm the AnyAPI /v1/models response actually lists google/gemini-3-pro-image (not gemini-3-pro-preview) and that dropping the previous gemini-3-pro-preview entry is intended; cite the specific API response or docs entry that supports it.

@es697 es697 force-pushed the feat/anyapi-sync-provider branch from 1c7a7f5 to cb70617 Compare July 13, 2026 12:52
@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [medium] [violation] providers/anyapi/models/anthropic/claude-haiku-4.5.toml:2-5 (and the other renamed claude-*.toml files that retain their inline comment blocks: claude-opus-4.6.toml:2-5, claude-opus-4.7.toml:2-4, claude-sonnet-4.5.toml:2-5, claude-sonnet-4.6.toml:2-5) - Check: AGENTS.md requires source citations and rationale in synced provider TOMLs to live in a leading comment block above the first key, because sync serialization discards comments elsewhere. Why: This PR enables the AnyAPI sync module, making these files subject to hourly CI sync rewrites that parse and re-serialize TOML (discarding all non-leading comments). The existing rationale/citation blocks sit between base_model and reasoning_options rather than in the leading header, so the next sync-triggered rewrite of any of these models will silently delete the documentation and source URLs that justify the reasoning_options values. The same risk applies to other AnyAPI TOMLs with non-leading comments that are now synced (e.g. openai/gpt-5.1.toml:2-4, openai/o3.toml:2-4, openai/gpt-5.toml:2-4). Action: Relocate each file's rationale/citation comments into a leading comment block above base_model (or move the citations into the PR body per the audit-reasoning-options skill) before merging, so the sync preserves them.

@github-actions

Copy link
Copy Markdown
Contributor

No actionable findings.

- add conservative AnyAPI sync provider using /v1/models
- require ANYAPI_API_KEY for sync runs and wire workflow env
- register provider in aggregators
- preserve existing authored AnyAPI TOMLs byte-for-byte
- skip creating new models from the thin ID-only endpoint
- never delete hand-authored models missing from API response
- align existing AnyAPI file paths with current API ids where needed
- move rationale comments into leading blocks so sync preserves them
@es697 es697 force-pushed the feat/anyapi-sync-provider branch from 02b346c to 173b96b Compare July 13, 2026 13:06
@github-actions

Copy link
Copy Markdown
Contributor

Action items

  • [low] [possible mistake] providers/anyapi/models/anthropic/claude-opus-4.6.toml (renamed from claude-opus-4-6.toml) and providers/anyapi/models/anthropic/claude-opus-4.7.toml (renamed from claude-opus-4-7.toml) - Check: Provider model filenames must match the provider's actual API model IDs. Why: The PR body states that anthropic/claude-opus-4.6 and anthropic/claude-opus-4.7 (dot-format) are absent from the /v1/models endpoint, yet the PR renames these files from hyphen-format to dot-format. The original hyphen-format IDs were not checked. If AnyAPI still serves these models under hyphen-format IDs, the rename produces incorrect catalog model IDs and prevents the sync from matching the files to API responses. The haiku/sonnet renames are verified (those dot-format IDs are present), but the opus renames are inferred from pattern only. Action: Verify whether anthropic/claude-opus-4-6 and anthropic/claude-opus-4-7 (hyphen-format) are present in the API. If they are, revert the renames. If neither format is present, consider marking the models status = "deprecated" since they are no longer in the API catalog rather than silently renaming them.

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.

1 participant