AI Models — Research & Update Workflow

When to Use This Skill

• Bumping a text, image, or video model to a newer version
• Adding a new image/video generation model or provider (Vercel gateway, Replicate, fal.ai)
• Updating pricing data (per-token, per-image flat, per-image tiered, per-second)
• Verifying model specs (context window, output limit, cost) against providers
• Grounding a model's first broad public release date and source
• Auditing hosted usage metering against prepaid organization credit

Key Files

Tools

Script: .agents/skills/ai-models/scripts/model_info.py (symlink to .tools/model_info.py)

Model lookup

# Text / language models
python .agents/skills/ai-models/scripts/model_info.py <model_id>

# Image models
python .agents/skills/ai-models/scripts/model_info.py --image <model_id>
python .agents/skills/ai-models/scripts/model_info.py --image --all

Discovery source: models.dev/api.json. Accepts exact IDs (anthropic/claude-sonnet-4.6) or substring search (gpt-5.4). Its release_date is a lead to verify, not authoritative provenance to copy into the catalogue.

Note: models.dev has per-token costs but not per-image tier breakdowns. For per-image pricing (OpenAI quality tiers, BFL flat rates), consult provider docs directly.

Provider pricing pages

Providers & model IDs

The same model has different ids — and different availability and pricing — across providers; an id is never portable. Two cataloguing patterns:

• text / audio / image_tools / 3D — one card = one provider or exact endpoint; id is in that provider's format, and the provider field (or namespace) fixes the route.
• image — one intrinsic card carries per-provider bindings, like video. The service view adds a primary provider for older single-provider consumers.
• video — the ecosystem is fragmented, so a card is canonical (vendor/model, e.g. google/veo-3.1) and carries a providers record (keyed by provider) of bindings, each with its own call id + meter. Default-provider choice is deferred (see Video Models). Pick a route with video.binding(card, provider).

• Availability + price differ per provider. Veo 3.1 Lite is on OpenRouter/fal.ai but not the Vercel gateway — a canonical card just omits the Vercel binding. Veo 3.1 audio-on is $0.40/s on both Vercel and fal, but fal also meters silent ($0.20/s) and 4K, while OpenRouter exposes only $0/MTok token pricing for video — no usable per-second meter (don't invent one).
• fal.ai is the broadest video/image catalogue (pay-per-use); billing unit is per-model — per-image, per-megapixel, or per-second video — retrievable from its Platform pricing API.
• Image facts are multi-homed across Vercel, fal, and OpenRouter where verified. Service listing is a separate decision; a listed card does not establish that every provider, installed adapter, or request mode can serve it.

What the catalogue is for

Keep one package with two explicit entries: @grida/ai-models for facts and @grida/ai-models/grida for service policy. Service definitions consume facts; the root entry never imports or re-exports Grida policy. Add verified model facts independently of Grida admission. Manage Grida choices in the service definitions, not source declaration order or provider timestamps.

The shared execution SDK (@grida/ai) retains its Grida defaults by explicitly importing the service entry where needed. Its catalog store accepts an optional snapshot or refresh URL; callers need not inject a catalog. Keep provider execution and refresh lifecycle in the SDK and the schema-1 codec in the service entry; do not restore agent-local adapters or duplicate membership.

Preference discipline: an optional default must be listed and nonlegacy. The independent order is partial; unknown and duplicate IDs are errors. Views sort default first, other active models before legacy, then explicit rank, label and ID. Explicit user selections are not replaced by a recommendation. Native subscription and custom-endpoint choices remain with their own runtime owners.

The catalogue states what is true and useful now. Its shape must never be a record of how recently someone got round to updating it — a stale entry is a wrong answer, not a conservative one.

• Price the steady state, not the promotion. When a vendor runs an introductory or time-limited rate, catalogue the price that applies once it ends and note the date in a comment. Otherwise the promotion expiring is a silent cost increase. Recheck when that date passes: a promotion can also be made permanent, which changes the fact, not the rule.
• Deprecate a card that is still a real choice; remove one that is not. Grida legacy: true (projected as deprecated for existing consumers) is for a model someone might still reasonably pick — same price as its successor, or better at something. Delete the entry when the successor is strictly dominant (never worse on any axis, better on at least one): a card nobody should choose is noise in every picker, and keeping it is not caution.

Removal from the service catalog is the kill switch — the id stops passing the run gate, and on a published catalogue that reaches installed clients within a refresh interval (docs/wg/platform/hosted-ai.md). That decisiveness is the point; it also means removal is the wrong tool for tidying. It does not require deleting factual identity or imply upstream retirement. Preserve schema-1 membership and legacy fields when publishing; installed clients ignore additive preferences. The v1 snapshot still has broad GG/BYOK membership and per-family fallback behavior; runtime adapter support and authorization remain independent checks.

Release dates and provenance

Every bundled entry carries a release object:

{
  date: "2026-07-09", // YYYY-MM-DD, or null only when an endpoint day is unknown
  basis: "model", // or "provider_endpoint"
  source_url: "https://vendor.example/release-note"
}

The date means the earliest day the exact named model or variant became broadly available. A public preview counts; a closed, invitation-only, or limited preview does not. This is intrinsic model metadata, so adding a provider binding does not change a basis: "model" release. Use basis: "provider_endpoint" only when the release fact describes a serving route because no exact upstream model launch can be established. An endpoint-shaped card may still use basis: "model" when its exact underlying model and launch are documented.

Do not substitute any of these:

• snapshot generated_at
• the date Grida added the card
• the date one provider added a binding
• a later GA date when an exact public preview date exists
• an API object's opaque created timestamp

Source priority for release facts:

1. Vendor release note, changelog, announcement, or model card that names the exact variant.
2. Vendor-maintained repository or official provider documentation for the exact endpoint.
3. First-party vendor social announcement when no durable release page exists.
4. Serving-provider history, only for basis: "provider_endpoint" or when the vendor has no usable record.
5. models.dev only to discover candidates; verify its date against one of the sources above.

If no authoritative source establishes the exact day, keep date: null with an HTTPS source showing the endpoint's history. Never infer a day from search-result ordering, repository commit time, or Grida history. Base snapshot types keep the field optional solely for older snapshots and custom models; every bundled card must include it, and tests enforce valid calendar dates, complete provenance, and the narrow null rule.

Text Models

Facts live in packages/grida-ai-models/src/models.ts under models.text.catalog: Record<CatalogId, ModelSpec>. Grida tier assignments live in packages/grida-ai-models/src/grida/tiers.ts; each must resolve to a listed service member.

Fields to update per tier:

• id — gateway format: provider/model-name
• label — human-readable name
• release — grounded date, basis, and first-party source under the contract above
• contextWindow, outputLimit — from model_info.py
• cost — { input, output, cacheRead?, cacheWrite? } per 1M tokens

Image Models

Facts live in packages/grida-ai-models/src/models.ts under models.image.models. The service view adds membership, legacy state, primary-provider choice and request presets. Editor consumers reach that joined view via import { ai } from "@/lib/ai/ai" (which also adds ai.toMills and ai.server.methods.*).

Pricing types

Three pricing schemes, modeled as discriminated union ImageModelPricing:

per_image_tiered  — quality x size tiers (e.g. OpenAI)
    { type: "per_image_tiered", tiers: { "medium/1024x1024": 0.034, ... } }

per_image_flat    — single price per image (e.g. BFL Flux)
    { type: "per_image_flat", usd: 0.06 }

per_token         — charged by token (e.g. Google Gemini)
    { type: "per_token", input: 0.5, output: 3.0 }

Fields per model

• pricing — real provider data, one of the three types above
• avg_cost_usd — existing fallback billable-cost estimate, not a provider quote. Retained compatibility surface; do not treat it as independently verified pricing or expand it into service routing/billing policy.
• release — intrinsic model release; do not use a provider-binding date
• min_width, max_width, min_height, max_height, sizes — dimension constraints
• Add new model IDs to the ImageModelId type union

New providers

Image generation currently routes through the Vercel AI Gateway (gateway.image(id)); fal.ai is the main alternative for models the gateway lacks (see Providers & model IDs). For a new provider:

• Verify the gateway supports it (or wire a new provider label for fal.ai / OpenRouter)
• Add to the Vendor type if needed
• Add a logo component and register in the Logos map on the models page

Video Models

Facts live in models.video.models in packages/grida-ai-models/src/models.ts. Like image, a video card is canonical: id is provider-agnostic (vendor/model, e.g. google/veo-3.1) and holds intrinsic specs; per-provider routes live in providers, keyed by provider.

Card shape

• Model (intrinsic): id (canonical), label, release, vendor, aspect_ratios, min_duration/max_duration, audio, url (original vendor's model card). Grida request default (resolution/aspect/duration/audio) belongs to the service view.
• providers: Partial<Record<VideoProvider, VideoProviderBinding>> — one binding per serving provider: provider, id, pricing, avg_cost_usd, optional url/deprecated. No preference order — the default-provider choice is deliberately deferred to the runtime. Look a route up with video.binding(card, provider).

Cards catalogue the image-to-video route only (canvas-relevant; Grok's sole mode), so each binding has a single id — on fal the capability is keyed into the id (fal-ai/veo3.1/image-to-video). Don't add a per-capability endpoints map until a second capability is actually served: identical ids across capabilities are YAGNI, and divergent ones (other fal endpoints) are a new binding/id when needed.

provider is a bare routing tag — auth (incl. BYOK) is a runtime concern, not catalogue data, so there is no provider registry or byok flag. The catalogue's only job is to hold each provider's real id + rate.

Cost

avg_cost_usd (per binding) = its rate at the model's default (resolution, audio) × default duration, plus any required input-image surcharge. Video dwarfs image costs (Veo 3.1 ≈ $3.20 for an 8s 1080p clip). The current prepaid-credit gate checks a global balance floor, not an estimated per-request ceiling, so audit metering and bounded-overspend exposure before serving a new video route.

Pricing (lives on the binding)

per_second, nested resolution → audio-mode → USD/s, with an optional provider-native usd_per_input_image surcharge. The rate varies by both resolution and whether audio is generated, so the keys are the exact (resolution, mode) combos that provider serves & meters:

{ type: "per_second", usd_per_second: {
    "720p":  { audio: 0.4, silent: 0.2 },   // fal: meters both modes
    "1080p": { audio: 0.4, silent: 0.2 },
    "4k":    { audio: 0.6, silent: 0.4 },
} }
// Vercel Veo omits "4k" + "silent" (gateway sells neither); Seedance lists only "audio" (bundled free).

Adding a model / route

• Factual boundary: a model requires verified provider bindings and grounded rates. Service boundary: list it only after Grida can execute the offering; factual identity alone is not admission.
• New model → add the canonical id to VideoModelId and a factual card with ≥1 binding. Separately define service membership and request presets; the chosen preset must be supported and priced by the route that executes it.
• New route for an existing model → add a VideoProviderBinding under its provider key, only with a verified rate (e.g. OpenRouter surfaces $0/MTok for video — not usable; leave it out).
• New capability (e.g. text-to-video) → only when actually used. If a provider keys it into a separate id (fal), that's a new binding/id; revisit the single-id shape only then.

Image Tool Models

Live in models.image_tools.models in packages/grida-ai-models/src/models.ts. Flat cost_usd pricing via Replicate.

Hosted Usage Metering

Grida Gateway (GG) usage is metered against the organization's prepaid AI credit. Unit: mills (1 mill = $0.001 USD).

• ai.toMills(cost_usd) converts a provider cost to the integer usage unit.
• The AI seam checks the organization's cached credit entitlement before the provider call and ingests usage into Metronome after the call.
• Text uses observed token usage. Media routes use verified catalogue pricing for the served request, with avg_cost_usd only where the provider does not expose a more exact billable dimension.
• The current gate is a global balance floor. There is no per-model provider-cost budget; do not invent one when updating a card.
• BYOK text calls bypass GG metering because the user pays the provider directly. Hosted media remains billable unless its route explicitly uses a supported BYOK provider.

After Any Update

• Facts and Grida membership/preferences were updated in their separate canonical homes
• Optional defaults still resolve to active listed members; order is deliberate, partial, and duplicate-free
• Existing explicit selections, runtime provider gates and installed schema-1 clients remain compatible
• Every bundled model has a complete release; date semantics and source priority were followed
• models.dev dates were treated as discovery hints and verified against authoritative sources
• pnpm tsc --noEmit passes
• docs/models/index.md matches the code
• /ai/models page renders correctly
• No stale model IDs remain (grep for old IDs)