Skip to main content

EXTENSIONS

Built by operatives — models, drivers, vaults, and reports, the parts that plug into Swamp.

Filter by what you need and pull what fits.

Selection
4 results
label:catalog

Music Library

@magistr/music-library · v2026.08.19.1

Multidimensional music library catalog built WITHOUT touching the

upd Aug 194 pullsA100/100

Agent Provider Catalog

@mgreten/agent-provider-catalog · v2026.07.31.1

A pure, deterministic provider/model catalog with tiered fallback and dispatch resolution for agent-dispatch pipelines: a caller-supplied, versioned table maps abstract roles to ordered CLI-agent provider/model tiers, and only throttling signals advance a fallback tier.

upd Jul 31105 pullsA100/100

Sourced Kb

@stateless/sourced-kb · v2026.06.23.2

A domain-neutral, sourced, versioned knowledge base — the provenance-aware core generalised out of @stateless/llm-catalog. One uniform `entry` record (open `kind` + open `facets` + `claims` + `relations`, like @stateless/inventory), but with a provenance envelope (asOf, source, versionPins, supersededBy) on every volatile assertion, so it can hold external, decaying, contested knowledge honestly — a value without a date + source is not trustworthy here. Declarative lifecycle: `apply` materialises the declared entries (re-run = versioned trend), `update` folds in a public catalog without clobbering local truth, `prune` soft-retires undeclared entries, `contribute` sanitises selected entries into PR-ready public fragments. It knows no domain (no typed facets, no compute methods); a consuming catalog — LLM-ops, cloud-storage pricing — is an instance whose entries carry that domain's kinds and facets.

upd Jun 2315 pullsA100/100

Llm Catalog

@stateless/llm-catalog · v2026.06.23.1

A sourced, versioned knowledge base of LLM-ops knowledge — NOT a control plane for running models, but the structured, CEL-queryable record that running extensions read to decide which model to run where, with what settings, at what cost. Six subject kinds (model, runtime, provider, hardware, technique, endpoint), all the same uniform `entry` shape (open kind + open facets, like @stateless/inventory); a model's run-options embed on the model in runsOn[] keyed by endpoint, and capacity/plan answer "what to run where" over them. The twist: it records external, decaying knowledge, so every volatile assertion carries a provenance envelope (asOf, source, versionPins, supersededBy) — "best vLLM version" is derived as the latest un-superseded claim, never a bare rotting field. Declarative: `apply` materialises one `entry` resource per id (re-run = versioned trend); `prune` soft-retires undeclared entries.

upd Jun 230 pullsA100/100