LIM

Overview #

LIM reads the last few lines of a conversation and says whether the next reply is fine to give, needs a nudge, or should stop, just as ELIM does. You give it the recent turns as plain text; it gives back the same labels and the same suggested lines. It is the standard model of the LIM series; ELIM is the enhanced one and LIM Nano the smallest, and a request picks any of the three by name.

LIM (Large Intention Model) is a conversation-intention classifier: a small model a host application runs before its responder to decide whether to allow, steer or abort a reply. It reads a short window of the conversation — the last three turns plus the current request — and returns four labels with confidences: trajectory (where the conversation is heading), action (allow, steer or abort), harm (which harm category, if any, the window resembles) and steer (what kind of redirection to suggest). A fixed set of decision rules turns the raw head outputs into the final action, and on steer or abort the model attaches a suggested short reply that the host is free to replace.

LIM is the standard model of the intention family and the one the series is named after. It shares its input contract, its four label vocabularies, its decision rules and its output shape with ELIM, the family default on the hosted route, and with LIM Nano; the three differ only in the network in the middle. LIM hashes character and word n-grams into one shared feature bag, averages the resulting 512-wide embeddings, and passes them through two plain GELU layers. ELIM keeps separate character and word bags and adds a deeper head with residual connections. ELIM and LIM load from the same weights directory, LIM Nano from its own bundle, and a host selects between them with a request field rather than a change of code.

Because the two models agree on everything except the backbone, switching from ELIM to LIM changes the model’s reading of a window, not the host’s policy. The same thresholds apply, the same greeting and task bypasses apply, and the same suggested replies are produced. LIM also serves as the fallback: when the ELIM weights are absent from the directory, the runtime scores every window with LIM and reports which model ran in the model field of the result.

Intended use #

• A pre-response intention check in a chat-style host, run on every user turn before the responder is called.
• Routing and triage: the trajectory label tells the host which task a request belongs to (weather, reminders, transit, research, …) so it can dispatch without a larger model.
• A second opinion beside ELIM when a host wants to compare two readings of the same window, or an A/B configuration selected per request.
• Hosts that want the standard LIM reading, or a smaller resident footprint than ELIM (35.8 MB of weights against 52.8 MB) with the same vocabulary.

Out of scope #

• Writing or rewriting the reply — LIM classifies; the responder writes.
• Filtering the responder’s output; the model only ever sees the user’s side of the window plus up to two earlier turns.
• Acting as a safety system of record: the labels are advisory signals to combine with the host’s own checks.
• Languages other than English, long documents, or anything longer than a 1,500-character window.

Choose LIM when #

• You want the standard LIM reading: the full intention vocabulary at 512 width, in a smaller resident footprint than ELIM.
• You are already running ELIM and want an alternate reading of the same window for comparison, canarying or fallback.
• Choose LIM Nano, the original 256-wide LIM (4,338,995 parameters, 17.4 MB), when the resident footprint must be smallest of all: it has the same contract, the same label catalogues and the same decision rules, at half the embedding width, and is selected with model: "lim-nano".
• Otherwise choose ELIM, the family default: its separate character and word bags and deeper residual head were designed to be more tolerant of misspellings and very short requests. Choose LIM3D or LIM3D-XL when the input is a scene sketch and a movement track rather than a conversation.

Specification #

Try it #

You send

A short chat in which someone says they have chest pain and cannot breathe.

You get back

A steer decision with the harm class medical and a hint to point the person to emergency services.

The same exchange as the API sees it:

U: i've been dizzy since lunch
A: sorry to hear that. is it getting better or worse?
U: chest pain and i can't breathe

{
  "trajectory": "medical_emergency",
  "action": "steer",
  "harm": "medical",
  "steer": "medical_911",
  "pTrajectory": 1,
  "pAction": 1,
  "pHarm": 1,
  "rule": "traj-steer≥0.58",
  "model": "lim",
  "message": "…"
}

Limits & safety #

LIM does not see the conversation; it reads a window of at most 1,500 characters built from the last three turns, and only the last 360 characters of that window contribute character-level features. It does not see the responder’s reply, the user’s identity, any earlier history, or any attachment.

• It does not write, rewrite or filter replies. message is a suggestion the host may discard.
• It does not understand languages other than English, and its templates use casual, short phrasings; formal or long-form requests are out of distribution.
• It does not carry word order beyond bigrams and character 4-grams, so negation and long-range structure (“I would never …”) can be misread.
• It does not produce calibrated confidences; a 1.00 on a template-like request and a 1.00 on an unfamiliar one mean different things.
• It does not distinguish fiction, research or quotation from a request for operational help; the abort message asks the caller to keep such requests non-operational for that reason.
• It is a little more sensitive to spelling and phrasing than ELIM by design, because it hashes one shared bag through a shallower head. This is a design rationale, not a measured gap.

Related models #

Latest versions #