Skip to content

Add sync for tensorx - #4035

Open
bu6n wants to merge 14 commits into
anomalyco:devfrom
bu6n:dev
Open

Add sync for tensorx#4035
bu6n wants to merge 14 commits into
anomalyco:devfrom
bu6n:dev

Conversation

@bu6n

@bu6n bu6n commented Aug 4, 2026

Copy link
Copy Markdown

Adds a sync module for TensorX and corrects the existing providers/tensorx catalog against the provider's own API.

Sources

Source Supports
GET https://api.tensorx.ai/v1/model/info cost.input, cost.output, cost.cache_read; limit.context, limit.output; mode, supports_reasoning, supports_vision, supports_tool_choice / supports_function_calling
POST https://api.tensorx.ai/v1/chat/completions every reasoning_options and interleaved claim below, and the enforced completion cap
z.ai chat-completion reference, already cited in providers/zai/models/glm-5.2.toml GLM-5.2 effective effort levels high|max
providers/openrouter/models/… and providers/nvidia/models/nvidia/… control shape for the four models this key cannot reach

How reasoning controls were measured

usage.completion_tokens_details.reasoning_tokens is unreliable on this host. GLM-5-turbo and GLM-5v-turbo stream ~3,000 characters into reasoning_content while reporting reasoning_tokens = 0. Every claim below is therefore measured by reasoning_content length, with a nonce in each prompt to defeat caching, repeated runs, and an invalid effort value as a control for silently-ignored parameters.

Reasoning controls

Measured against the live API:

model authored finding
deepseek-v4-pro / -flash / -flash-0731 toggle effort accepted but not honored — low, high, max and an invalid value all overlap
deepseek-v3.2 effort ["none","high"] does not reason by default; an effort value switches it on; both toggle fields are no-ops
deepseek-r1-0528 [] none rejected, no level grades depth — matches the OpenRouter entry
kimi-k2.5 [] neither control works: thinking=false and effort=none both 0/6 empty
kimi-k2.6, kimi-k2.7-code toggle thinking=false empties reasoning; effort levels and an invalid value overlap
kimi-k3 effort ["none","low","high","max"] none empties 9/9 and depth grades low<high<max; toggle dropped — thinking=false leaked in 3/9
minimax-m2.5 [] none rejected, levels overlap, both toggle fields no-ops
qwen3.5-122b-a10b, qwen3.5-9b effort ["none","high"] none empties; levels overlap across 4 runs each; toggle fields no-ops
glm-5 effort ["none","high"] off is the effort value, not a field — enable_thinking is a no-op here
glm-5.1, glm-5-turbo, glm-5v-turbo toggle enable_thinking=false empties reasoning_content
glm-5.2 toggle + effort ["high","max"] both verified; levels per the z.ai aliasing note

Carried, not measured — /v1/model/info is a per-key view and these four return 403 key not allowed to access model, so nothing could be probed. Each says so in its leading comment, and none gets [interleaved] rather than assuming one:

model authored baseline
glm-4.7, deepseek-chat-v3.1, nemotron-3-super-120b-a12b toggle first-party z.ai / OpenRouter / first-party NVIDIA
gpt-oss-120b effort ["low","medium","high"] OpenRouter peer

minimax-m3 keeps its previously authored thinking_mode toggle; only its side channel was re-verified here.

interleaved: all 18 reachable reasoning models return reasoning_content, and each now declares it. None use reasoning_details.

Limits

limit.output is the API's max_output_tokens, and it is enforced. Streaming deepseek-v4-flash with max_tokens: 200000 stopped at exactly 64,000 with finish_reason: "length". Its lab entry claims 384,000, so inheriting the lab value would overstate real capacity ~6×.

Sync module

  • skipCreates: true — the catalog exposes no name, description, release date, reasoning controls or side channel, so new IDs are reported for hand-authoring rather than published with the runner's fallback reasoning_options = [].
  • deleteMissing: false — absence from /v1/model/info means the key lacks access (403, not 404), not that a model was retired.
  • A base_model already authored locally wins over re-derivation; resolution uses the shared resolveCanonicalBaseModel, which matches metadata filenames case-insensitively.
  • Cost is published only as a complete input/output pair; cache_write is preserved when the API reports null — it is null for every model, meaning "not published", not "not charged".
  • attachment and modalities.input are derived together from supports_vision, touching only image.
  • temperature and structured_output are deliberately not derived: supported_openai_params is a static list identical across all 32 entries, including the Whisper and embedding models.

Validation

bun validate passes. bun models:sync tensorx --dry-run against the live API reports 0 created, 0 updated, 0 removed, 25 unchanged — every hand edit matches serializer output, so nothing is clobbered on the next automated run.

Out of scope

deepseek-v3.2 and qwen3-235b-a22b-2507 remain full-inline because no models/ lab entry exists for either. Pre-existing; adding those affects other providers (302ai, vivgrid and siliconflow all carry inline deepseek-v3.2) and belongs in its own PR.

To do before merging

A maintainer should create a free account and API key at Tensorx.ai because the sync pipeline endpoint is authenticated.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] packages/core/src/sync/providers/tensorx.ts:178 - Check: Prefer local base_model on existing TOMLs (baseten/deepinfra/huggingface/openrouter pattern); do not expand factored files. Why: resolveBaseModel(model.model_name) ignores context.existing/authored base_model, and with preserveBaseModels: false the runner will not restore it. If resolution fails while a local factored file exists (missing alias, ID drift), buildTensorXModel returns ...existing as a full SyncedFullModel and rewrites the file without base_model, flattening lab fields into the provider TOML. Action: Use authored?.base_model ?? resolveBaseModel(...) (or existing?.base_model when present), pass authored base_model_omit, and never emit a standalone full model for an already-factored local entry.
  • [high] [violation] providers/tensorx/models/z-ai/glm-5.1.toml:3 - Check: AGENTS.md toggle rules — effort with none must not be paired with toggle. Why: This PR rewrites GLM-5.1/5.2/5-turbo/5v-turbo for AGENTS toggle headers while keeping toggle plus effort values that include none (and a full enum dump). That pairing is forbidden; off is already represented by none. First-party providers/zai uses toggle alone or effort high/max, not this dual shape. Action: Drop toggle and keep only the real effort set (or drop none from effort if on/off is a separate wire control), and replace the full enum with the levels TensorX actually accepts.
  • [medium] [possible mistake] providers/tensorx/models/deepseek/deepseek-v4-pro.toml:3 - Check: Reasoning baseline for DeepSeek V4 = lab/peers (toggle + high/max), not toggle-only unless this host lacks effort. Why: Lab providers/deepseek authors toggle + high/max; these TensorX V4 files only declare toggle. If reasoning_effort is forwarded, effort is missing; if it is not, document that this host is toggle-only. Action: Verify whether TensorX accepts reasoning_effort for V4; add high/max when it does, or keep toggle-only with an explicit host-only rationale.
  • [medium] [possible mistake] providers/tensorx/models/deepseek/deepseek-v4-flash.toml:15 - Check: Provider limit.output deltas should match the host’s real completion cap. Why: Patch 3 sets output = 64_000 on many models (DeepSeek V4, Kimi, GLM-5.x, MiniMax-M3) while lab defaults are 128k–384k; the previous MiniMax-M3 value was 131072. A uniform 64k looks like a platform default and may understate capacity if the API field is wrong or not authoritative. Action: Confirm /v1/model/info max_output_tokens is the enforced cap for each model (or a global TensorX ceiling), and note that in the PR body; restore higher outputs where the API is not authoritative.
  • [low] [possible mistake] packages/core/src/sync/providers/tensorx.ts:139 - Check: deleteMissing: false peers usually surface retained locals via missingNotice. Why: Absent remote models are retained silently, so lifecycle drift is easy to miss in sync reports. Action: Add a missingNotice listing retained local paths, matching baseten/deepinfra/huggingface.

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

1. base_model precedence — fixed. Correct, and a real regression. Now existing?.base_model ?? resolveBaseModel(...), matching openrouter/kilo/nano-gpt/empiriolabs. Verified against the exact scenario you described (factored local file, unresolvable ID): base_model and base_model_omit are both preserved and no lab fields are inlined.

2. GLM toggle + effort-with-none — fixed, and the enums were wrong too. Toggle dropped from all four files; enable_thinking stays documented in the header. Sweeping reasoning_effort against the live API showed three of the four authored lists were factually wrong:

model rejected (400)
glm-5.1 minimal, xhigh
glm-5-turbo minimal, xhigh, max
glm-5v-turbo minimal, xhigh, max
glm-5.2 none — all 7 accepted

Each list now carries only accepted values. none verifiably yields 0 reasoning tokens on all four. Enums elsewhere check out: deepseek-r1-0528 and minimax-m2.5 both reject none and both already omit it.

3. DeepSeek V4 effort — verified, not actionable. TensorX accepts reasoning_effort for V4 but does not honor it. It accepts any string without a 400, and reasoning-token counts for bogus_value (79/82/110) are indistinguishable from low (73/88/85), high (84/77/78) and max (81/95/66) across repeated unsaturated runs. Declaring high/max would advertise a control that does nothing, so these stay toggle-only with the host-only rationale now in the header, per your fallback action.

4. output = 64_000 — verified enforced, no change. Two premises to separate. First, the values aren't uniform: the catalog reports 8192, 64000, 65536, 131072, 163840, 202752 and 262144 across models, so this is per-model data. Second, I tested the cap directly on deepseek-v4-flash (the largest lab-vs-API gap in the set) by streaming with max_tokens: 200000: it stopped at exactly 64,000 tokens with finish_reason: "length", matching max_output_tokens exactly. The cap is server-enforced and the reported value is accurate. Note the lab entry claims 384,000 for this model — restoring the higher value would have overstated real capacity by 6×.

5. missingNotice — added. Matching the other deleteMissing: false providers. The text notes that /v1/model/info is a per-key view, so absence can mean the sync key lacks access rather than retirement — probing the six retained models returns 403 key not allowed to access model, not 404, which is also why deleteMissing stays false.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [medium] [violation] packages/core/src/sync/providers/tensorx.ts:114 - Check: Sync cost authoring must only emit complete USD pricing (peer pattern in openrouter/deepinfra/huggingface). Why: buildTensorXModel always builds a cost object from per-field ?? fallbacks. If the API omits input_cost_per_token or output_cost_per_token on a create (or both), stripUndefined can leave cost: { input } or cost: {}. Full-model Zod rejects partial Cost; SyncedBaseModel is deepPartial so an empty/partial [cost] can be written instead. Either aborts the whole TensorX sync or publishes incomplete prices. Action: Only set cost when both input and output prices resolve (else keep existing?.cost); do not auto-create a new model without a complete cost pair.
  • [medium] [possible mistake] providers/tensorx/models/z-ai/glm-5.2.toml:8 - Check: Reasoning effort baseline = lab + same-surface peers; no full-schema enum dumps without meaningful effect. Why: The “correct GLM effort” commit still authors none|minimal|low|medium|high|xhigh|max. First-party zhipuai/glm-5.2 documents many of those as aliases of effective high|max, and OpenRouter peers use high|xhigh. The header only claims other strings return 400, not that each listed value is a distinct control. Action: Narrow to effective levels observed on TensorX (or document per-value behavioral evidence), consistent with the turbo/5.1/5v-turbo fixes.
  • [medium] [possible mistake] providers/tensorx/models/moonshotai/kimi-k3.toml:4 - Check: Relay reasoning_options should copy lab/peer caller controls unless the host truly lacks them. Why: First-party Moonshot is toggle + effort low|high|max; OpenRouter exposes low|high|max. TensorX remains toggle-only. This PR added interleaved and claims host testing, and deepseek-v4 got an explicit “effort not honored” note—kimi-k3 has no equivalent. Action: Verify reasoning_effort on TensorX for kimi-k3; add the lab/peer effort set if it works, or add a leading comment that effort is accepted-but-ignored/rejected (as with deepseek-v4).

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

1. Partial pricing — fixed. Confirmed: SyncedBaseModel is AuthoredModelShape.deepPartial(), so a partial [cost] on a base_model file is written rather than rejected. Cost is now emitted only when both input and output resolve, otherwise existing?.cost is kept, and creates without a complete pair are skipped.

2. GLM effort — fixed, and the prior fix had it backwards. You're right that acceptance isn't a distinct control. First-party zai is toggle-only for 5.1/5-turbo/5v-turbo and effort ["high","max"] for 5.2, so the previous commit dropped the wrong control. Measured on TensorX: 5.1's toggle works (0 vs 582–966) but its effort levels aren't separable → toggle. 5.2 has both → toggle + high|max. 5-turbo/5v-turbo emit zero reasoning tokens under every setting including unset, so nothing is verifiable there → toggle carried from z.ai, noted in the header. glm-5 is the inverse: the toggle is a no-op, none genuinely disables → effort none|high|max.

3. kimi-k3 — fixed. reasoning_effort is real there: invalid values return 400 and none yields 0. Now toggle + ["low","high","max"], matching Moonshot and OpenRouter. The siblings genuinely differ and each now carries its evidence: k2.6 and k2.7-code accept effort but ignore it (invalid value and none both leave the token count unchanged), and k2.5 honors neither control, so it keeps reasoning_options = [].

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] providers/tensorx/models/z-ai/glm-5.toml:8 - Check: Relay reasoning_options must match this host’s real controls and the lab/peer baseline (first-party z.ai is toggle-only for GLM-5); do not invent graded levels the host cannot separate. Why: Final options are effort = none|high|max, but first-party providers/zai/models/glm-5.toml is toggle-only, and the new header says graded levels were not separable here while still publishing both high and max (and mislabels that as “z.ai's effective levels,” which is the GLM-5.2 set). Callers get fake effort steps. Action: Re-author from measured TensorX behavior: if only on/off works, use toggle (with wire comment) or a single off/on effort pair such as none + one on level; do not list both high and max unless they produce distinct reasoning behavior on this host.
  • [medium] [violation] packages/core/src/sync/providers/tensorx.ts:130 - Check: On multi-model relays, reasoning_options = [] means no caller control, not “unknown”; APIs that cannot author reasoning controls should not auto-create reasoners. Why: /v1/model/info does not expose reasoning controls, but the module still creates new chat models whenever base_model + pricing resolve. The runner then injects reasoning_options = [] for reasoning = true, publishing “no control” without host evidence (and without interleaved). Action: Set skipCreates: true (tinfoil/xai pattern) so new IDs are only noticed/issued for hand-authoring of reasoning_options / interleaved; keep updates for existing TOMLs.

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

Both findings correctly identified a real contradiction — the header claimed no reasoning was observed while the file asserted a reasoning_content side channel and a working toggle. That was a bug in my evidence, not in the data, and the resolution goes the other way.

Root cause: I measured the wrong signal. My earlier runs used usage.completion_tokens_details.reasoning_tokens, which these two models never populate — it reads 0 under every setting. They do reason, and stream ~3,000 characters into reasoning_content while reporting zero reasoning tokens. glm-5.1 returns comparable content and rt≈900, so this is a usage-accounting quirk specific to the turbo variants, not a capability difference.

Re-measured against reasoning_content length, with a nonce in each prompt to rule out cached completions:

glm-5-turbo glm-5v-turbo
default 2153, 2426, 1238 1129, 1025, 1816
enable_thinking=false 0, 0, 0 0, 0, 0
enable_thinking=true 1039, 1843, 1736 1809, 1626, 1614
reasoning_effort=none 0, 0, 0 0, 0, 0

So the side channel is real and the toggle is honored. All three proposed actions — dropping interleaved, dropping toggle, or overriding reasoning = false / publishing reasoning_options = [] — would have deleted accurate data. interleaved and toggle both stay; effort=none also suppresses reasoning, but no graded level separated from another, so only on/off is published per the binary-control rule.

Fixed in 62a2414d6: the header now states the verification and documents the accounting quirk, so the next person measuring this host doesn't repeat the mistake.

Because that metric had misled me once, I re-audited every other "this control has no effect" claim in the PR using content length. All held: glm-5's toggle is a no-op while effort=none works, kimi-k2.6 is toggle-only with effort ignored, kimi-k2.5 honors neither control, and DeepSeek V4's effort levels stay flat against an invalid-value control. The turbos were the only models with a zero baseline, so they were the only ones affected.

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [high] [possible mistake] providers/tensorx/models/deepseek/deepseek-v4-pro.toml:2 - Check: Relay reasoning_options must match lab/peer controls unless this host is shown not to honor them (AGENTS.md Reasoning options; audit evidence bar). Why: These entries drop lab effort high|max and keep toggle-only because “reasoning-token distribution” did not change. Later in this PR, GLM turbo notes that TensorX can leave usage.reasoning_tokens at 0 while still filling reasoning_content, so token-count probes are not reliable evidence on this host. Action: Re-probe V4 Pro/Flash/Flash-0731 with reasoning_content (or equivalent content signal). If effort changes depth, restore toggle + effort high|max; only keep toggle-only if content-based runs still show no effect.
  • [high] [possible mistake] providers/tensorx/models/moonshotai/kimi-k2.5.toml:1 - Check: [] on a relay requires affirmative “no caller control,” not a failed metric (audit-reasoning-options). Why: reasoning_options = [] is justified only by “reasoning-token count unchanged” over 8 runs, while first-party Moonshot exposes a thinking toggle and this PR later shows token counts can stay 0 while reasoning still streams on TensorX. Action: Re-test chat_template_kwargs.thinking by whether reasoning_content empties/fills. Restore toggle (and wire comment) if it works; keep [] only after content-based confirmation that reasoning cannot be turned off.
  • [medium] [possible mistake] providers/tensorx/models/moonshotai/kimi-k2.6.toml:2 - Check: Do not drop lab/peer effort controls from token-count-only probes on this host. Why: K2.6/K2.7-code comments say reasoning_effort is ignored because token counts did not move; K3 on the same host claims effort does move token counts, so the metric is model-dependent and the V4/K2.5 methodology risk applies here too. Action: Re-check reasoning_effort via reasoning_content length/presence. Add the real effort set if separable; otherwise keep toggle-only and note content-based verification.
  • [medium] [possible mistake] providers/tensorx/models/z-ai/glm-5.toml:1 - Check: Off/on claims for reasoning must use a signal this host actually populates. Why: GLM-5 marks reasoning_effort = none as off because it yields “0 reasoning tokens,” but patch 8 documents that TensorX may report 0 reasoning tokens while reasoning still appears in reasoning_content. Action: Confirm off/on with reasoning_content (as done for GLM turbo). Keep binary control only if content goes empty for off; if graded high|max separate in content, publish those effort values instead of toggle-only.
  • [low] [possible mistake] .pr-review/pull-request.json:3 - Check: Data-changing PRs should cite direct provider pricing/model/API docs mapped to claims. Why: The body points at prompt-caching docs for catalog/sync changes that also cover limits, cache prices, interleaved reasoning, and control surfaces; that URL does not clearly support those claims. Action: Add first-party citations (e.g. /v1/model/info / pricing / chat API) and state which claim each source supports.

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

1–4. Token-count evidence — valid objection, all four re-probed on reasoning_content. You're right that my own GLM-turbo finding invalidates token-count probes on this host. Re-measured everything with reasoning_content length, nonce-varied prompts, and an invalid-effort control:

model result authored
v4-pro / v4-flash / v4-flash-0731 unset, bogus, low, high, max all overlap (e.g. flash: bogus 1144 is the highest mean) toggle-only stands
kimi-k2.6 / k2.7-code thinking=false → 0,0,0; effort levels and bogus all overlap toggle-only stands
glm-5 enable_thinking=false → 1766/1527/3635 (no-op); effort=none → 0,0,0 binary on/off stands
kimi-k2.5 thinking=false 0/6 empty; effort=none 0/6 empty [] stands, now affirmative

kimi-k3 changed. On the content signal, reasoning_effort=none empties reasoning in 9/9 runs while chat_template_kwargs.thinking=false leaked in 3/9 — the toggle is unreliable, none is the real off switch, and depth is genuinely graded (low 99 < high 224 < max 279). Since effort now carries none alongside graded levels, the toggle is dropped per the none-vs-toggle rule: effort = none|low|high|max.

Every header now cites the content-based measurement and the run counts, and notes that usage.reasoning_tokens is unreliable on this host.

  1. updating the PR body

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] providers/tensorx/models/z-ai/glm-5.toml:9 - Check: When off is reasoning_effort = none, author effort with none in values — not type = "toggle" (AGENTS.md Reasoning options; audit skill “Not toggle: effort=… as off”). Why: Final file declares type = "toggle" while the leading comment states the only working off switch is reasoning_effort = none (and enable_thinking is a no-op). That mis-models the control surface: consumers treat toggle as a separate boolean wire field, not an effort value. Action: Replace with effort including none plus the effective on level(s) you measured (e.g. ["none", "high"] if graded levels are not separable), and update the leading comment to the effort wire path (no Toggle:).

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Action items

  • [high] [violation] providers/tensorx/models/nvidia/nemotron-3-super-120b-a12b.toml:5 - Check: Every toggle must document the exact request wire path in a leading top-of-file comment (AGENTS.md → Reasoning options). Why: This entry authors type = "toggle" while the header states the wire path is undocumented and unverifiable. Callers cannot send a real on/off control, so the catalog claims a capability this host file does not define. Action: Document the exact TensorX/NIM request field for this toggle (or drop toggle until that path is known); do not ship a toggle whose wire syntax is unknown.
  • [medium] [violation] packages/core/src/sync/providers/tensorx.ts:174 - Check: When deriving vision from supports_vision, keep attachment coherent with the full non-text modality set (including video/pdf), not image alone. Why: attachment is set from vision while modalities only add/remove image. For hosts of video-capable models (e.g. minimax/MiniMax-M3), supports_vision = false yields attachment = false with video still inherited—the inconsistent state this block claims to prevent. Action: Derive attachment from the final modalities.input (any non-text → true), or leave attachment unchanged when non-image non-text modalities remain after the image edit.

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

1. Nemotron toggle wire path — fixed, path found. You were right that shipping a toggle with an admittedly unknown wire syntax claims a capability the file doesn't define. It turned out to be documented: Workers AI hosts this exact model and specifies chat_template_kwargs.enable_thinking = true|false (sync-input.json, already cited in providers/cloudflare-workers-ai/models/@cf/nvidia/nemotron-3-120b-a12b.toml). It's also the field every GLM model on TensorX uses, which I verified directly. The header now leads with that path and its source, while still recording that the model is 403 for the sync key so it could not be confirmed on this host. [interleaved] stays omitted.

2. attachment vs non-image modalities — fixed. Correct, and the MiniMax-M3 case you named was the real hole: supports_vision = false would have set attachment = false while video stayed inherited — precisely the state that block claims to prevent. attachment is now read back off the resulting modalities.input (any non-text → true) rather than off the flag, so it stays coherent after the image edit. Verified across the four states:

vision=false, had video    -> input=["text","video"]   attachment=true (matches base)
vision=false, image only   -> input=["text"]           attachment=false
vision=true,  text only    -> input=["text","image"]   attachment=true
vision=null                -> both inherited

@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

No actionable findings.

bu6n added 14 commits August 4, 2026 15:45
Sync provider models from TensorX's own /v1/model/info endpoint.

Capability flags are three-valued in that catalog: true, false, and null
for "not published". Only real booleans are authored so a null leaves the
field inherited from the lab entry rather than overriding it with false.

supported_openai_params is deliberately not read. It is a static
LiteLLM-style list — all 32 catalog entries advertise the same params,
including temperature and response_format on the Whisper and embedding
models — so it carries no per-model signal. temperature and
structured_output stay lab metadata.

The endpoint publishes no name, description, or release date, so an
unknown model is reported through skippedNotice for hand-authoring
instead of being created from invented metadata.

Base models resolve through the shared resolveCanonicalBaseModel, which
matches metadata filenames case-insensitively.
The sync re-serializes provider files through Bun.TOML.parse, which
discards comments; only the leading block is re-attached. Trailing
comments on `type = "toggle"` / `type = "effort"` lines were therefore
lost on the first sync run.

AGENTS.md requires a leading top-of-file comment carrying the exact wire
path for every toggle, so the request syntax moves there and survives
future runs. No data changes.
Source: https://api.tensorx.ai/v1/model/info

- max_output_tokens is published per model and was previously missing or
  stale on ten entries (deepseek-v4-*, kimi-k2.6/k2.7-code/k3, glm-5.1,
  glm-5.2, minimax-m3, qwen3.5-9b)
- deepseek-v4-flash-0731 cache_read corrected 0.06 -> 0.0625

cache_creation_input_token_cost is null for every model in the catalog,
so cache_write is left at its authored value rather than being dropped:
a null there means "not published", not "not charged".
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Reconstructing the final sync module and checking a few peer comparisons that look suspicious.

@bu6n

bu6n commented Aug 4, 2026

Copy link
Copy Markdown
Author

Reconstructing the final sync module and checking a few peer comparisons that look suspicious.

Not sure what happened to the bot here, but I think this PR is now ready to be merged. (Last bot run said no actionable findings, and then I only rebased)

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