MIC / Developer guide
22 October 2026

Model Integration Contracts

What are MICs?

MIC packages a model’s real usage code, a smaller version of the model for fast runs, and reviewed expected results. Transformers CI runs that usage and reports when behavior changes.

SmolLMOriginal model
MIC
SmolLM-slimShrinked model + same vocab/tokenizer/processor
usage.mdMarkdown with executable example
assertions.jsonexpected inputs/outputs

You or your agent can drive the whole workflow: create a MIC, run checks, investigate failures, and propose fixes.

01 / Understand

How do we create the shrunk model?

An agent can drive this entire workflow with tmic. Agent mode returns structured questions for review and upload decisions.

Create and publish a new slim model
tmic run HuggingFaceTB/SmolLM-135M --mode agent --regenerate --namespace huggingface-mic

The agent resumes the same command with answers as needed. Explore each step below.

01 / Smaller dimensions, same kinds of layers

Reduce hidden sizes, attention heads, and depth. Keep each distinct layer pattern and preserve architecture features such as RoPE and MoE. Some families need a specific recipe.

Step 1 of 5

01 / Understand

Inside usage.md

The code in usage.md is a fully valid Transformers Python script: generate text, then take one training step using the same model.

Generation

## Generate
```py runnable:generate
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "HuggingFaceTB/SmolLM-135M"
tokenizer = AutoTokenizer.from_pretrained(model_id)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "left"
model = AutoModelForCausalLM.from_pretrained(model_id)
prompts = ["The capital of France is",
           "The capital of Germany is"]
inputs = tokenizer(prompts, return_tensors="pt", padding=True)
outputs = model.generate(**inputs, max_new_tokens=4,
    do_sample=False, pad_token_id=tokenizer.eos_token_id)
new_tokens = outputs[:, inputs["input_ids"].shape[1]:]
print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))
```

Load the model and tokenizer, left-pad a batch of prompts, and generate without sampling. MIC records the generated tokens and selected logits for comparison with expected outputs.

Training

## One training step
```py runnable:generate:2
answers = [" Paris", " Berlin"]
tokenizer.padding_side = "right"
batch = tokenizer(
    [p + a for p, a in zip(prompts, answers)],
    return_tensors="pt", padding=True)
labels = batch["input_ids"].masked_fill(
    batch["attention_mask"] == 0, -100)

model.train()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
loss = model(**batch, labels=labels).loss
loss.backward()
optimizer.step()
print(f"loss: {loss.item():.4f}")
```

Continue with the same model and prompts. Right-pad the training batch and ignore padding in the labels. MIC records the loss, checks selected gradients are finite and nonzero, and checks that weights changed.

01 / Understand

Inside assertions.json

For the prompt “The capital of France is”, this slim model’s recorded output starts with “ Paris”.

Recorded SmolLM-slim expectations · excerpt
{
  "outputs": {
    "generated_tokens": [[7042, 7042, 7042, 7042]],
    "generated_text": [" Paris Paris Paris Paris"],
    "next_token_logits": [[12.8125, 3.046875, 7.59375, 5.03125]],
    "training": {
      "loss": 0.2566872537136078,
      "updated": true
    }
  }
}

Generation assertions

Token IDs and text must match exactly. Selected logits are compared with numeric tolerances. This small model repeats “Paris”; that is its recorded behavior for this prompt.

Training assertions

Compare the loss with its baseline, check finite, nonzero gradients, and verify an optimizer step changed the weights. The gradient records are omitted above.

02 / Use in CI

How MICs are used

A very fast CPU job (few seconds per model) runs the small models on PRs and on main. No GPU is needed for these checks.

Pull requests

Check the affected models

Model or processor changes select the relevant MICs. Changes to shared code or dependencies can select the whole fleet.

Main

Check the whole fleet

Pushes to main run both fleets, checking the integrated code against the same reviewed expectations.

Load the small modelUse the published, pinned MIC snapshot.
Run usage.mdExercise generation and training on CPU.
Compare outputsCheck tokens, numeric values, and training assertions.
Report resultsFind failures in the job summary and MIC dashboard.

The job is currently observational: failures are reported without blocking the PR.

03 / Investigate

A MIC failed in CI. What next?

Ask your agent to inspect the failure and reproduce it with the recorded framework revision, fleet snapshot, and runtime.

Real MIC dashboard screenshot: PR 49792 has a failing Wav2Vec2 bfloat16 CPU check. The logits maximum delta is 0.000977 over tolerance. Links open Trace, Run, Baseline, and Contract.
Actual CI failure in the MIC dashboard · Wav2Vec2, BF16 CPU · Open dashboard ↗

Fix the code

The agent can reproduce the regression, patch the code, and rerun the same MIC against the existing baseline.

OR

Review the baseline

For an intended change, the agent records candidate outputs and explains the diff. Review changed expectations before publication.

OR

Fix setup or metadata

The agent can check dependencies, platform, and dtype, repair setup or stale known-failure entries, then rerun.

03 / Investigate

Give your agent the failing case.

Share the Run or Trace link. The agent can inspect the assertion, fetch pinned references, reproduce the failure, and propose a fix with evidence.

Example case · numeric comparisonILLUSTRATIVE ROW · HISTORICAL DELTA
ModelVariant / platformLatest checkFailure
Wav2Vec2bfloat16 / CPUFailedlogits delta 0.000977 exceeds tolerance
What to inspect
Output: logits · comparison against the reviewed baseline
Record: contract + target + variant + platform + framework SHA + fleet SHA
Open: Trace · Run · Baseline · Contract

Run & Trace

Find the failing assertion or traceback, runtime versions, selected case, and reproduction command.

Baseline & Contract

Open the pinned reference and usage. Understand the expected output and the exact call producing it.

Latest & history

Compare the latest result with daily bars. Repeated failures are observations, not a count of distinct bugs.

04 / Agents on the Hub

Improve discoverability for agents through the HUB

A proposed link from the original Hub model to its MIC would give an agent a tested starting point, instead of another snippet to debug.

Today

A broken README sends the agent guessing

An example may no longer work with the installed Transformers or Torch. The agent tries package versions, patches loaders, or switches models—and still may not know whether the output is correct.

With a discoverable MIC

Run the example in its tested environment

The agent follows the model’s MIC link to executable usage.md, the exact tested versions of Transformers, Torch, tokenizers, and other dependencies, and reviewed inputs and expected outputs.

Original model pageDiscover the linked MIC.
Passing recordFind the model revision, exact versions, device, and dtype.
Agent reproduces itRun the example and verify the outputs before adapting it.

A verified starting point, less trial and error. “Working” applies to the recorded target, inputs, and environment; the original checkpoint needs its own passing record.

Explore MIC

Try it. Explore the models. Follow the results.

Give these links to your agent to get started.

Read at your own pace

Arrow keys navigate. Home / End jump to the first / last slide. Print includes every slide.