arkcli-models

arkcli models

CRITICAL — Before starting, you MUST first use the Read tool to read ../arkcli-shared/SKILL.md, which contains the authentication gate, configuration troubleshooting, and command selection order CRITICAL — If the model query serves Endpoint creation, you must first complete the owning Skill handoff: for ordinary creation, first use Read to read ../arkcli-deploy/SKILL.md; for explicit raw CRUD / CI / unguarded creation, first use Read to read ../arkcli-infer-endpoint/SKILL.md. Before reading the owning Skill, it is forbidden to execute authentication checks, model queries, or any other commands. CRITICAL — All models commands must be preceded by using the Read tool to read their corresponding reference documentation before execution; do not directly call commands blindly.

Step -1 (hard gate): first lock in the owning Skill of the final task

• First determine whether what the user ultimately wants to do is "query models" or use models for an upstream task; do not treat model querying as the final task just because the user mentions models search .
• When the final goal is Endpoint creation, this skill can only serve as a read-only assistant and cannot become the owning Skill: for ordinary creation, read and retain arkcli-deploy; for explicit raw CRUD / CI / unguarded creation, read and retain arkcli-infer-endpoint。
• The owning Skill's query count, result limits, stopping points, and write boundaries take precedence over this skill's general workflow. After completing the handoff, execute according to the owning Skill; only for pure model queries should you continue with this skill's Step 0 and general command selection.

Usage principles

• For model-related needs, prioritize using arkcli models ...
• Although these commands are of the standard CLI type, their implementation entry point still comes from shortcuts/models/
• Only when product commands cannot cover the need should you fall back to ../arkcli-api-explorer/SKILL.md
• This skill is not the default fallback entry point; only when the user explicitly asks about model queries, model asset inventory, or model details should it serve as the primary route. If it is for upstream +chat / +gen / Endpoint creation model selection, first load and retain the corresponding upstream skill; this skill only provides read-only queries. The owning skill for ordinary Endpoint creation is arkcli-deploy；Explicit raw CRUD / CI / unguarded Endpoint creation intent must switch to arkcli-infer-endpoint, and load it before querying candidates
• Voice model boundaries: A hit in the marketplace does not prove that arkcli supports invocation, Endpoint creation, examples, or usage for that model. Integration of independent capabilities such as TTS/ASR should be verified against the corresponding official API/SDK, and bare names should not be stuffed into Responses. Cost inquiries go to pricing models --modality Audio, answering only based on the current pricing items; if nothing is returned, it means the price source does not cover it.
• Offline notices and the marketplace catalog are different evidence domains: When the user mentions SMS/in-app messages, service shutdown dates, or "whether reconfiguration is needed," first verify the corresponding product's official offline announcement; do not first check models search and then use the catalog's Published/Retiring to refute the announcement. If the user does not specify whether they are using Agent Plan, Coding Plan, or pay-as-you-go Endpoint, label the applicable scope of each product separately; for Agent Plan, first checkmodel offline announcement, for Coding Plan checkmodel offline announcement, for pay-as-you-go Endpoint checkplatform model offline announcement. Cite only the specific lines, time zones, and migration targets of the old model in that product announcement,then check whether the recommended migration model in the newer announcement line is also being discontinued, and give the next stop that is still supported; do not apply one package's dates to another product. When the product is unclear, give a conditional conclusion.
• The ultimate goal of this type of question ismigration judgment, not public model selection: first load the corresponding arkcli-plans / arkcli-infer-endpoint owning Skill; only after the announcement is answered, distinguish according to the user's actual configuration auto/ark-code-latest, hardcoded Model Name, self-built ep-.... If the real-time account status query fails, clearly state it is unknown; do not substitute the public catalog status. Only when purely asking about the public catalog lifecycle should you continue this skill's models search process.

Applicable scenarios

• The user wants to search, filter, or compare Ark models
• The user wants to view model details, versions, context, modalities, or lifecycle status
• The user wants to inventory the public foundation model catalog; account-uploaded/fine-tuned assets go to arkcli-custommodel, and package model lists go to arkcli-plans
• Volc only: the user wants to compare TTFT/TPOT, first-token latency, sustained output latency, performance rankings, latency trends, or performance under different input lengths
• Upstream +chat / +gen / +deploy needs to first determine the available model name
• The user asks whether speech models exist, which speech models there are, or what TTS/ASR models are called in the plaza: answer only with plaza-searchable facts and the boundary that current arkcli does not support subsequent scenario capabilities

Anti-trigger signals

• The user just wants direct conversation, image/video generation, or Endpoint deployment: first route to the corresponding skill; if the model name is missing, this skill can be called to query it, but it cannot replace the main routing of the original task. For ordinary Endpoint creation, route to arkcli-deploy; only when the user explicitly specifies raw CRUD / CI / unguarded creation, route to arkcli-infer-endpoint
• The user explicitly requests calling raw Actions, listing OpenAPI, or constructing low-level params: route to arkcli-api-explorer
• The user asks why their own Endpoint is slow: route to arkcli-doctor; public leaderboards cannot be used for Endpoint diagnosis
• The user is troubleshooting authentication, profile, region, or base URL: route to arkcli-auth or arkcli-config
• Do not treat arkcli models as the default entry point; for non-model questions, do not query models first

Business positioning

• This skill is a dependency skill for other business flows, not a terminal skill
• It usually serves three types of upstream goals:
  • Find the correct model for +chat / +gen Find the correct model
  • Confirm deployable models for +deploy Confirm deployable models
  • Confirm model details and versions for business troubleshooting
• Unless the user is explicitly doing a model query, after querying the model you should return to the original task
• Speech follow-up routing: if only asking about the catalog, deliver catalog facts; if actual integration is needed, explain the independent API boundary and guide verification against the official contract, and do not generate unverified call/deployment commands. If pricing is needed, route to pricing's Audio query; do not infer from "no call wrapper" that "pricing cannot be queried."

Quick decision

Price query for a known model

First read references/arkcli-models-get.md, use arkcli models get <model-id> --format json, read pricing.prices. According to service_type、label、dimensions、usage_unit、unit_code and optional usage_period , determine the applicable price; do not take the first entry, and do not read the old pricing.charge_items / pricing.multi_charge_items。price: null indicates missing price,0 indicates zero price under that condition; an empty array does not mean free or not activated; activation and entitlements still depend on pricing.state、pricing.inference_free_usage and other independent fields.--version Select a detailed version; the price is queried based on the returned base model name , and is not guaranteed to be a version-specific quote.

Troubleshooting API capability for an exact model

When the user has provided a complete model ID and asks to verify Responses API for a certain API capability, this is a "single-model fact check", not a candidate search:

• Must use arkcli models get <model-id> --format json, read the complete api_support。
• Do not use models search instead; search is a candidate discovery and reranking view, not the final source of truth for exact model API support.
• In the api_support array, locate the target API by name / key / path , and draw conclusions only based on that item's supported ; if the item is missing, report insufficient metadata.
• If the actual error is an access issue, after querying return to the original owning Skill (such as arkcli-chat) to explain that "the model declares support" and "the current Endpoint / account can access it" are two layers of fact; do not repeatedly trial-and-error with real calls.

Step 0 (hard gate): read the scenario table first, then choose the command

This is the first action for any "find a model by intent" request, prior to search / list / resources command selection. MUST first use Read to open references/arkcli-models-scenario-table.md to determine whether the intent hits a scenario tag, and only then decide what command to run. This manually curated 场景标签 → 推荐模型 table isthe highest-weight signal for intent ranking, overriding all naming heuristics / modality / capability filters below。

Counterexamples easily hijacked (required reading) — the following intents that "smell like hard metrics" are essentially scenario tags; you must check the scenario table first, and do not instinctively jump to --capability / --modality downgrade line:

User says	❌ Don't directly	✅ Scenario tag hit at Step 0 → Recommendation
"Complex reasoning / multi-step / strongest model"	search --capability thinking	Complex reasoning / Agent tasks → check the table, then use real-time lifecycle to exclude offline candidates
"Which model to use for image generation"	resources list --modality image and stop	Image generation → doubao-seedream-5-0
"Do video / role-play / field extraction"	search --modality ...	Video generation / role-play / information extraction → check the table

After a hit, execute according to the JOIN protocol in the table: take the recommended model family name stem → arkcli models search <族名词干> go back to the left table to verify facts → pin the recommendation + add 2–3 alternatives.The version/full-id in the table is only a starting point; hits are based on what search returns in real time(measured table ids can become stale).

Only in these two cases should you skip the scenario table and downgrade to the following search + naming heuristics:

• The user gaveexplicit numeric/capability hard constraints("200K context", "must support functioncall"), and the scenario table has no corresponding tag;
• The usernamed a third-party / open-source / historical model(qwen, glm, Seedream 4.5…) — do not forcibly replace it.

Note the distinction: "complex reasoning" is a scenario tag (check the table first),does not equalthe user gave thinking Hard indicators. The former goes through step 0 and validates the real-time lifecycle; only the latter follows the degraded path; old models within a table being taken offline cannot become recommendations for new onboarding.

Layer boundary (important, don't mix them up): the scenario table is the "model plaza selection layer", answering "for this intent, which model to select in the plaza", and the data source is always models search（catalog）。 What it provides is the catalog-recommended model name (e.g. image generation → doubao-seedream-5-0）。

• "Whether the current profile can invoke it and what the exact invocable id is" isthe downstream availability layer's job, handled by resources list → models get → +gen / +chat (arkcli-gen already implements it),and is not within this table's responsibility。
• Therefore: if the user has apure selection question("which model to look up/select") → only go through models search，do notgo off to query resources list turning "selection" into "checking available resources". Only when the userreally wants to generate / invokeshould you drill down to resources list to resolve the real id for this profile.

This isthe intent-ranking lineexclusive to it. Enumeration / inventory / statistics is another line, going through list, and does not attach to the scenario table for re-ranking.

Command selection

• The user only knows a vague model name / wants to search by intent ("strongest video generation", "200K context LLM", "models that support thinking"): use search — it does keyword fuzzy matching + modality/context/capability structured filtering
• If you need to enumerate by modality / pagination parameters, or match by exact name: use list
• full inventory of the public catalog → models list --page-all; "models I uploaded/fine-tuned",cm-* → arkcli custommodel list/get; "which models my Plan supports" → plans model-list --plan <plan>. When the scope of "my models" is unclear, clarify first; do not pass off the public catalog as account assets.
• Volc only: for performance rankings, trends, or input-length comparisons, first read references/arkcli-models-performance.md, then use models performance rank、trend or input-length
• If there is already a clear model ID: use get
• If it is only to find a model for +chat / +gen / Endpoint creation: first retain the owning skill, initially execute only one bounded models search <keyword> --size 10 --format json(omit the keyword when there is none), and once a successful complete result forms candidates, immediately return to the original task; do not loop get over each candidate. For empty results, incomplete captures, or cases needing verification against the exact API, follow the search recovery rules to handle; a single query budget must not become a reason for missing key evidence.
• The userproactivelywants to activate a certain base model ("first get doubao-seed-1-6-flash activated", "I want to try the fast-infer sub-service", "first preview the activation request"): use activate, first read references/arkcli-models-activate.md; if the user merely wants to deploy / create an endpoint, deploy / infer-create can trigger implicit activation on its own, so do not activate separately first

Agent quick execution order

1. First confirm whether already logged in; if unsure, first look at arkcli auth status
2. When the user's description carries intent (modality / numeric capacity / capability / cache category), use arkcli models search + the corresponding flag (--modality、--min-context-window、--capability、--cache-type...); for cache capability you must look at cache_types, do not use the old capabilities.caching
3. When the user only knows a vague name, still use arkcli models search <keyword>(by default returns all hits, no pagination)
4. When you need to fully enumerate by modality or paginate for statistics, use arkcli models list
5. When the user asks about "custom models/my models created in the last N days", route to arkcli-custommodel to query account assets; only public catalog date statistics use models list --page-all. Filter fields must follow the actual output of the selected command; the two schema types must not be mixed
6. When you already have an explicit model ID and need details, use arkcli models get
7. When the user explicitly wants to enable a model (proactive activation, not for immediate deploy), use arkcli models activate <name> [--sub-services ...]; for CI scenarios add --yes, for local request preview use --dry-run, but it must not be called server-side validation
8. After finding / activating the model, return to the upstream chain that initiated it:+chat / +gen / +deploy

Typical business chain

0. Complete the full model ID for data-plane commands (mandatory prerequisite)

First retain the exact Endpoint / Custom Model ID provided by the user, as well as the valid Plan invocation name returned by the current resource directory.Only when a versioned ID for a public foundation model is needed, combine it from this round's name and non-empty primary_version ; the Plan's output_name / routing alias is not a "missing version", and the date must not be mechanically appended. Actual invocation follows the owning Skill's execution context; a catalog hit alone does not guarantee the account can invoke it.

primary_version format is not fixed，Do not use regex to judge on your own whether it "looks like a complete ID". Actually observed format distribution (about half of ~152 models are not 6-digit):

Format	Sample full ID	Common family
YYMMDD(6-digit date)	doubao-seed-1-6-251015	doubao series
YYYYMMDD(8-digit date)	qwen3-14b-20250429、glm-4-6-20250930	qwen / glm open source
Qualified prefix + date	doubao-seed-2-0-code-preview-260215、doubao-seed-1-6-nano-unfiltered-250928	Canary / variant
Pure routing string	kimi-k2-6-modelhub、open-source-models-default	External access
Short number	qwen3-235b-a22b-instruct-2507	Some qwen
Empty string	doubao-seed-tts-2-0(full ID equals the family name)	Some TTS / ASR

Two acquisition paths, in decreasing order of efficiency:

• Path A (efficient, reuse existing results): when arkcli models search <keyword> or arkcli models list has just been executed, each item in the returned JSON includes a primary_version field; the Agent reads it directly and concatenates <name>-<primary_version>, with no extra call needed.search also returns structured fields such as context_window / input_modalities / output_modalities / capabilities / cache_types in sync (from ArkModels enrich); downstream can judge directly based on this whether the model is suitable, saving the cost of another call to get cost of。
• Path B (separate query): when only the bare name is known,arkcli models get <name> --transform 'primary_version' directly returns the version number

Note：--transform the output contains JSON double quotes (such as "251228"); before shell concatenation it must be stripped with tr -d '"' :

VER=$(arkcli models get doubao-seed-1-8 --transform 'primary_version' | tr -d '"')
# VER=251228  -> full ID: doubao-seed-1-8-251228
# VER=""（空串模型）-> 直接用族名: doubao-seed-tts-2-0
if [ -n "$VER" ]; then
  MODEL="doubao-seed-1-8-$VER"
else
  MODEL="doubao-seed-1-8"
fi
arkcli +chat --model "$MODEL" "你好"

1. Find a model for trial

models search [--modality / --capability ...] -> +chat / +gen

2. Find a model for formal integration

models search [--min-context-window / --capability ...] -> +deploy

3. Filter by hard metrics

# 找最新最强的 200K+ 文本模型，含 thinking 能力
arkcli models search --modality text --min-context-window 200000 --capability thinking --strict-filter

# 找视频生成模型
arkcli models search --modality video --strict-filter

# 找多模态 LLM
arkcli models search --multimodal --output-modality text --strict-filter

--strict-filter is strongly recommended: the default behavior is "keep on missing data" (to avoid false kills); with strict added, only models that satisfy the conditions 100% are returned.

Catalog evidence and context units

When the user asks about parameter support, runtime behavior of missing parameters, search/get conflicts, or NotFound, first read get evidence and troubleshooting rules. Missing fields cannot be treated as negative evidence, and conflicts must have their sources labeled separately; the public catalog cannot be used to inventory account-custom assets.

• models search/get proves the public catalog and metadata, but does not prove that the Endpoint has been created, that console candidates are visible, that the Key is valid, that the balance is sufficient, or that the current account has permissions. For binding issues, first use infer endpoint get / resources resolve to get the real binding, then check the model details; for Custom Model, base_model_* is the lineage and cannot replace the actual cm-* binding.
• api_support is determined by the supported of the target API item; a missing item or a capability of null/unknown means "insufficient evidence," not true or false. For image input capability, look at input_modalities; text output cannot be used as counterevidence that image reading is unsupported. Report catalog capability separately from the result of this call.
• context_window keep the exact integer for filtering. Display abbreviations follow 1K = 1024、1M = 1048576 tokens: 131072 → 128K, 262144 → 256K, 1048576 → 1M, and also give the original value; when not divisible, give the exact token count directly, and do not write 262144 as 262K.
• When the user asks for activation but no model is specified, follow real-time candidate template to first check 10 items, project the real fields, and display 5–8 representatives by target; if there are not enough, do not fabricate, and handle empty/defective cases according to the recovery rules. For new onboarding, Shutdown/Retiring are not recommended. Keep 0/1/N selection separate from write authorization; enabling a sub-service, activating a base model, and creating an Endpoint cannot substitute for one another.
• The full ID, version, and display name are resolved according to the current get reference; do not split the ID yourself using the "last six digits," and do not try to fix NotFound by switching families or repeatedly activating.

Common degradations

• Authentication failure: go to ../arkcli-auth/SKILL.md
• profile / region looks wrong: go to ../arkcli-config/SKILL.md
• Business-wise it is only to find a model name for +chat、+gen、+deploy , so prioritize completing "look up the model, then return to the original task"; do not stop at models itself

Command overview

Command	Description
arkcli models search [keyword] [filters]	Agent first choice: full recall + ArkModels enrich + modality/context/capability/cache type structured filtering + reranking; returned fields include context_window / input_modalities / output_modalities / capabilities / cache_types
arkcli models list	Full enumeration by modality, pagination statistics, model asset inventory; lightweight, without enrich
arkcli models get <id> [version]	Full details of a single model (aggregates multiple APIs, heaviest and most complete)
arkcli models performance {rank,trend,input-length}	Volc only: public model performance rankings, trends, and input length comparisons

Tier heuristic for naming conventions (degradation fallback: enabled only when the scenario table does not match)

Priority mnemonic: scenario table match (★★★) > naming heuristic (★★, this section) > update_time. First go through the scenario table in "Quick Decision Step 0"; only when the scenario table does not cover that intent, or when the user names a third-party/open-source/historical model, use the naming heuristic in this section for ranking.

search After adding filter, there are usually still multiple candidates left; regular tier signals in the naming can help the agent do the final ranking step.This is a heuristic, not a hard rule: hard indicators (context_window / capabilities / modality) always take precedence over naming.

Generation (major version) — highest priority

2-x > 1-8 > 1-6 > 1-5 > ...

Generation jumps are usuallystronger than tier. Example:doubao-seed-2-0-mini is stronger than doubao-seed-1-6-proon most tasks, because the base model generation gap is larger than the size-tier gap.

tier (size tier within the same generation)

pro  ≥  无后缀  >  lite  >  flash  >  mini  >  nano

• pro: flagship, largest size / strongest capability
• no suffix (e.g. doubao-seed-1-8): mainstream tier, usually ≈ pro
• lite: cost/performance balance
• flash: speed-optimized
• mini / nano: low latency, high concurrency, lowest cost

specialty suffix (not part of tier comparison, choose by use case)

-code        → 编程优化（Doubao-Seed-Code 等）
-thinking    → 思考能力强化（更长 reasoning）
-vision      → 视觉理解强化
-character   → 角色扮演 / 长旁白
-translation → 翻译专用
-tts / -voice → 语音合成
-asr         → 语音识别

specialty models, within their domain,are usually stronger than same-generation general-purpose pro, but are not portable across tasks.

primary_version comparison notes

• Within the same family: the newer the date, the better (260215 > 251228 > 251015）
• Between different families：cannot be compared numerically。qwen3-14b-20250429(8 digits) and doubao-seed-1-6-251015(6 digits): the former is numerically larger, but that has nothing to do with "which is stronger"
• To compare "which is newer", always use the update_time field (ISO 8601, lexicographically comparable); do not parse primary_version

Decision rules of thumb

filter (硬指标，必须满足)
   ↓
代次 (2-x > 1-x，跨代差距通常 > 同代 tier 差距)
   ↓
tier (pro > 无后缀 > lite > flash > mini > nano)
   ↓
update_time (同代同 tier 时，新者优先)

Sorting is already implemented in the search command

No need for the agent to do client-side reordering —— arkcli models search uses a two-phase sort of "group by family first, then fine-sort within the group":

1. bucket             — keyword 可见性 (name 命中 > desc 命中 > 兜底 > hidden)
   ↓
2. 跨 family：       按 family 的"代表分"排（family 成员中的 max ctx → max update_time → family 名）
   ↓                  → 同 family 的所有成员保持在一起
3. 同 family 内部：  gen DESC → tier DESC → ctx DESC → update_time DESC → name ASC

Key design：

• Family grouping precedes fine sorting. The doubao-seed family (max ctx=262144) is placed entirely before doubao-seed-character (max ctx=131072) and all ctx=null families. This avoids strange results that violate transitivity, such as "1-6-vision of the same family ranking ahead of 1-8".
• Within the same family, gen takes priority over ctx. A new version will float ahead of older versions that already have ctx data even if the ArkModels metadata has not yet been filled in (context_window=null). Example:glm-5-1(gen=501, ctx=null) ranks before glm-4-6(gen=406, ctx=262144);kimi-k2-6(gen=600, ctx=null) ranks before kimi-k2-5(gen=500, ctx=262144).
• Generation takes priority over tier. Within the same family, doubao-seed-2-0-mini(gen=200, tier=50) ranks before doubao-seed-1-8(gen=108, tier=80) —— the gap across generations is usually larger than the tier gap within the same generation.
• Do not compare gen/tier across families. pro/lite/mini are naming conventions internal to a family and are not comparable across families —— the family order is determined by the family representative score (max ctx + max time).

Old models tagged with any of 体验隐藏 / 推理隐藏 / 广场隐藏 automatically sink to the bottom (they will not be hidden from list/search, but will always be at the end of the results).

Note：体验隐藏 / 推理隐藏 / 广场隐藏 is a legacy-page hidden tag in the Volcano Ark model platform customized_tags and is unrelated to this CLI command; arkcli only reads them for sorting.

Model lifecycle: Shutdown / Retiring / Published

ArkModels records lifecycle_statuson public model catalog entries, with three values, and Search handles them differently.This only describes the catalog view, not the source of truth for the shutdown of Agent/Coding Plan packages or personal Endpoints; the catalog Published is not enough to override a product end-of-life announcement:

status	Meaning	search default behavior
Published	Normally displayed in the public catalog, does not mean any package still supports it	✓ shown
Retiring	The public catalog is being retired; new integrations are not recommended; actual callability still depends on the product and account	✓ Displayed, the agent should verbally remind and find an alternative
Shutdown	The public catalog has been taken offline; the independent timeline of another product cannot be inferred from this	❌ Filtered out by default(add --include-deprecated to bring it back)

Additionally,display_name containing the 废弃 / 下线 / 已下架 / deprecated keyword are also treated as Shutdown (a fallback, because some legacy models are not in the ArkModels metadata and rely on manual tagging).

Agent behavior conventions：

• No need to implement client-side logic to "filter out Shutdown" — search already does this by default
• When you see lifecycle_status="Retiring" a model,proactively remind the user that it is being retired, and try to find a newer version in the same family (use search + the correct keyword)

❌ Anti-patterns (required reading for agents)

The following behaviors are wrong — choosing the wrong command will prevent the agent from getting enrich data (context_window / modalities / capabilities) and from hidden sinking / weighted reranking, leading to incorrect recommendations.

• ❌ Do not use list to find models — finding models (any "which model / find an X model" intent) should always go through search。list does not do keyword fuzzy matching, does not do weighted reranking, and does not return enrich fields.
• ❌ Do not use list --modality video to select video generation models — use arkcli models search --modality video --strict-filter, which combines ArkModels' output_modalities and task_types fallback, resulting in more accurate recall and allowing further combination with --min-context-window / --capability filtering.
• ❌ Do not use list --modality text to select an LLM — same as above, use search --modality text --strict-filter。list --modality text only looks at the foundation_model_tag.filter_domains layer of signal and will miss many models.
• ❌ Do not first list then get to verify parameters such as context_window —— search already returns context_window / max_input_tokens / max_completion_tokensdirectly in the results, saving an get call.
• ❌ Do not search without passing a keyword just to "see the 5 hottest" — now, not passing a keyword returnsall 152 entriessorted by UpdateTime descending, no longer a curated hot list. For a small number of results, use --size 5。
• ❌ Do not recommend models with lifecycle_status="Retiring" to users for new integrations — although these can still be called, the vendor has already marked a retirement countdown. When you see Retiring candidates, proactively notify and search for a newer version.
• ❌ Do not do client-side secondary filtering on search to compensate for the shortcomings of list — directly use search 's built-in --modality / --min-context-window / --capability flag。
• ❌ Do not force exact ID / specified version verification into a search; at this point directly get. Only for fuzzy names or finding candidates should you first search。
• ❌ Do not, just because models list has no server-side time filtering flag, go arkcli api --list to probe the Raw API — first models list --page-all --format json, then use local JSON processing to filter by create_time .
• ❌ Do not tell the user "the CLI does not have this capability, please go to the console", unless you have confirmed that arkcli models list --help the current version truly has no enumerable output, and local JSON filtering also cannot accomplish the statistics the user wants.

Legal list sole purpose:

• ✓ Do --modality tofull exhaustive enumeration/audit(not to "find the strongest")
• ✓ Need total_count this kind of statistic
• ✓ --name foo exact match (agents can hardly use it, because search can also hit it)
• ✓ Inventory public directories and their time fields; account-custom assets cannot use public models list as a substitute

Reference

• arkcli-chat -- after finding the model, enter the conversation / inference pipeline
• arkcli-gen -- after finding the image/video model, enter the generation pipeline
• arkcli-deploy -- after finding the model, enter the Endpoint deployment pipeline
• references/arkcli-models-list.md
• references/arkcli-models-get.md
• references/arkcli-models-search.md
• references/arkcli-models-scenario-table.md -- scenario-based recommendation table (highest weight in intent ranking) + JOIN validation protocol
• references/arkcli-models-activate.md