CAFleet Model List Refresh
SkillAI & modelsRefresh the CAFleet model list at skills/cafleet/reference/coding-agents.md from the approved official pricing and capability sources. Use when a maintainer asks to refresh, update, or re-verify the model list, its token prices, its context windows, or its freshness, or when a Director reports the list was last refreshed more than 30 days ago. Maintainer-invoked only — never run automatically during a member spawn.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the CAFleet Model List Refresh skill
What this skill tells your AI
The instructions your AI receives, as published by himkt/cafleet in .claude/skills/cafleet-model-list-refresh/SKILL.md and read by ahel’s review.
Refresh the repository's model catalogs and canonical Role defaults in
skills/cafleet/reference/coding-agents.md — from the approved official
sources, under explicit maintainer review. The repository file is the release
source: a running Director reads only its deployed skill replica, so a refresh
reaches Directors exclusively through the release/deployment transaction below.
This skill maintains each backend's Model catalog, its provenance/context notes, its canonical Role defaults table, and the shared freshness metadata. Preserve Runtime bindings, bound runtime notes, pane-state capture cues, and worked resolutions as runtime documentation owned outside model refreshes. The common catalog preamble specifies maintainer-owned refresh at least every 30 days, a last-refreshed date for model data, standard provider USD per MTok as planning estimates, reviewed capability ordering, and Director ownership of selection policy.
Approved sources (exhaustive allowlist)
Fetch only these five official pages. Search results, third-party price
sites, and social posts are never model-list authority. The first four are
pricing and availability authority; the fifth is capability authority for the
claude backend's context windows and Claude Code model-string syntax, and
is never used to price a model.
| Source | What it feeds | URL |
|---|---|---|
| Anthropic pricing | claude prices | https://platform.claude.com/docs/en/about-claude/pricing.md |
| OpenAI pricing | codex prices | https://developers.openai.com/api/docs/pricing |
| Codex model availability | codex availability | https://learn.chatgpt.com/docs/models.md |
| OpenCode Zen models and pricing | opencode prices and availability | https://opencode.ai/docs/zen.md |
| Claude Code model configuration | claude context windows and [1m] applicability | https://code.claude.com/docs/en/model-config.md |
Refresh procedure
-
Fetch all five approved sources. If any source cannot be fetched or parsed, stop: leave the model list unchanged, report the error, and let it become stale rather than fabricating values.
-
Extract pricing facts only: the currently effective standard input and output prices (USD per MTok) and availability/deprecation qualifiers. Do not copy long provider text into the repository, and do not present the pricing pages as benchmark evidence — they are pricing/availability sources only.
-
Refresh the
claudeandcodextables from their provider pricing pages, and refresh theopencodetable with the dedicated procedure below — the Zen catalog behaves differently from the provider pages, so follow that procedure exactly. Forcodex, pricing and availability come from different pages: price each model from the OpenAI pricing page, but take Codex availability from the Codex models page (https://learn.chatgpt.com/docs/models.md) — the table carries only the models Codex currently offers in its model picker. A model absent there or demoted to a legacy model (reachable only viacodex -m/config.toml) is removed from the table even when the pricing page still prices it; legacy models remain manual pass-through--modelvalues. -
Reapply the capability classes explicitly. The
Classdescriptions and the most-to-least-capable row ordering are reviewed maintainer judgment, not provider benchmark claims; changing a class or the ordering requires reviewed policy approval in the same pull request. Every row carries both prices from its approved source. Update each backend's canonical Role defaults table directly from its refreshed Model catalog: assign{monitor_model}and{reviewer_model}to local catalog entries or aliases under the Director's selection policy. -
Re-verify every
clauderow's context window on every refresh, even when the prices are unchanged. Take each window from the Claude Code model configuration page's Extended context section and record it in theclaudetable'sContextcolumn. That page is also the authority for whether a row's--modelvalue carries the[1m]suffix, which is a Claude Code model-string suffix stripped before the request reaches the provider — it is meaningless for thecodexandopencodetables, whose values never carry it. Apply the suffix only where it changes the window a member actually gets:- A model the page lists as always running at 1M on the Anthropic API carries no suffix — the window is already 1M and the suffix is inert.
- A model the page gives no 1M variant carries no suffix.
- A model without 1M support carries no suffix; appending it there is a malformed value.
- Where the page shows the window is opt-in for the reader's plan, the suffix belongs in the page's note rather than the row, so the Director applies it per spawn against the operator's plan instead of every spawn inheriting a credit-billed window.
A suffixed value must be single-quoted everywhere it appears in a command, because
[1m]is a glob pattern that fails an unquoted zsh invocation. -
Propose, then apply atomically. Generate a concise proposed diff and require explicit maintainer approval before applying the model-data changes in
skills/cafleet/reference/coding-agents.md. Preserve the common catalog preamble contract described above. Apply catalogs, provenance/context notes, Role defaults, and the last refreshed date together after approval and successful validation. The Director's staleness check reads that date, so every successful refresh keeps it present and current. A failed refresh makes no edit.
OpenCode Zen procedure (the opencode table)
The opencode backend is priced by the OpenCode Zen page, and its catalog
behaves differently from the two provider pages: model IDs differ from
display names, the page lists many models while cafleet curates a few, and
free stealth/preview models appear and disappear. On every refresh, even
when the claude/codex prices are unchanged:
- Price from the Zen page only. Zen's own USD-per-MTok rates are the
billing rates for the
opencodebackend. Never price a Zen model from the upstream vendor's page (Anthropic, OpenAI, DeepSeek, …) — the Zen rate is the one cafleet members are billed at. - Copy the Zen model ID exactly; never slugify the display name. The
page shows a display name ("GLM 5.2", "Kimi K2.7 Code") and a distinct
model ID (
glm-5.2,kimi-k2.7-code). The row's--modelvalue isopencode/<zen-model-id>— the literalopencode/prefix followed by the ID copied verbatim from the page. A hand-derived slug that does not match the Zen ID fails at spawn time. - Re-verify every curated row against the page. For each existing row, confirm the model is still listed on Zen and its price is current. A delisted model's row is removed in the same refresh.
- Handle free models by their published price. A model Zen offers free
for a limited time is priced
0.00in both columns. When the free offer ends: update the row to the newly published Zen price, or remove the row if the model disappears or has no published price. - Keep the table a curated subset. Do not mirror the full Zen catalog — keep a handful of reviewed models spanning the price range. Adding or removing a curated model is a reviewed policy change, approved in the same pull request like any class or ordering change.
Cadence and staleness
Refresh the model list at least every 30 days and whenever the user asks for a refresh. A stale list disables cost efficiency mode — the Director relays an operator choice for those spawns — until a maintainer refreshes the model list, commits the repository source, and completes the release/deployment transaction.
Release-coupled deployment
There is no model-list-only sync path: a committed source file alone does not refresh a running Director's asset copy. To deploy a refreshed model list, the maintainer:
- Bumps the CAFleet release version.
- Builds the release binary with the repository
skills/tree embedded, includingskills/cafleet/reference/coding-agents.md, and publishes the per-target release archives. - Upgrades the installed CLI to that release and runs
cafleet setup, which installs its embedded skill payload for the selected backends, including the unified reference. The binary upgrade and setup complete the deployment.
Installing skills directly from a checkout is a separate contributor operation; it does not replace the embedded-binary build/release → upgrade → setup path.
Ownership boundary
This skill owns model catalogs, provenance/context notes, canonical Role defaults,
and freshness metadata in the unified reference. Runtime documentation maintenance
owns Runtime bindings, bound notes, pane cues, and worked resolutions. The CAFleet
Director owns per-spawn selection under skills/cafleet/roles/director.md; cafleet member create remains the execution
boundary.
Signals
- GitHub stars
- 51
- Forks
- 4
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
cafleet-model-list-refresh- Source
- github.com/himkt/cafleet