Spark-to-Paper is an end-to-end research paper generation system that operates in 13 combined capabilities within existing programming assistants, without the need for separately deployed smart body platforms or external editing services. Starting with a research idea, the system automatically completes document retrieval, experimental design, experimental execution, paper writing, proof-driven conclusion modification, editable paper text generation, up to the output of a complete LaTeX project that can be compiled directly.
In eight controlled study subjects, Spark-to-Paper citations were 99.5% efficient, graphic elements editable at 96.4%; false conclusions from 36 injections increased the detection rate from 14% generated once to 92%, and counter-review accuracy at 74%. On average, each paper uses 11.9M tokens, costs $8.1, and takes 3.2 hours.
The paper:
Hugging Face：
Currently, the paper introducing the system has been marked by Hugging Face Papers as the first of the day.
The pain points of AI research
The development of CodingAgent has reshaped traditional scientific research processes to become a new paradigm for AI-assisted scientific research: Intelligent bodies are responsible for the entire process of research task planning, programming and task execution, significantly improving scientific research efficiency.
However, due to the complexity of the research process itself and the limitations of current large-scale modeling capabilities, AI research still faces two major pain points, limiting its practical application.
The first is the fragmentation of tools: literature reading, assumptions proposing, code writing, experimental trial errors, parametric optimization, etc. are scattered across multiple platforms, each linking product is difficult to attach, and even with the use of a programming assistant (Claude Code / Codex), there is a lack of a set of end-to-end processes that are "complete from idea to paper".
The second is the scientific illusion: large models have inherent hallucinatory problems, face complex, long-chain research tasks, are prone to errors such as literature citations, experimental figures, causal inferences, and so on. References cannot be checked, figures are not available, experimental results "pretend nothing happened" when they contradict conclusions, and seriously undermine the viability and rigor of scientific work.
Spark-to-Paper：
From the idea to the paper to the end of the scientific workflow
Spark-to-Paper is no longer a standalone smart body platform, but instead directly replicates the programming assistant's existing ability to read documents, execute code, search for information and call tools, breaking down the research process into 13 unifiable skills. Each skill specifies only task objectives, constraints, tools and delivery standards, specifically executed by the programming assistant according to the current project status; a lightweight streamline is responsible for assigning task sequences. All skills share the same project directory, through documented product collaboration, the first step of input is the next step of input, documentation, research blueprints, code, experimental results, images and modification records.
Starting with a short idea, the system expands it into structured research proposals, then completes planning, citation, writing, revising, reviewing, drawing, and assembly, ultimately producing a complete LaTeX project containing manuscripts, reference documents, charts, and template configurations that can be compiled directly.
Experimental links are also done automatically by the system: in the planning phase, the data set, baseline, indicator, decomposition and result table structure are pre-determined in advance (numerical values are left empty) and the process is pre-registered at a light level; after writing, the system retracts missing evidence from the paper's claims, automatically runs the smallest experimental set when the code and data are available, records logs, indicator documents, tables and graphs, and returns the correct text, redraw results graphs, while linking to the summary, quotes, results and conclusions.
The document diagram follows two routes: the result diagram directly reads the test data; the vector PDF is generated and exported by the drawing program; the method diagram and the drawing diagram first produce a visual drawing using the image model; the programming assistant then recreates it as an editable web file and alters the calibration, ultimately exporting the vector PDF.
Spark-to-Paper overall execution process
Spark-to-Paper core technology
Modular flows based on skills
13 skills are organized by input routing with eight stages. The input judges the starting point and selects the completeness model of the result. The input judges the starting point and selects the completeness model of the result. The numbers must be empty when the uncertain results are entered into the proposal mode; when the experimental data are entered into the data perception mode, the quantitative conclusions must be supported by the results. The planning, citation, writing, revision, review, drawing, assembly constitute the process of generating the core paper; the experiments are executed on demand, triggered, and the test evidence is rewritten.
Pre-registered experimental design and evidence-driven revisions
Experimental planning and experimental reporting are strictly separated: prior to the results of observations, the planning phase is fixed data sets, baselines, indicators, meltdowns, and result table structures; the experimental phase requires minimum evidence sets, costly computations, or external data acquisition must be backed up by specific claims and resource availability. After the experiment is complete, the system, based on a proof-of-concept review manuscript, classifies the arguments as supported, partially supported, unsupported, refuted, or further confirmed, and preserves, weakens, removes, transfers limitations, or complements the experiment accordingly; negative, ineffective, or insignificant results are preserved rather than tainted, and summaries, citations, results, and conclusions are updated to ensure that the entire text is consistent with the final results.
Complete checks, long-term self-sacrifice and failure
Determination Gate identifies the verifiable properties individually: blueprint structure, reference consistency, notation unification, graph file readiness, successful LaTeX compilation, and rules such as "unobserved results must be left blank" in the proposal mode, which are executed by the program rather than the model.
Semantic-level problems are handled by two levels of model self-consciousness: self-examination of the local check point drift and backward consistency after each editing; counter-examination of the entire paper from the perspective of theoretical correctness, experimental design and systemic effectiveness; multiple independent reviews of the entire paper; each review opinion must cite specific paragraphs and verify from three directions whether the question is real, whether it has been answered elsewhere, beyond the scope of the claims of the paper; irrefutable opinions only enter the revision, and the review continues until no new questions are created within a round.
Against the self-refuting cycle of "repeated experiments denying the same research direction", the system set the experiment as a seven-round cycle. When the upper limit is still unable to support the core goal, it ends the cycle and generates failure reports, records the original ideas, methods tried, test results and reasons for insufficient evidence, and then restarts from new ideas. The failure trajectory is retained as a research product, but not packaged into a successful paper.
Integrity check, self-examination and self-refutation cycles
Can be edited to generate charts
The paper graph follows two routes: the experimental result graph reads the experimental output; the native vector PDF is generated by the drawing program, and the numerical and experimental results are strictly bound; the method graph and the explanatory graph are first generated by the image model as a visual sketch, then by the drawing as a visual specification; the text, shape, and layout are reconstructed by the Coding Agent in the form of HTML to be generated, and the vector PDF is exported by rendering against the algorithm, which returns to the graph when it is unreliable. The generated model is responsible for the visual design, the experimental results are entirely determined by the data, and the final product remains editable.
The resulting graph uses two different editable generating paths
Applied practices and evaluation results
Controlled evaluation: Comparison with human pre-printed books and existing scientifically researched intelligences
In eight controlled study subjects, Spark-to-Paper citations were 99.5% more efficient than 97.8% of pre-printed human citations, 93% of AI Scientist, 91% of AI Scientist-v2, 96% of Agent Laboratory and 81% of single-generation baselines. Graphic elements were 96.4% editable, compared to only 58% of human pre-printed copies, and 0% of editable graphic elements in products published by AI Scientist and Agent Laboratory.
In the anti-hallucination melting assessment, false conclusions about 36 fixed injections were detected only 14% of the time, increased to 69% after inclusion, superimposed self-censorship to 81% and complete stacking to 92%; contrasting review accuracy to 74%, meaning that the majority of the reviews responded to real verifiable questions.
In terms of efficiency, the entire system uses an average of 11.9M tokens, costing $8.1, and takes 3.2 hours; the single-generation baseline is 0.11M tokens, $0.66, and 16 minutes, but citation efficiency is only 81%. Spark-to-Paper uses more reasoning and checking costs in exchange for more reliable citations, traceable experimental results, and editable paper products.
The Spark-to-Paper page on Hugging Face Papers was marked the first of the day.
Open and co-built
We welcome every developer, researcher and expert in the field to participate in the co-creation, submit feedback or contribute content to the code repository, and we will continue to iteratively optimize.
GitHub：
Website of the project:
The paper:
Hugging Face：