Page-Level Reuse:
Pay Once for Each Page
Lingxiao Yin & CSPaper
October 2026
TL;DR
- Every paper on CSPaper goes through OCR first, and the OCR service charges per page. Many papers are uploaded several times with only a few pages changed.
- Page-level reuse identifies each page by its content, keeps the OCR result of every page it processes, and sends only new pages to OCR, all in one request.
- In a test on a non-public subset of CSPaper's production traffic over about 38 days, 25.71% of page lookups came from the cache. That is at least 24,035 OCR pages we did not pay for, and 30.55% of reviews reused at least one page.
- 594 of those reviews reused only some of their pages. A cache keyed on the whole file would have missed every one of them.
- The work comes from Lingxiao Yin's MSc thesis at DTU, carried out with the CSPaper team. The full thesis is on CSPaper OpenPrint [5].
Every paper that comes into CSPaper goes through OCR first [6]. This step turns the PDF into page-level JSON, which the system then joins into Markdown for our review models. The OCR service charges for each page it reads.
Many papers are sent to us several times. Authors may fix a typo, update a table or add an appendix, and then submit again. Before this work, each new submission went to OCR in full, so we paid again for pages we had already read. Page-level reuse stops this.
Why page-level reuse matters now
Generative AI makes it fast to write and revise a paper. In one controlled study, access to a language model cut the time for professional writing tasks by 40% [1]. Faster revision means more versions of the same paper, and each version may pass through our pipeline again.
The cost to process a paper does not fall at the same rate. Before CSPaper can review a PDF, the system must validate it, convert it and send it to models and external services. Each step uses time and compute, and the OCR step also has a direct price per page. When a page has not changed, a second OCR pass gives no new information.
A simple cache does not solve this:
Only helps inside one review record. A re-upload creates a new record, so nothing is reused.
Finds exact re-uploads. But one edited page gives a new file hash, and the saved results for all other pages become unreachable.
For our pipeline, the page is the right unit. The OCR service charges per page, it returns its results page by page, and most revisions touch only some of the pages.
of 93,497 distinct page lookups were served from the cache
in about 38 days, a lower bound
1,798 of 5,885 reviews used at least one saved page
All numbers come from a non-public subset of CSPaper's production traffic over about 38 days, not from platform-wide traffic.
Two questions before a saved result is used
For each page of a new PDF, the system asks two questions.
1. Have we read this exact page before, with the same settings?
Two PDFs can show the same page with different bytes inside. So the system first cleans up an image of the page in a fixed way and computes a SHA-256 hash of the result. It also compares two settings: the version of the clean-up step and the OCR model. The system uses a saved result only when all three parts agree.
2. Can the saved result go back to the correct place?
A document is a list of pages in order. The same page content can appear many times, in one document or in different uploads. The system must put each result at the correct position and give it the matching page number and image names. It does this in three parts:
- Every page keeps its index and its hash. When the system renders a page, it stores the page's position in the uploaded PDF next to its hash. The original PDF stays the reference for page order.
- Results are collected in one map, keyed by hash. During a request, a dictionary called
ocr_by_hashholds one OCR result per hash. Results from the cache go in first. New OCR results are mapped back by position: the j-th result belongs to the j-th page of the temporary PDF and is stored under that page's hash. - Each position gets its own copy. The system walks through the uploaded pages in their original order and reads the result for each hash. It makes a deep copy of that result and writes the details of the current position into it. Every image name in the copy gets the prefix of its page, for example
page-3-img-0.jpeg.
From PDF to Markdown: how it works
The work runs in six steps.
PyMuPDF draws every page as a PNG image at twice its normal size, with no transparency. The larger image keeps small symbols and thin lines. We use this image only to make the page key. When a page needs OCR, the service gets the original page from the PDF.
The image goes through a fixed recipe: grayscale, local contrast correction (CLAHE, clip limit 2.0, 8×8 tiles), a light 3×3 blur, and a cut from 256 gray levels to 64. The result is saved again as PNG. This removes small pixel differences that come from rendering, compression or uneven contrast.
The key has three parts: the SHA-256 hash of the cleaned PNG, RENDER_VERSION (the version number of the clean-up recipe), and the OCR model name.
Duplicate keys inside one file are removed first. Then one MongoDB query checks all the remaining keys. A match counts as a hit only if the saved OCR result also loads from Blob Storage. If it does not load, the page is treated as new.
The first copy of each new page goes into a temporary PDF, and that PDF goes to the OCR service in a single request. One request per page could cause a burst of calls and hit the provider's rate limits. Each new result is written to Blob Storage first and its index record second, so the database never points to a missing result.
Each result goes to its page as described above, and the pages are joined in their original order. The Markdown has the same format as before, so the rest of the review pipeline does not change.
In a six-page paper, pages 2 and 5 are new and the other four pages are in the cache. The temporary PDF holds two pages. The first OCR result goes to page 2 and the second to page 5. If pages 2 and 5 were the same page, only page 2 would be sent, and its result would fill both positions.
A missed match costs one extra OCR page. A false match can put a wrong digit or a flipped sign into a review, and nobody may notice. So we accept only exact key matches. Perceptual image hashes allow near matches, but they may miss small changes [2], and they can be manipulated in both directions: small edits can force two different images to match, or stop two similar images from matching [3], [4]. In a cache shared across users, a forced match would serve one page's text for another.
What we saw on part of our traffic
We turned the feature on for a non-public subset of CSPaper's production traffic, not for all of it, and studied a snapshot of the cache after about 38 days. Every number in this section describes that group only. It is not a measurement of CSPaper's traffic as a whole.
One page in four came from the cache
The cache held 69,462 entries and recorded 24,035 hits, out of 93,497 distinct page lookups. That gives a page hit rate of 25.71%. Each hit is one OCR page we did not pay for. When we grouped entries by the week they were created, the hit rate of each of the five full weeks stayed between 20.97% and 30.63%.
Partial reuse is real
We also grouped the results by review (Figure 2):
The 594 partial reviews are revised or mixed papers. A whole-file cache would miss all of them, but page-level reuse catches them. Even the 1,204 fully cached reviews are not necessarily exact re-uploads: their pages can come from several earlier documents, which a whole-file cache would not see either.
A small set of pages does most of the work
Most entries (80.02%) had no hit yet. The 7.17% of entries with two or more hits produced 62.96% of all hits, and the busiest entry was hit 25 times. Pages cached near the end of the window had less time to be reused: entries aged 0–1 days had a hit rate of 20.52%, and entries aged 8–30 days reached 27.43%.
Reuse happens fast
For entries with at least one hit, the median time from creation to the last recorded update was 18.13 minutes. 65.95% fell within one hour, 86.08% within 24 hours and 96.46% within seven days. This fits authors who upload the same paper several times in a short period. The cache works like a short-term working set with a long tail.
The cache has no eviction yet, and a shared cache raises questions about deletion and access. Since most reuse happens within a day, a future retention policy should look closely at the first day and the first week after an entry is created.
What we have not measured yet
The numbers above count OCR work we avoided on part of our traffic. They are not a net saving, and they are not a platform-wide figure. We want to be clear about both gaps.
- The numbers cover only part of our traffic. The data come from a non-public subset of CSPaper's production traffic over about 38 days. They do not show the hit rate across all of CSPaper, or a stable long-term rate, which may change with submission deadlines, user growth and product changes. The hit rate also counts only lookups that left a trace in the cache, so it is an observed rate, not a complete measurement of that traffic.
- 24,035 is a lower bound on avoided OCR pages. It does not count repeated pages inside one PDF. Those were rare (page count matched distinct pages for 5,806 of 5,810 checked reviews), so the bound is close to the true number.
- The overhead is not measured yet. Every page is still rendered, cleaned and hashed, and every upload needs a lookup. The cache pays off as long as its average overhead per page lookup stays below about a quarter of the cost of one OCR page. We did not have per-step timers, so latency and total cost are open questions.
- Exact hashing does not remove every risk. The clean-up step is lossy, so two different pages could in principle become identical after it. We saw no false match, but the validation sample was small.
The thesis lists these limits in detail and proposes the next steps: a per-page event log, per-step timers, and tests with pages that differ by a single digit or sign.
Beyond this work
The same pattern can work for other expensive steps, such as layout analysis, table and formula recognition, or translation. It needs three conditions:
- Each unit can be processed independently.
- The system can put each result back in the correct position.
- Every setting that changes the result is part of the key.
The page is the unit we identify, reuse and pay for. The PDF is still the unit we send. That split is what keeps the work small without changing anything downstream.
Read the full thesis
This post is based on the MSc thesis Fine-Grained Content-Addressed Computation Reuse for Document Processing Pipelines by Lingxiao Yin (Technical University of Denmark, 2026) [5]. It covers the formal model, the break-even condition, the production code path, and the full evaluation. It is published on CSPaper OpenPrint.
Acknowledgements
Page-level reuse was designed, built and evaluated by Lingxiao Yin as an MSc thesis in Computer Science and Engineering at the Technical University of Denmark (DTU), in collaboration with CSPaper. The work was supervised by Lei You and Birger Andersen at DTU, and by Yong Du and Lele Cao at CSPaper. This article was drafted from the thesis and edited by the CSPaper team.
References
[1]Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192.
[2]Monga, V., & Evans, B. L. (2006). Perceptual image hashing via feature points: Performance evaluation and tradeoffs. IEEE Transactions on Image Processing, 15(11), 3452–3465.
[3]Hao, Q., Luo, L., Jan, S. T. K., & Wang, G. (2021). It's not what it looks like: Manipulating perceptual hashing based applications. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS '21), 69–85.
[4]Struppek, L., Hintersdorf, D., Neider, D., & Kersting, K. (2022). Learning to break deep perceptual hashing: The use case NeuralHash. In Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency (FAccT '22), 58–69.
[5]Yin, L. (2026). Fine-grained content-addressed computation reuse for document processing pipelines. Master's thesis, Technical University of Denmark. CSPaper OpenPrint 20261020.0001v1.
[6]Cao, L., You, L., & R&D Team. (2025). CSPaper Review: Fast, rubric-faithful conference feedback. In INLG 2025 System Demonstrations.