Chimeraforge MCP Server

Chimeraforge

A local-first, model-agnostic LLM deployment planner. It turns "which model, quantization, GPU, and backend -- how many, will it fit, will it hit my SLO, what will it cost" into a fast answer with explicit evidence and assumptions, from your shell, your Python, or your AI assistant.

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

The trust principle

Since 0.96.0, serving quote budget checks compare dated whole-instance prices to an exact monthly USD cap.

Since 0.95.0, passive fleet reports render an existing receipt against its original plan in Markdown or HTML.

Since 0.94.0, read-only Kubernetes inspection accepts an operator serving declaration directly and retains every declared resource.

Since 0.93.0, offline inventory arithmetic checks a saved plan against a supplied NVIDIA CSV without a local GPU query.

Included in 0.92.0

• Continuous fleet export serves cached native gauges on loopback, with all-member freshness and failure views and owned shutdown. Scrapes make no backend calls.
• Whole-campaign diagnostics render complete native campaigns as HTML, SVG or Markdown, retaining every execution, original member and unknown value.
• Native chat trace replay preserves ordered role histories across ordinary, saved-plan, fleet and campaign paths. Missing native usage stays unknown.
• Operator-authored serving declarations capture concrete intent, quote dated whole instances and check native configuration without optimizer predictions.
• Selected-batch inventory preflight adds the saved active-sequence KV increment to the saved batch-one interval for each original device.

Every number is labeled measured, extrapolated, derived, estimated, or unknown, and the tool refuses to fake the ones it can't stand behind. VRAM and KV-cache are derived -- exact arithmetic over the model's real architecture, not a measurement. Throughput is a measured lookup only on the rig the corpus was measured on; on any other GPU that row is scaled by memory bandwidth and reported as extrapolated, carrying the row it came from, the rig it was measured on and the ratio applied, because a 17.8x bandwidth extrapolation (RTX 4080 Laptop 432 GB/s -> B200 7700 GB/s) is not a measurement of your card. Failing that it is an explicit roofline estimate -- never presented as data it isn't. Quality below the bundled corpus reports unknown, not a made-up score. A 0-result plan names the exact gate that rejected every candidate instead of a generic "nothing found." No telemetry, no phone-home, works air-gapped.

Give it a model -- a size class, a Hugging Face repo, an Ollama tag, or manual overrides for an unreleased model -- and it searches the (model x quantization x backend x GPU count x tensor/pipeline parallelism) space against VRAM, quality, latency, cost, energy, and an opt-in safety gate, then hands back the cheapest config that meets your SLO.

34 commands, one tool: plan - check - bundle - study - serving - deploy - deploy-verify - deploy-inspect - inventory-check - suggest - measure - workload - monitor - monitor-fleet - monitor-fleet-exporter - validate - doctor - contribute - catalog - safety - bench - trace - trace-fleet - trace-fleet-campaign - trace-campaign - trace-envelope - score - gate - eval - compare - refit - report - mcp - serve. This is the command set for Chimeraforge 0.96.0.

The empirical corpus traces to Technical Reports TR108-TR137 (~204,000 real measurements on consumer GPUs). See the CHANGELOG for the full feature history.

What the planner itself reads. The ~204,000 measurements are the research program's total across its reports. The tables plan looks numbers up in are far smaller:

Anything outside those rows is extrapolated (scaled by memory bandwidth from the reference GPU), derived (exact arithmetic) or estimated (roofline), and every number in a plan says which. The data records its own limits:

• Every throughput row is FP16. Quantized throughput is the FP16 row times a quant multiplier, not a measurement of that quant.
• Every row was measured on one GPU. Other hardware is bandwidth-extrapolated and labelled 'extrapolated', not 'measured'.
• The largest model measured is 3.21B; predictions above that extrapolate the power law.
• No SGLang rows exist; that backend falls through to the fp16/power-law path.

---

Install

Try it with no install:

uvx chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"
pipx run chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB"

Install for real:

pip install chimeraforge            # planner + model resolution (HF/Ollama) + suggest/measure/safety/bench
pip install "chimeraforge[bench]"     # + GPU environment metadata for benchmarks (pynvml)
pip install "chimeraforge[mcp]"       # + MCP server so Claude/GPT/Cursor can call the planner
pip install "chimeraforge[eval]"      # + quality evaluation (ROUGE-L; BERTScore additionally needs `bert-score` + torch)
pip install "chimeraforge[refit]"     # + coefficient refitting (numpy, scipy)
pip install "chimeraforge[all]"       # everything

Python 3.11+ (since 0.82.0; the patched filelock dependency requires it). The core install covers the planner and network-facing commands (httpx is a core dep). Registry planning and the local catalog work offline; HF/Ollama resolution or discovery needs explicit network access. bench / measure / safety need a running backend (Ollama, vLLM, TGI, or SGLang; safety supports Ollama only). Windows / macOS / Linux.

Release scope. Chimeraforge 0.96.0 adds budget checks for dated serving quotes. It includes static passive fleet reports from 0.95.0, declaration-based Kubernetes inspection from 0.94.0, offline inventory arithmetic from 0.93.0 and the five workflows introduced in 0.92.0.

pip install "chimeraforge[mcp]==0.96.0"

Inventory arithmetic (since 0.77.0): inventory-check and async api.check_inventory check all original ordered GPU selectors and reported-free memory against a saved per-GPU batch-one baseline. Every result keeps deployment_ready: null; MIG status and UUIDs do not establish physical independence, allocation or runtime fit. See the complete inventory contract.

Secure monitoring (since 0.78.0): verified HTTPS, named-environment bearer and optional client certificates now cover standalone/saved/fleet metrics and every metadata bracket. Credentials stay runtime-only and per endpoint. See secure monitoring.

Quickstart

# Plan a registry size class on your GPU
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0

# Plan ANY model -- a Hugging Face repo or an Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434

# Split a model too big for one GPU across several (tensor parallelism)
chimeraforge plan --model Qwen/Qwen2.5-72B-Instruct --hardware "H100 80GB" --tp 4

# Shrink the KV-cache, print the cost/latency/quality trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4080 12GB" --kv-quant q8 --pareto

# Benchmark a live model and plan on the MEASURED numbers
chimeraforge plan --model qwen3:14b --measure

# Discover + rank what fits your GPU and budget
chimeraforge suggest --source ollama --hardware "RTX 4090 24GB" --budget 500

# Save and recheck an offline plan
chimeraforge plan --model-size 3b --hardware "RTX 4090 24GB" --no-network --save offline-plan.json
chimeraforge check offline-plan.json --json

Keep one Hub checkpoint through planning and export

# Metadata/config only: no model weights are downloaded by the planner
chimeraforge plan --model HuggingFaceTB/SmolLM2-135M-Instruct \
  --revision 12fd25f77366fa6b3b4b768ec3050bf629380bac \
  --hardware "RTX 4080 12GB" --platform linux --request-rate 0.01 \
  --quality-target 0 --budget 100000 --save checkpoint-plan.json --json
chimeraforge check checkpoint-plan.json --json           # offline
chimeraforge check checkpoint-plan.json --network --json # explicit Hub inspection

Branches and tags are accepted too; resolution first establishes one immutable commit, then reads that commit's config and declared file metadata. Repeat --revision MODEL=REF when planning multiple HF models. A cached moving ref is a dated producing observation, not proof of its current state.

Select a supported saved candidate before deployment export. vLLM, TGI and SGLang commands carry --revision with the resolved commit; an Ollama conversion cannot retain that pin and is refused. The receipt hashes the config bytes actually consumed and records declared weight metadata. It does not verify downloaded weight/tokenizer bytes or identify a running server. Legacy plans still load with their original identity gaps. See the Python checkpoint loop.

---

Plan with your traffic, not your guesses

chimeraforge workload --from-log requests.jsonl --out workload.json
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --workload-profile workload.json

Derives the request rate, prompt and output lengths, traffic variance and prefix-cache hit rate from a request log or a live vLLM/SGLang /metrics endpoint. The variance one matters most: plan otherwise takes it as one of four presets, and it drives the whole queueing tail.

Metric names are per-engine and explicit -- vLLM has renamed two of these between versions, and a scraper that silently falls back to a stale name reports a fabricated measurement. An unknown engine is an error, and a field the source did not expose stays absent rather than acquiring a default.

Decision briefs

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2 --report brief.md

Writes a markdown record of the decision: the recommendation, every assumption as an input rather than a finding, the alternatives table, the planner's warnings verbatim, and the exact command that regenerates it. Each number is tagged measured / extrapolated / derived / estimated / unknown in prose, not just with a symbol.

It refuses to render on a stale price snapshot and exits non-zero, rather than printing an old price in a nicer font -- a formatted document reads as more durable than a terminal line, and its reader will not re-derive the arithmetic.

MCP server -- give Claude / GPT / Cursor the same numbers

GPU sizing is exactly where assistants fail: training-cutoff hardware prices and specs, plus error-prone KV-cache/batching arithmetic done from memory. chimeraforge mcp runs a stdio MCP server so an assistant calls the real planner against measured data instead of guessing.

pip install "chimeraforge[mcp]"

Claude Code:

claude mcp add --transport stdio chimeraforge -- uvx --from "chimeraforge[mcp]" chimeraforge mcp

Claude Desktop / Cursor (add to your MCP config file):

{
  "mcpServers": {
    "chimeraforge": {
      "command": "uvx",
      "args": ["--from", "chimeraforge[mcp]", "chimeraforge", "mcp"]
    }
  }
}

The --from "chimeraforge[mcp]" pulls in the MCP SDK; uvx runs the server in a self-contained environment. If you have already pip install "chimeraforge[mcp]" into the environment your client launches, you can instead use "command": "chimeraforge", "args": ["mcp"].

For an HTTP-capable MCP client, start the native Streamable HTTP transport:

chimeraforge mcp --transport streamable-http --port 8766
# Connect the client to http://127.0.0.1:8766/mcp

HTTP binds to loopback and defaults to offline model resolution. Only the server operator can enable Hugging Face lookups/discovery with --allow-network; HTTP tool callers cannot supply local file paths, endpoint URLs, or network overrides. Ollama endpoint resolution/discovery remains a stdio capability. The SDK rejects browser Origins, foreign Hosts, and bodies above 64 KiB, including chunked uploads. Native sessions are capped at 32 and expire after 300 idle seconds. These settings and the fixed two-worker capacity are configurable through mcp --help. HTTP Hugging Face discovery is capped at 16 models per call before network work is admitted; stdio keeps its existing discovery options.

HTTP tools run off the protocol event loop. A response times out after 30 seconds; timed-out or cancelled synchronous work keeps its worker slot until it actually finishes. Further calls receive a busy error when capacity is occupied, while protocol ping/discovery stays responsive. Python threads are not forcibly stopped: server shutdown drains owned work and can wait for a slow underlying resolver. The transport uses the supported MCP 1.x SDK (>=1.30,<2), with its native Streamable HTTP session and request guards.

Exposes five tools: chimeraforge_plan (the full gate search), chimeraforge_suggest (the inverse -- rank what actually fits a given GPU), chimeraforge_compare_api (self-host vs hosted-API cost and the break-even volume), chimeraforge_resolve_model (grounds a model id in its real params/architecture), and chimeraforge_list_hardware. Every result carries the same measured / extrapolated / estimated / unknown provenance as the CLI, and the tool descriptions tell the model to prefer them over its own knowledge. chimeraforge_plan also returns a launch field -- the serve command for the recommended config -- so the assistant can answer "and how do I run it" without inventing flags. chimeraforge_compare_api prices against a dated snapshot and reports its age, so an assistant quotes a price with its capture date rather than presenting a stale figure as current.

---

Commands

plan -- predictive capacity planner

chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2.0
chimeraforge plan --model Qwen/Qwen2.5-7B-Instruct --hardware "RTX 4090 24GB"   # any HF repo
chimeraforge plan --model ollama:qwen3:14b --ollama-url http://localhost:11434  # any Ollama tag
chimeraforge plan --model Qwen/Qwen2.5-72B-Instruct --hardware "H100 80GB" --tp 4   # multi-GPU
chimeraforge plan --model-size 3b --kv-quant q4 --pareto                       # smaller KV cache, trade-off menu
chimeraforge plan --model-size 8b --hardware "RTX 4090 24GB" --launch          # + the serve command to actually run it
chimeraforge plan --model-size 3b --workload agent --safety-target 0.85 --json

• Plans any model: registry size class, HF repo (org/name), Ollama tag, or manual overrides (--params-b/--n-layers/...).

• Searches (model x quantization x backend x N-replicas x batch/GPU) through a 5-gate pipeline: VRAM -> quality -> safety (opt-in) -> latency -> budget.

• Models real serving physics: continuous batching (vLLM/TGI), prefill/decode split (TTFT + TPOT), KV-cache-bound concurrency, and variance-aware queueing (--workload).

• Fits models too big for one GPU: --tensor-parallel/--tp {N|auto} shards weights + KV across N GPUs (Megatron-style, comms-modelled); --pipeline-parallel/--pp {N|auto} splits layers across N stages instead (cheaper on slow interconnects, needs batching to fill the pipeline). Not combinable yet.

• Serves what the backend serves: GGUF quants are offered on Ollama; vLLM/TGI get FP16 and FP8 (only on GPUs with FP8 tensor cores -- Ada/Hopper/Blackwell/CDNA3). The planner no longer suggests a GGUF checkpoint on vLLM priced with a llama.cpp speedup.

• Runs where the engine runs (--platform linux|windows|wsl2|macos; default linux, or this machine's OS with --hardware auto): each engine is offered only where its own docs say it runs on that OS and GPU. Refusals happen only on a documented statement, and each one cites the doc:

  • vLLM on native Windows;
  • SGLang or TGI on a consumer Radeon card, where their ROCm docs are Instinct-only;
  • vLLM AWQ/GPTQ on AMD, or FP8 on Intel;
  • TGI AWQ on ROCm.

  Where an engine's docs are silent the plan warns that the configuration is unverified rather than refusing it, and TGI's maintenance mode is always stated.

• KV-cache quantization (--kv-quant {fp16,q8,q4}) shrinks the cache and raises max concurrency -- biggest win at long context.

• Heterogeneous fleets (--fleet "H100 80GB,A100 80GB,L4 24GB"): sizes a mix of GPU types instead of N copies of one, because a cheap GPU can win at loose SLOs and small requests while an expensive one wins at tight SLOs and long requests. On an 8B at 250 req/s that is 3x H100 + 1x L4 at $5,760/mo against 6x A100 at $6,912 -- 16.7% cheaper, because the last few req/s are cheaper on a small GPU than on another big one (plan --model-size 8b --request-rate 250 --fleet "H100 80GB,A100 80GB,L4 24GB" --budget 100000). A mix presumes a capability-aware router that no serving engine ships, so every mixed plan says so, and the reported provenance is the worst across the types used rather than the best.

• Cost realism (--duty-cycle, --gpu-price-multiplier): the headline $/1M-tok prices a saturated fleet. You also pay for provisioned headroom and for every idle hour, so the effective figure on an 8B at 2 req/s on an H100 is $2.71/1M at full duty and $9.04/1M at 30%, against $0.71 at capacity (plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --duty-cycle 0.3). Spot/reserved pricing is your input, not a bundled guess.

• Hyperscaler on-demand prices (--cloud aws|azure): the bundled datacenter prices are marketplace rates, roughly 4-5x below what AWS and Azure bill on demand. --cloud prices the fleet from a dated snapshot of each cloud's public list prices: AWS's EC2 price list for us-east-1, and the Azure Retail Prices API for eastus. Prices are Linux, on-demand and shared tenancy.

  • Whole instances: a TP/PP group must fit in one instance, and a partly-filled instance bills every GPU in it.
  • Example: the same 8B on one H100 is $1,800/mo at the marketplace rate, $4,954 on AWS (one 1-GPU p5.4xlarge), and $70,790 on Azure. Azure sells the H100 only in an 8-GPU VM, and the plan says 7 of those 8 sit idle (plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --cloud azure).
  • Sourcing: each offer's GPU model comes from the cloud's own instance or VM-series page, and its GPU count and memory are checked against the hardware DB. Different cards with similar names are excluded with a reason: Azure's H100 NVL and A100 PCIe VMs, for example. The snapshot is regenerated by scripts/build_cloud_prices.py and flagged stale after 90 days.

• Batch mode (--mode batch): for an offline backlog (a nightly summarisation job, an embedding backfill, an eval sweep) that nobody is waiting on. The latency gate and the 70% utilisation headroom are dropped. Each GPU runs the batch that maximises its throughput, the fleet is the smallest that drains --request-rate at full utilisation, and results rank by $/1M tokens rather than by monthly bill.

  • Example: an 8B at 2 req/s on an H100 goes from $0.66/1M (Ollama Q2_K, the cheapest online pick) to $0.065/1M (vLLM AWQ at batch 267), with the same one GPU at $1,800/mo (plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --mode batch). That throughput is a roofline estimate, and the output says so.
  • A latency target (--latency-slo, --ttft-slo, --tpot-slo) together with batch mode is an error, not ignored. The reported request time is service only, with no queue wait, because a backlog's wait depends on its size. --pareto trades $/1M tokens against quality.

• Self-host vs API break-even (--compare-api): prices your workload against hosted APIs and reports the monthly volume where self-hosting starts winning. Prices are a dated snapshot with a source URL per provider, flagged stale past 90 days -- never presented as a live quote -- and a frontier API is labeled as a different quality tier rather than passed off as like-for-like.

• Disaggregation advisory: prefill/decode disaggregation is not modelled. There is no closed-form prefill:decode ratio, and vLLM's own docs say it "DOES NOT improve throughput". What the planner does instead is mark candidates that sit where the published sources say it is worth considering, quote those sources, and predict nothing.

  • When it appears: the plan gates both --ttft-slo and --tpot-slo, it is serving online, it uses more than one GPU, and the engine (vLLM or SGLang) documents the feature. Every condition maps to a sentence in DistServe (OSDI 2024) or in the engine's docs at the planner's pinned tags.
  • What it reports: this plan's prefill share of modeled request service time, using the session-limited TTFT when residency is enabled, and the GPU's interconnect, since the KV handoff needs a fast link.

• Prefix caching (--prefix-cache-hit-rate): chatbot and agent traffic reuse a long system prompt, so most of the prefill is already cached. At a 4k prompt and a 90% hit rate an 8B on an H100 goes from 166ms to 17ms TTFT (plan --model-size 8b --prompt-tokens 4096 --hardware "H100 80GB" --budget 100000 --prefix-cache-hit-rate 0.9); the same query on the reference RTX 4080 is 2051ms to 205ms. Defaults to 0 and is never inferred, and the KV a shared prefix saves is deliberately not deducted -- under-sizing KV is what turns "it fits" into an OOM.

• Multi-turn session residency (--think-time SECONDS --session-turns T): a conversation's next turn hits the prefix cache only if its KV survived the user's think time. Between turns the conversation is idle (it is not decoding, and the concurrency ceiling does not count it), but its prefix still has to sit in the KV pool.

  • How it is computed: by Little's law the fleet holds rate x (T-1)/T x think time idle conversations at once. The planner computes how many of their prefixes each (replicas x batch) config's free KV can hold, and limits the stated hit rate to that share. TTFT is computed from the limited rate inside the search, so more replicas genuinely help.
  • Example: an 8B at 2 req/s with 4k prompts and 60 s between turns has 108 idle conversations. One RTX 4090's free KV holds 19 of them, so a stated 90% hit rate becomes 16%, and TTFT goes from 100ms to 837ms (plan --model-size 8b --hardware "RTX 4090 24GB" --request-rate 2 --prompt-tokens 4096 --context-length 8192 --prefix-cache-hit-rate 0.9 --think-time 60 --session-turns 10).
  • Assumptions, stated in the output: session-affinity routing, so a returning turn reaches the replica holding its prefix, and eviction that keeps idle conversations at random relative to when they return. Ollama keeps one conversation per replica slot. Off unless both flags are given.

• Reasoning models (--reasoning-tokens N): hidden thinking tokens are decoded by the GPU and held in KV even though the caller never sees them. Counting only visible output under-counts decode by the reasoning ratio -- 1000 hidden tokens take an 8B plan on an H100 from 193ms to 3664ms p95 (plan --model-size 8b --hardware "H100 80GB" --budget 100000 --reasoning-tokens 1000). Defaults to 0 and is never inferred: the ratio is a property of your workload, not the weights.

• Attention-shape aware KV: MLA (DeepSeek-V2/V3) caches a compressed latent rather than per-head K/V -- sizing it as GQA overstates DeepSeek-V3's cache by 57x -- and sliding-window models stop growing the cache past the window. A window whose layer pattern isn't declared is not applied, because under-sizing KV is what turns "it fits" into an OOM.

• Mixture-of-Experts aware: VRAM sizes on total params (every expert stays resident) while throughput and TTFT use active params (a token only reads the experts it routes to). Treating an MoE model as dense under-predicts its throughput by 3.6x on Mixtral-8x7B and ~18x on DeepSeek-V3. Active counts are derived from the model's real expert geometry and match published figures.

• Energy (--electricity-rate): monthly kWh cost, $/1M-tok (+energy), and tok/s-per-watt, reported alongside (not folded into) the budget gate.

• Operational carbon (--grid-region USA|DEU|France|... or --carbon-intensity G): gCO2e per 1M tokens and kg per month, computed as that same energy times the grid's carbon intensity. An 8B at 2 req/s on an H100 comes to 60 gCO2e per 1M tokens on the US grid and 6.5 on France's (plan --model-size 8b --request-rate 2 --hardware "H100 80GB" --budget 100000 --grid-region USA).

  • Intensity is Ember's annual-average lifecycle figure per country, via Our World in Data, pinned to an OWID commit and regenerated by scripts/build_carbon_data.py. The year is printed with every figure, and a figure more than 2 years old is flagged stale.
  • It is the SCI operational term only (O = E x I). Embodied emissions are not modelled, so it is not a full SCI score.
  • E is board power with no host or datacenter PUE, so the figure is a lower bound. An unknown TDP gives unknown carbon, never zero.

• Launch-command export (--launch): emits the vllm serve / ollama run / TGI docker run command for the winning config, with the plan's own context length, TP/PP degree, batch size, and KV dtype filled in -- the flags that are error-prone to hand-compute. It won't fabricate what it can't derive: a GGUF quant level becomes a note to serve the native-equivalent checkpoint, not an invented --quantization flag.

• Per-prediction provenance (measured / extrapolated / derived / estimated / unknown); explains the binding gate when nothing fits.

• Validated on registry data: VRAM R^2=0.968, throughput R^2=0.859, quality RMSE=0.062, latency MAPE=1.05% (beats analytical M/D/1 by 20.4x, TR133). No ML -- empirical lookup tables with first-principles interpolation (roofline for off-registry models).

check -- recheck a saved plan offline

chimeraforge plan --model-size 3b --no-network --save plan.json
chimeraforge check plan.json --json

Compare consumed inputs, local pricing, feasibility, candidate order and modeled deltas without changing the saved file. New snapshots bind full model geometry, GPU/platform and input receipts; legacy snapshots report missing bindings as unverified. Checks never enable network access from a saved permission or probe a new host for an auto plan. Exit 0 means required modeled components are unchanged, 1 means changed/expired/unverified required evidence, and 2 means malformed input. A stable modeled recommendation does not prove serving performance or identify immutable model weights. See the API contract.

bundle -- portable saved-plan handoff

Available in the published 0.61.0 CLI.

Harness files may contain private prompts or other data. Review the exact inputs before sharing a bundle. Creation copies only the original plan and its bound coefficient/quality files; original bytes, paths and fingerprint stay intact.

chimeraforge bundle create plan.json --out handoff
# Move the whole handoff directory to the receiving machine.
chimeraforge bundle verify handoff --json
chimeraforge bundle check handoff --json

Rechecks use verified input bytes offline even after producer files are removed. JSON shows producer and local source locations separately. Current tool, policy, hardware and applicable price/cloud changes remain actionable; verification alone is not a passed plan check. verify exits 0 for verified content, check exits 0 for unchanged required facts or 1 for changed, expired or required unverified facts, and malformed/unsupported bundles exit 2. Legacy plans without byte bindings and nonempty contribution dependencies are refused before writing. Integrity does not authenticate a source or prove served weights or performance. See the portable workflow.

contribute gate -- trusted signed native comparisons (since 0.71.0)

chimeraforge contribute gate --baseline before.signed.json --candidate after.signed.json --trusted-key receiver.pub --policy gate-policy.json --out decision.json --json

Compare public native facts only after exact signature/artifact verification and explicit receiver trust. Repeated flags retain the declared populations; copied, incomplete or incompatible evidence cannot qualify. api.gate_signed_contributions returns a defensive decision receipt. Exits: 0 conditional pass, 1 authentication failure or comparable regression, 2 malformed/output failure, 3 unavailable or inconclusive. Signatures do not authenticate measurement truth, hardware, weights or execution independence. See signed native gates for policy, matching rules, byte limits and the public projection's limits.

bundle prediction-* -- private prediction evidence (since 0.70.0)

Preserve a plan with its bound inputs, explicit score policy and every original benchmark receipt for offline handoff:

chimeraforge bundle prediction-create plan.json --policy score-policy.json --benchmark first.json --benchmark second.json --out private-evidence --json
chimeraforge bundle prediction-verify private-evidence --json
chimeraforge bundle prediction-score private-evidence --out scorecard.json --json

Private handoff: original benchmark and harness files can contain prompts, options, provider diagnostics or paths. Review those files before sharing. Metadata and scorecards expose digest receipts and bounded outcomes; the directory preserves the raw originals. No upload occurs. The closed bundle contract retains exact receipt order, bytes, hashes and negative/duplicate evidence under a 32 MiB transport budget including both manifests. An empty received population is valid missing evidence. Create/verify exit 0 for valid content, 2 for invalid input; scoring retains existing exits 0 within band, 1 comparable breach, 2 invalid, 3 incomplete. Integrity does not qualify GPU evidence or authenticate measurements.

study -- frozen-model workload, hardware and cost sensitivity

Available in the published 0.61.0 CLI. Compare explicit assumptions against one saved plan or portable bundle offline:

[
  {"name": "twice-the-load", "changes": {"request_rate": 2}},
  {"name": "half-duty", "changes": {"duty_cycle": 0.5}},
  {"name": "no-budget", "changes": {"budget": 0}}
]

Save that list as cases.json, then run:

chimeraforge study plan.json --cases cases.json --out study.json --json
# A portable bundle works even with the producer's input files absent.
chimeraforge study handoff --cases cases.json --json

The ordinary search uses the same bound model geometry and verified coefficient/quality bytes for every case. Current engine-support, applicable cloud prices, grid intensity, quarantine records and their time observations are captured once. The report distinguishes those current facts from producer receipts, retains infeasible cases with gate reasons, and compares configurations and estimates in native units. A changed policy identity aborts the study.

Supply 1-16 unique cases for up to 16 bound model targets. Workload, context, SLOs, quality/safety targets, budget, duty and cost assumptions may change; model and platform stay fixed. Cases without an explicit hardware alternative also hold physical hardware fixed. gpu_cost_per_hour is an operator price assumption, is refused for cloud instance pricing, and zero keeps the native unknown-price behavior. Output cannot overwrite known inputs. Exit 0 means a completed modeled study, including infeasible cases; invalid or unavailable inputs exit 2. No weights are downloaded or serving traffic generated. Integrity and modeled deltas do not authenticate inputs or qualify performance. See the Python and case contract.

Hardware alternatives (since 0.72.0). Compare full GPU registry specifications through the same CLI or Python API, without changing the saved plan:

[
  {"name": "larger-gpu", "changes": {"hardware": "RTX 4090 24GB"}},
  {"name": "ampere", "changes": {"hardware": "RTX 3090 24GB"}},
  {"name": "explicit-price", "changes": {"hardware": "H100 80GB", "gpu_cost_per_hour": 2}}
]

Save as hardware-cases.json and run chimeraforge study plan.json --cases hardware-cases.json --out hardware-study.json --json. Use one exact case-insensitive canonical name from chimeraforge plan --list-hardware; partial names, ambiguous entries and auto refuse before search. Explicit hardware cases refuse sources with cloud instance pricing or gpu_overrides, including an explicit same-name selection; scenarios without hardware preserve that saved setup. An existing unified-memory fraction stays fixed and native compatibility rules apply.

Each alternative binds the full raw/effective GPU spec from one held registry, including VRAM, bandwidth, compute, FP8, interconnect and price provenance. Base geometry stays bound to the source. Policy changes abort; physical configuration identity excludes price and source metadata. Unknown prices and infeasible cases remain explicit. Non-reference timing retains native extrapolation labels while valid model-quality evidence remains measured. These are modeled alternatives, without probing this host, running inference or attesting hardware/weights.

serving -- operator-authored serving intent

Since 0.92.0. Declare concrete settings without a predictive plan, model/corpus lookup or capacity claim. The example revision is an operator claim; the image is an explicit mutable tag, not verified runtime compatibility.

chimeraforge serving declare --model Qwen/Qwen2.5-1.5B-Instruct \
  --revision 00112233445566778899aabbccddeeff00112233 \
  --backend vllm --image vllm/vllm-openai:v0.30.0 \
  --replicas 3 --tp 2 --pp 2 --context 8192 --batch 8 \
  --out operator.serving.json --json
chimeraforge serving quote --declaration operator.serving.json \
  --cloud aws --instance p5.48xlarge --region us-east-1 --json
chimeraforge serving export --declaration operator.serving.json --format compose \
  --replica-devices 0,1,2,3 --replica-port 9001 \
  --replica-devices 4,5,6,7 --replica-port 9002 \
  --replica-devices 8,9,10,11 --replica-port 9003 \
  --out operator.serving.compose.json --json
chimeraforge serving verify --declaration operator.serving.json --format compose \
  --replica-devices 0,1,2,3 --replica-port 9001 \
  --replica-devices 4,5,6,7 --replica-port 9002 \
  --replica-devices 8,9,10,11 --replica-port 9003 \
  --config operator.serving.compose.json --json

N=3, TP=2, PP=2 means twelve logical slots. The exact 8-GPU offer quotes two whole billed instances, without assigning hosts. Launch/Compose maps describe one host namespace with twelve distinct IDs; they cannot be copied onto each quoted 8-GPU instance. --format launch returns three independent entrypoints; --format kubernetes --namespace operators --name-prefix serving produces three Deployments and three Services, without physical host/device mappings.

Declaration settings also include --dtype FP16|BF16 --kv-quant fp16|q8, --prefix-caching and vLLM-only --max-num-batched-tokens. SGLang BF16 with requested fp16 KV refuses. Quote target flags are all-or-none; absent/unknown offers retain null costs and native dated sources/age travel with known prices. Single-replica host bindings use --gpu-device/--host-port; Kubernetes also accepts repeated --node-selector key=value. Match is 0, config drift 5, invalid input 1 and native usage 2. No throughput, quality, memory feasibility, placement, engine execution or deployment readiness is implied. See all bounds, Python API and fixed argv-reference limits.

To apply a monthly cap to the dated estimate:

chimeraforge serving quote --declaration operator.serving.json \
  --cloud aws --instance p5.48xlarge --region us-east-1 \
  --max-monthly-usd 80000 --max-price-age-days 45 --json

The budget exit is 0 at or below the cap, 5 above, and 4 for stale or unknown pricing. See decimal controls and quote compatibility.

deploy -- export serving configuration

Homogeneous Compose fleets (since 0.74.0). Select an original online Linux CUDA vLLM/SGLang candidate with N>1. Repeat --replica-devices 7,3 --replica-port 9001 once per replica, supplying disjoint ordered groups of TP x PP IDs and distinct loopback host ports. The direct API accepts replica_gpu_devices=[["7", "3"], ["9", "2"], ["8", "4"]] and replica_host_ports=[9001, 9002, 9003] for a three-replica TP=2 candidate. Do not mix these options with singular device/port options. Each inference-1..N service retains the saved model/revision and per-replica batch; manually target each port. There is no router, scaler or verified physical capacity. See the complete CLI/API example and limits.

Explicit deployment devices (since 0.73.0): repeat --gpu-device once per saved TP x PP GPU and optionally set Compose --host-port. For the one-GPU vLLM selection below, append --gpu-device 7 --host-port 9001. Two-GPU selection uses, for example, --gpu-device 7 --gpu-device 3. Full GPU UUIDs are also supported. Compose emits device_ids instead of count; its list order is a requested declaration, not observed CUDA rank mapping. systemd uses ordered CUDA_VISIBLE_DEVICES selectors. The API accepts gpu_devices=["7", "3"] and host_port=9001; see the full options, API examples and refusals. Default exports retain their GPU count and ports when these options are omitted. The export admission bound is 64 GPUs per replica, with no device, topology or performance verification.

Export one saved candidate as Compose, a systemd user service, an Ollama macOS LaunchAgent, or a Modelfile. No engines are installed, started or deployed.

Documentation truncated — see the full README on GitHub.