Paper2Any is a legacy snapshot: what the Apache-2.0 code actually contains now
Turn paper/text/topic into editable research figures, technical route diagrams, and presentation slides.
At a glance
- What is it?
- Paper2Any's repository still ships the original Apache-2.0 paper-to-figure and paper-to-slides code, but the README states plainly that new development moved to a hosted product called Nexus Office. Here is what that split means for anyone deciding whether to clone it.
- Who is it for?
- Adopt this repository only if you want the original Apache-2.0 paper-to-figure and paper-to-slides code and accept that it is frozen; the README states it no longer receives new product features or architecture updates. Do not adopt it if you need PowerPoint, Excel, or Word generation, since that work now lives in the hosted Nexus Office product whose implementation is not distributed here.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Paper2Any was built to do, and what the repository is now
The original pitch is narrow and specific: turn a paper, a block of text, or a topic into editable research figures, technical route diagrams, and presentation slides. That is a different job from generic slide generation. A research figure has to survive being moved into a paper, which means the output has to remain editable rather than being a flat image, and a technical route diagram has to reflect the actual method described in the source document. The topic list attached to the repository (agent, aippt, editable-pptx, langgraph, paper2slides, ppt-generator) is consistent with that scope. Python is the primary language.
The complication is the repository's current status, and it is not a minor footnote. A callout near the top of the README reads: "Repository status: legacy open-source snapshot." The same callout states that the repository "no longer receives new product features or architecture updates," and that the actively developed product is Nexus Office, rebuilt on a new stack and offered as a hosted service. The README adds that the hosted or commercial implementation "is not included in this repository."
So there are two things sharing one name. There is a frozen Apache-2.0 codebase, which is what you get if you clone the default branch. And there is a live hosted workspace at paper2any-studio.cpolar.cn, which the README promotes with animated banners and screenshots. Anyone landing on the GitHub page and skimming the images could easily conclude they are looking at the source of the product in those images. The comparison table in the README says otherwise: the entry point for this repository is "Continue reading the archived documentation below."
The agent loop the README describes, and the architecture it does not
The README gives a five-step flow in a plain text block: a goal plus source files, then the agent chooses the Office and visual tools, then editable PPTX, XLSX, DOCX or PNG, then structural checks and visual review, then open, revise, and continue in the same workspace. It also states that the same workspace retains the conversation, execution trace, source files, deliverables, and follow-up edits, and that users do not need to know individual Skill names before starting.
Read carefully, that flow describes Nexus Office, not the archived Paper2Any workflows. It is presented under the heading "One workspace, one continuous Agent workflow" in the section of the README devoted to the new product. Nothing in the supplied material describes the internal architecture of the legacy code: no module list, no graph definition, no node names, no explanation of how a parsed paper becomes a figure specification. The langgraph topic on the repository suggests a graph-based orchestration library is involved somewhere in the history, but the README does not confirm that, and I cannot verify it from the material given.
The one architectural claim that belongs to the legacy scope is the output format. Editable PPTX is named as a topic, and the README's own comparison table describes this repository's scope as "historical paper, figure, diagram, and presentation workflows." If editability is the reason you are looking at this project rather than a text-to-image pipeline, the repository topic list is the only confirmation available here, and it is a weak form of evidence. Treat the editability guarantee as something to test on your own documents rather than something the documentation establishes.
Getting it running: what the README does and does not tell you
There is no installation section in the supplied README. No pip install line, no conda environment file, no docker command, no configuration keys, no environment variable names, no model provider settings. The README is a product page for Nexus Office wrapped around a notice that the code below it is archived. If you need a copy-pasteable setup path, this document does not contain one, and I am not going to invent commands that the project has not published.
What you can check yourself, in order, once you have the tree: whether setup.py or pyproject.toml exists and what it declares, whether a requirements file pins the LangGraph version, whether any entry-point script is present, and whether the code expects API keys for a model provider. The homepage URL in the repository metadata points at the hosted workspace, not at documentation for the legacy code, so it will not answer these questions.
The realistic setup path for a frozen Python research project is to read the source, install what its own dependency declarations list, and run it in an isolated environment. That is not a strong endorsement, and it is not meant as one. The absence of setup instructions in a repository that has stopped receiving updates is a maintenance signal: the last push recorded is 2026-08-31, and no releases were retrieved, so there is no versioned artifact to pin against. You are tracking a branch, not a release.
The licence boundary is the part to read closely
The repository is Apache-2.0. The README's own badge is more precise than the repository metadata: it labels the licence as "Legacy Code - Apache 2.0," which is a deliberate distinction. The comparison table separates "Apache-2.0 source code in this repository" from "Hosted/commercial implementation is not distributed here."
The practical consequence is that the permissive grant you get applies to the code in this repository and to nothing else. Apache-2.0 permits commercial use, modification, and redistribution of what it covers, subject to its own conditions around notices and attribution. It does not reach the hosted product, because that code was never published under it. If your plan involves taking the Paper2Any idea and shipping a service, the licence on the snapshot is not the obstacle; the obstacle is that the snapshot is the old architecture and the new one is not available to you at all.
I am not a lawyer and this is not legal advice. Before you build anything commercial on this code, read the LICENSE file in the repository and confirm which directories the grant actually covers, particularly if any bundled assets, model weights, or example documents sit alongside the source.
Where this is the wrong tool
The clearest failure case is also the one the README advertises most heavily. If your goal is generating PowerPoint, Excel, or Word deliverables, this repository is not the product for that. The README's own table assigns PowerPoint, Excel, Word, and AI visual creation and editing to Nexus Office and assigns "historical paper, figure, diagram, and presentation workflows" to this repository. Cloning the default branch to get the Excel dashboard workflow shown in the screenshots will not work, because the screenshots come from the hosted product.
The second case is any project that needs a stable dependency. A codebase described as receiving no new architecture or feature synchronization is a codebase where an upstream library change can break you with no fix coming. The langgraph topic makes this concrete: agent orchestration libraries have moved quickly, and a frozen snapshot pinned to an older API is a liability if you plan to keep it running for years.
The third case is reproducibility. With no releases retrieved and no installation documentation, there is no supported way to get the same environment a previous user had. If your workflow requires pinned, auditable dependencies, this repository does not offer them.
What the alternative actually is, and where the difference lies
The alternative the README names is Nexus Office, the hosted workspace at paper2any-studio.cpolar.cn. The difference is not a feature list; it is a change of scope and a change of delivery model. Paper2Any was a set of isolated paper workflows: take a paper, produce a figure or a deck. Nexus Office is positioned as an Office workspace, with the README stating it "focuses the product on everyday Office delivery instead of adding more isolated paper workflows."
That reframing has a cost. The hosted product is a service, so your source documents leave your machine unless you run the legacy code locally instead. The legacy code is Apache-2.0 and you can read all of it; the hosted implementation is closed and you can read none of it. You are choosing between a frozen thing you control and an evolving thing you do not.
For a narrower comparison, a plain text-to-image or text-to-slides pipeline is the other realistic option, and the difference there is editability. The repository's editable-pptx and editable-pptx-adjacent topics indicate native objects rather than rendered images as the intended output. Whether the legacy code delivers on that for your documents is exactly the thing the supplied README does not let you confirm.
Who should clone this, and what to verify first
Clone it if you want to read or fork the original Apache-2.0 implementation of paper-to-figure and paper-to-slides generation, you are comfortable working from source without setup documentation, and you accept that the architecture is frozen. That is a real use case. Reading a working agent pipeline for document-to-figure conversion can be more instructive than reading a paper about one, and the licence lets you reuse what you find.
Do not clone it if you need Office file generation, if you need a maintained dependency, or if you were drawn in by the screenshots of editable PPTX decks and Excel dashboards. Those belong to the hosted product. The README is explicit that the hosted implementation is not distributed here, and no amount of reading the legacy tree will produce it.
Before you commit, do three things in this order. Open LICENSE and confirm the scope of the grant against the actual directory layout. Check whether the tree contains a dependency manifest and an entry point, since the README supplies neither. And run the legacy code on one of your own papers before trusting the editable-output claim, because that claim rests on repository topics rather than on documentation you can read. If the first two checks fail, the third one is moot.
Editorial conclusion
Adopt this repository only if you want the original Apache-2.0 paper-to-figure and paper-to-slides code and accept that it is frozen; the README states it no longer receives new product features or architecture updates. Do not adopt it if you need PowerPoint, Excel, or Word generation, since that work now lives in the hosted Nexus Office product whose implementation is not distributed here. Before cloning, read LICENSE, confirm which paths the Apache-2.0 grant covers, and check whether setup.py, requirements files, or a LangGraph entry point exist in the tree, because the supplied README documents no installation command.
Community notes