Python¶
The local engine¶
| Argument | Default | Does |
|---|---|---|
model |
Mythologic/MIMIR-1 |
a Hugging Face Hub id or a path to a local release directory |
revision |
the revision this package version pins | a specific Hub commit or tag |
device |
auto |
cpu, cuda, or CUDA when a GPU is visible to torch |
variant |
the variant listed for the device | fp32 |
policy |
the release policy | path to a custom policy JSON from mimir calibrate |
cache_dir |
the Hub cache | where the model files are stored |
offline |
False |
load only from the local cache, with no network access |
allow_unsigned |
False |
load a local release directory that has no Sigstore signature |
mimir.Mimir requires mimir-decisions[local], which installs Torch with CUDA support: the same install serves the CPU and the GPU. mimir doctor reports the Torch version, whether CUDA is visible, and the device in use.
device="auto" serves CUDA when torch sees a GPU, else the CPU. The same fp32 weights and release policy serve both; on hardware the certificate does not list, the first load runs the release's equivalence set once and caches the pass.
Before loading the weights, from_pretrained checks the pinned revision, verifies the manifest's Sigstore signature against the release identity of abderahmane-ai/mimir, and verifies each file's SHA-256 against the manifest. Nothing is read until every check passes.
For offline use, fetch once with mimir download and then load with offline=True (or set HF_HUB_OFFLINE=1).
model.info() reports the model id, revision, variant, runtime fingerprint, certified risk levels, and input limits. model.count_tokens(context, spec) sizes a request before sending it.
The engine is safe to share across threads.
The HTTP client¶
from mimir import MimirClient
remote = MimirClient("https://mimir.internal", api_key="...")
remote.choose(
"Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan.",
"Which department should handle this request?",
options={
"billing": "Billing: invoices, payments, refunds",
"technical": "Technical: bugs, outages, system errors",
"sales": "Sales: pricing, new contracts",
"other": "Other: everything else",
},
)
MimirClient implements the same interface as Mimir — the same methods, the same signatures — so code, decision tools, and framework adapters accept either without modification. It requires only the base install.
api_key defaults to the MIMIR_API_KEY environment variable. Connection errors, timeouts, and 429, 502, 503, 504, and 529 responses are retried with exponential backoff that honours Retry-After. Any other error response raises a ServerResponseError subclass that keeps the HTTP status and the response body.
Use MimirClient as a context manager to ensure the underlying connection pool is released:
with MimirClient("https://mimir.internal") as remote:
result = remote.choose(
"Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan.",
"Which department should handle this request?",
options={
"billing": "Billing: invoices, payments, refunds",
"technical": "Technical: bugs, outages, system errors",
"sales": "Sales: pricing, new contracts",
"other": "Other: everything else",
},
)
Async and batches¶
Every method has an async counterpart: adecide, adecide_many, achoose, ayes_no, averify, arank, arate, aestimate.
decide_many and adecide_many take a list of (context, spec) pairs and batch them by token length. On the local engine, requests that share the same mode, floor, risk level, and alpha are grouped into a single engine call.
Decision tools¶
from mimir import Choice
route_ticket = model.tool(
"route_ticket",
Choice(
"Which department should handle this request?",
{
"billing": "Billing: invoices, payments, refunds",
"technical": "Technical: bugs, outages, system errors",
"sales": "Sales: pricing, new contracts",
"other": "Other: everything else",
},
),
description="Route a support ticket to the team that owns it.",
)
route_ticket(
"Hi, we were billed twice for March. Please refund the duplicate today or we will cancel our plan."
)
route_ticket.input_schema, route_ticket.output_schema
A decision tool binds a spec to a name so the caller supplies only the context. The HTTP server, the MCP server, and every framework adapter expose decision tools. input_schema and output_schema are JSON Schema objects describing the tool's expected input and output.
Types without the engine¶
from mimir import Choice, Context, ChoiceResult loads only the data models, which depend on Pydantic alone. A project that constructs requests or reads results without running the model can depend on the base install and never touch Torch.