SNIP: Small N-gram Identifier for Pastes

Problem

Pastebin sites, editors, and developer tools often need a useful syntax suggestion immediately after text is pasted. SNIP is designed for that narrow workflow: fast browser-local inference without sending pasted content to a server. It predicts a likely syntax or text label for pasted text, snippets, logs, configuration files, and text-like source files. Binary file detection, MIME sniffing, and full file-type forensics are outside the current scope.

Method

The release model is a multiclass linear classifier trained with passive-aggressive updates. Input text is sampled, converted to hashed character n-gram features, L2-normalized, scored by sparse per-label weights, and ranked with a softmax transform. The final package exposes both the accepted label and the raw top prediction so applications can decide how much ambiguity to show to users.

Inputs up to 16 KiB are classified whole. Longer inputs are represented by windows from the start, middle, and end, which bounds runtime for large pastes while preserving common file-level signals.

Data

The dataset was built iteratively from generated structured text, curated programming examples, realistic project fragments, targeted hard-neighbor cases, and plain-text fallback examples. Candidate splits were checked for exact and normalized duplicate overlap.

For programming languages, examples were written as complete files or realistic project fragments: CLIs, web handlers, tests, services, configuration loaders, migrations, and framework code. For structured formats such as JSON, CSV, and logs, examples varied shape, length, field names, nesting, and value distributions rather than repeating one template.

The final training data emphasizes realistic short snippets, source-grouped splits, and explicit hard cases for ambiguous neighboring labels such as HTML/XML, INI/TOML, JSON/log, Markdown/plain text, and CSV/plain text.

Training Loop

A major objective of training the n-gram was testing how much of training a model can be performed semi-autonomously by an LLM Agent. n-grams are incredibly fast to train, and afforded the model many opportunities to run experiences and build up a training dataset over time that specifically targeted failures in the trained models. A key part of getting that loop to work was ensuring the data stayed representative of a real-world text distribution while keeping the model from over-fitting to the generated dataset. The Agent was instructed to keep notes, an experiments log, and a data quality log. It did require a bit of nudging along the way, such as prompting it to manually inspect some of the generated data and note the quality issues (For example early C examples were almost all duplicates of 4-5 lines of a main() printing a few words).

Each round started with a candidate model trained on the current corpus. The agent evaluated it against the normal validation/test split, targeted hard cases for confused labels and the held-out evaluation suites. When the model failed, a subagent was used to describe the failures as broader missing shape: short prose-heavy Markdown, TOML that looks like INI, JSON-looking application logs, small diffs, short language snippets without imports, and so on.

Those descriptions were then used to create new train-only examples. For programming languages, the examples were usually generated as realistic files or fragments rather than templates. For structured formats, the generation could be more programmatic, but still had to vary field names, lengths, nesting, and punctuation. Before a new training split was used, the added rows were checked against the rest of the corpus for exact or near-duplicate overlap.

A separate LLM subagent was used to create new held-out evaluation suites between rounds. This was important to help ensure the overall quality of the train dataset. We want the generated examples to be different enough to keep the model robust. The held-out suites were generated from label-level requirements and broad scenario prompts, then locked before the next candidate was evaluated. Once a held-out suite exposed an error category and influenced the next data pass, it was no longer treated as a final benchmark. It became a regression suite.

The loop looked like this:

1. train a candidate on the current corpus
2. evaluate against validation, test, hard cases, and held-out evaluation suites
3. inspect failures as categories and patterns
4. generate train-only coverage for those categories
5. check duplicate and near-duplicate overlap
6. train the next candidate
7. create fresh held-out coverage when a release-quality claim is needed

This process let the dataset grow in the directions the n-gram actually needed while keeping a clean separation between training data and held-out evaluation suites.

Results

SNIP scores every label and selects the highest-scoring label. The margin shows how far that winner is ahead of the runner-up.

Runtime and Size

The runtime is authored in TypeScript and published as plain JavaScript with generated declaration files. It has no runtime dependencies. The raw model JSON is 626,595 bytes, and the gzip-compressed model is 204,593 bytes.

Limitations

• Very short snippets may lack enough evidence for a specific syntax label.
• TypeScript and JavaScript can be close when a snippet has no type syntax.
• JSON-lines application logs can be close to JSON.
• Markdown/plain-text separation can be weak on very short prose-like Markdown.
• Large JSON manifests with embedded language-labeled snippets can look like source code.

Labels

Install and API

The package exports classifyText and classifyTextAsync, and embeds the SNIP model directly in the runtime. There is no model fetch step for browser applications.

Results include label, predicted_label, confidence, margin, and the top five alternatives. SNIP scores every label and returns the highest-scoring label as the prediction. margin is the gap between the winning label and the runner-up.