OEIS-LT: Scalable Lean Formalization Server

• OEIS-LT is a Lean-based server that formalizes OEIS content by converting DSL sequence definitions into verified Lean functions and proofs.
• It employs a multi-threaded, JSON RPC architecture to evaluate candidate functions and synthesize value theorems with industrial-scale throughput.
• The tool also supports alternative interpretations, including lookup methods, Transformer-based modeling, and statistical analysis of sequence frequency distributions.

Searching arXiv for papers directly relevant to OEIS-LT and closely related OEIS tooling. {"query":"OEIS-LT Sequencelib Lean server OEIS Transformer arXiv","max_results":10} {"query":"all:OEIS-LT OR ti:Sequencelib OR ti:IntSeqBERT","max_results":10,"sort_by":"submittedDate","sort_order":"descending"} OEIS-LT most explicitly denotes the highly scalable Lean server introduced within Sequencelib for the formalization of OEIS content, but the label is not uniform across the literature. In the strictest technical sense, it is a production-grade tool server, written in Lean 4, that translates candidate sequence definitions into Lean, checks them against OEIS values, and synthesizes verified theorems at scale. In adjacent usage, the same label or closely related phrasing has also been applied to OEIS lookup/search practice, to OEIS-focused Transformer modeling, and to the long-tail statistical profile of integer occurrences in the OEIS corpus (Moreira et al., 16 Jan 2026).

1. Nomenclature and scope

The term “OEIS-LT” is centered in recent work on formalization, but it is polysemous across OEIS-adjacent research. The most concrete and explicit use is in Sequencelib, where OEIS-LT is the tool server underlying large-scale Lean formalization. By contrast, the introductory paper on the OEIS does not name a tool called OEIS-LT; it describes the practical lookup workflow of entering initial terms on the OEIS website and, for harder cases, using Superseeker. The IntSeqBERT paper likewise does not use the term directly, but states that it would be reasonable to regard its OEIS-specific Transformer design as an “OEIS-LT” in the sense of an OEIS Transformer. A different paper uses “OEIS-LT” as shorthand for the long-tail distribution of integer frequencies in the database (Moreira et al., 16 Jan 2026, Sloane, 2021, Nakasho, 5 Mar 2026, Gauvrit et al., 2011).

Usage	Source	Core meaning
Formalization server	"Sequencelib: A Computational Platform for Formalizing the OEIS in Lean" (Moreira et al., 16 Jan 2026)	Lean 4 server with low-latency API
Lookup/search interpretation	"The OEIS: A Fingerprint File for Mathematics" (Sloane, 2021)	OEIS search plus Superseeker
OEIS Transformer interpretation	"IntSeqBERT: Learning Arithmetic Structure in OEIS via Modulo-Spectrum Embeddings" (Nakasho, 5 Mar 2026)	OEIS-focused Transformer encoder
Long-tail interpretation	"Sloane's Gap. Mathematical and Social Factors Explain the Distribution of Numbers in the OEIS" (Gauvrit et al., 2011)	Statistical long-tail of integer frequencies

In the formal methods literature, the first of these meanings is primary. OEIS-LT there is not merely a search interface or modeling framework; it is infrastructure for converting computational sequence definitions into kernel-checked mathematics.

2. Position within Sequencelib

Sequencelib is a project to formalize the mathematics contained within the OEIS using Lean. Within that project, OEIS-LT operationalizes metaprogramming in server form so that both humans and AI systems can generate Lean definitions from a Standard ML–inspired DSL, evaluate candidate functions against OEIS values, and synthesize proofs that those functions return the correct values at many indices. A formalization of a single OEIS entry is described as comprising a Lean function $f : \mathbb{N} \to \mathbb{N}$ or $f : \mathbb{N} \to \mathbb{Z}$, value theorems $f(i)=b$ for known indices, and equivalence theorems $\forall n, f(n)=g(n)$ when multiple definitions represent the same sequence (Moreira et al., 16 Jan 2026).

This framing turns OEIS entries into formally manipulable objects. The system attaches OEIS metadata directly to Lean definitions via an attribute such as @[OEIS := "A000079", offset := 0, maxIndex := 10, derive := true], after which Sequencelib can query the metadata and derive value theorems automatically. The paper presents this as the core answer to the scale problem in OEIS formalization: parsing, typechecking, evaluation, and proof synthesis are exposed through one programmable endpoint rather than through manual theorem-proving workflows (Moreira et al., 16 Jan 2026).

The server also mediates between synthesis artifacts and formal mathematics. The computational pipeline builds on ML-generated DSL functions for 27,987 OEIS entries, and OEIS-LT provides the translation, evaluation, and proof-generation steps needed to convert numerical agreement into Lean-certified artifacts. This is the decisive methodological shift from informal sequence matching to kernel-checked formalization.

3. Architecture, execution model, and API

OEIS-LT is implemented in Lean as a lightweight, multi-threaded process serving JSON RPC-like messages over TCP or Unix domain sockets. Each request is parsed, elaborated by Lean’s kernel, executed either by evaluation or tactic-based proof, and returned as structured JSON. Commands are organized into core and extension modules, and the server supports a plugin architecture in which a command is supplied as a Lean function of type $\alpha \to \mathrm{OEISM}\ \beta$, with OEISM bundling error handling, IO lifting, and logging (Moreira et al., 16 Jan 2026).

Command	Function	Notes
gen	Translate DSL definition to Lean	Standard ML–like DSL
compile	Typecheck or compile Lean source	Lean kernel elaboration
eval	Evaluate a function on indices and compare values	Can test against OEIS and b-files
prove	Synthesize value theorems $f(i)=b$	b may be omitted
ready	Status probe	Health check

Multiple clients can connect simultaneously, with each client receiving its own execution thread. For evaluation, OEIS-LT builds Lean syntax, elaborates it to Expr, and applies evalExpr when the term is computable. For proof generation, it invokes Sequencelib.Meta.deriveTheorem and deriveTheoremForIndex, which call the curated oeis_tactic. Proof synthesis runs inside withoutModifyingEnv do blocks to avoid environment growth and to keep memory stable across thousands of proofs (Moreira et al., 16 Jan 2026).

The server’s design is explicitly operational rather than merely declarative. It is intended for high-throughput use by downstream automation, including a Python SDK and a high-performance instance hosted at the Texas Advanced Computing Center. This makes OEIS-LT a systems component as much as a metamathematical one.

4. Transpilation, autoformalization pipeline, and quantitative results

The pipeline begins from Gauthier–Urban ML-generated DSL programs. The supported subset includes arithmetic operators $+$, $-$, $*$, div, control constructs loop and compr, variables x, y, and constants $0,1,2$. OEIS-LT parses this DSL using the custom Lean syntax category oeis_synthesis, elaborates it to Lean via DSLToLean or DSLToLeanSimplified, and applies algebraic simplifications and constant folding before verification (Moreira et al., 16 Jan 2026).

Evaluation checks candidate Lean functions against the main OEIS value list; if a b-file exists, the server samples 100 uniformly chosen b-file entries. Candidates with any disagreement are discarded. For passing candidates, the prove stage attempts to derive as many value theorems as feasible without timeouts, first up to 100, then 50, then 25. Successful definitions and theorems are written out as Sequencelib files (Moreira et al., 16 Jan 2026).

The reported outcomes are large-scale. The pipeline formalized 25,457 sequences into Lean out of 27,987 ML-generated candidates, proved more than 1.6 million value equalities, achieved the maximum theorem budget for 24,546 sequences, and generated at least some theorems for 908 sequences. The skipped cases were 2,462 due to value disagreement, 3 due to timeout, and 65 due to negative offsets (Moreira et al., 16 Jan 2026).

Load testing on an Ubuntu VM with 16 cores and 32 GB RAM reported zero failures across 30-second runs from 8 to 300 threads. Median latencies were 10–21 ms for compile, 12–28 ms for eval, and 15–48 ms for prove, while throughput reached approximately 410 req/s, 420 req/s, and 490 req/s respectively at 300 threads. Memory stayed in the approximate 5–7 GB range, and CPU usage scaled with thread count (Moreira et al., 16 Jan 2026).

These figures establish OEIS-LT as a verification service capable of industrial-scale throughput, not merely an experimental theorem-proving interface.

5. Lookup and learned-model interpretations

Outside formalization, “OEIS-LT” has been used or inferred in ways that emphasize sequence identification rather than proof production. The introductory OEIS article describes the OEIS as a “fingerprint file for mathematics”: one enters initial terms in the search box, obtains candidate A-numbers, and verifies identity via offset, predicted subsequent terms, graph, formulas, references, links, programs, and b-files. If no match appears, the recommended escalation path is to transform the sequence or invoke Superseeker by email using a line of the form lookup 0 1 3 7 11 15 23 35 43 47 with no commas (Sloane, 2021).

That lookup interpretation is operationally distinct from the Lean server. It is centered on recognition and contextualization of integer data rather than on certified formalization. It also covers triangles and arrays, which must be linearized by rows or antidiagonals before search; the paper uses Pascal’s triangle A007318 and the Nim-sum table A003987 as canonical examples. In that sense, a search-oriented “OEIS-LT” is a workflow over the public OEIS site rather than a standalone software artifact (Sloane, 2021).

A further extrapolation appears in IntSeqBERT. That work presents a dual-stream Transformer encoder for masked integer-sequence modeling on 274,705 OEIS sequences, with each sequence element represented by a continuous log-scale magnitude embedding and a modulo spectrum of sin/cos residue embeddings for moduli $f : \mathbb{N} \to \mathbb{Z}$0 through $f : \mathbb{N} \to \mathbb{Z}$1. The streams are fused by FiLM, trained with magnitude, sign, and modulo heads, and coupled to a probabilistic CRT-based solver. At the Large scale of 91.5M parameters, the model reports 95.85% magnitude accuracy, 50.38% Mean Modulo Accuracy, and a next-term Top-1 solver accuracy of 19.09% versus 2.59% for a tokenized Transformer baseline (Nakasho, 5 Mar 2026).

The IntSeqBERT paper explicitly states that it does not use the term “OEIS-LT,” but that it would be reasonable to refer to its approach as an OEIS Transformer. This suggests a second technical lineage for the label: not theorem serving, but arithmetic representation learning over OEIS data.

6. Statistical interpretations, limitations, and future directions

A different strand of work uses “OEIS-LT” to denote the long-tail structure of integer frequencies in the OEIS. In that analysis, the frequency $f : \mathbb{N} \to \mathbb{Z}$2 counts how many OEIS sequences contain the integer $f : \mathbb{N} \to \mathbb{Z}$3 among their listed terms. The empirical fit on $f : \mathbb{N} \to \mathbb{Z}$4 is

$f : \mathbb{N} \to \mathbb{Z}$5

with $f : \mathbb{N} \to \mathbb{Z}$6, indicating a rapidly decaying long tail. Superimposed on this is “Sloane’s Gap,” a visible separation between two clouds in the scatter plot, interpreted as the result of social and editorial over-representation of primes, squares, highly factorable numbers, repdigits, and numbers of the form $f : \mathbb{N} \to \mathbb{Z}$7 (Gauvrit et al., 2011).

This meaning is conceptually far from the Lean server, but it bears on how OEIS-derived systems are interpreted. Search, recommendation, autoformalization, and machine learning over OEIS all operate over a corpus whose content is not statistically neutral. A plausible implication is that infrastructure labeled “OEIS-LT,” regardless of technical form, inherits both the mathematical regularities and the editorial biases of the underlying encyclopedia.

Within the server-centered sense, the limitations are concrete. The current DSL subset is narrow; OEIS-LT today focuses on value equalities and equivalences rather than automated derivation of recurrences, closed forms, generating functions, inequalities, monotonicity, or congruences; noncomputable definitions remain difficult; negative offsets caused 65 skips; and cross-request caching is minimal. The stated future work includes richer theorem classes, broader handling of noncomputable sequences, and further AI pipelines to formalize tens of thousands more sequences (Moreira et al., 16 Jan 2026).

Within the learned-model sense, the limitations are also explicit: the modulus range is fixed to $f : \mathbb{N} \to \mathbb{Z}$8–$f : \mathbb{N} \to \mathbb{Z}$9, solver accuracy collapses for huge or astronomical values, CRT mode is brittle to residue errors, the dataset is OEIS-biased, and the experiments are restricted to single-GPU, single-seed runs. Proposed extensions include approximate CRT, larger models, family-aware splits, synthesis-based augmentation, and downstream applications such as conjecture generation (Nakasho, 5 Mar 2026).

Taken together, these usages show that OEIS-LT is not a single settled object across the literature. It is, most rigorously, the Lean-based server at the center of Sequencelib’s large-scale formalization pipeline; but it also names, or is plausibly extended to name, three neighboring ideas: OEIS lookup as fingerprint-based identification, OEIS-specific Transformer modeling of integer sequences, and the long-tail statistical geometry of OEIS content itself.