daily-arXiv-ai-enhanced: a research digest that runs entirely inside GitHub Actions

A daily crawl configured entirely through repository variables

There is no config file to edit. The README's setup instructions push every setting into GitHub's own secrets and variables screens, which is what lets the workflow stay unchanged across forks.

Two repository secrets carry the model credentials, named OPENAI_API_KEY and OPENAI_BASE_URL. The second one matters more than it looks, because an OpenAI compatible base URL is the switch that lets any provider be plugged in rather than a single vendor being baked in. The optional ACCESS_PASSWORD secret gates the published page, and the README points at a pull request for that mechanism if you want to add one.

The repository variables hold everything that is not sensitive: CATEGORIES as a comma separated list such as "cs.CL, cs.CV", LANGUAGE such as "Chinese" or "English", MODEL_NAME such as "deepseek-chat", and EMAIL and NAME for the git push the workflow performs. Splitting these from the secrets is the pattern to copy, since it means a fork can change what it tracks without anyone regenerating credentials.

The default category list is worth writing out because it defines the project's personality: cs.CV, cs.GR, cs.CL, cs.AI, cs.CE, cs.GT, cs.IT, cs.LG. Computer vision, graphics, computational linguistics, AI, computational engineering, computer theory, information theory and machine learning, in other words a broad computer science reading list rather than a single field.

Why Actions and Pages instead of a hosted app

The README states the pitch as zero infrastructure required, because GitHub Actions and GitHub Pages are doing the work that a server would otherwise do. The crawler runs on a schedule, writes markdown into the repository, and GitHub serves the site from a branch.

The deployment target is set in repository settings under Pages, where the README tells you to choose Deploy from a branch with the branch set to main and the path to /\(root\), then to wait a few minutes before visiting your own Pages URL. There is a linked issue for more precise instructions, which is a fair signal that the first attempt is the fiddly part.

The repository tree explains what that produces. Alongside the workflow directory there are index.html, login.html, settings.html and statistic.html at the root, css/, js/, images/, assets/ and ai/ directories, a _config.yml that is the Jekyll convention this Pages setup uses, and template.md plus readme_content_template.md holding the output shapes. The daily_arxiv/ directory is the crawler package itself, to_md/ handles conversion, and update_readme.py and run.sh are the entry points a local run would use.

The README also gives an honest cost figure of roughly 0.2 CNY per day for the model calls, which is the number that makes this model of deployment hard to argue with: the infrastructure is free and the inference is the entire bill.

The Python package underneath the JavaScript shell

The repository language reads as JavaScript because of the static site, but the crawler is a Python package declared in pyproject.toml, named daily-arxiv at version 0.1.0 with the description Daily crawl arXiv papers and use LLMs to summarize them, requiring Python 3.12 or newer and carrying an Apache-2.0 license marker in the file itself.

Its dependency list is short and tells you the approach:

dependencies = [
    "arxiv>=2.1.3",
    "dotenv>=0.9.9",
    "langchain>=0.3.20",
    "langchain-openai>=0.3.9",
    "requests>=2.32.3",
    "scrapy>=2.12.0",
    "tqdm>=4.67.1",
]

The arxiv client handles metadata, requests handles plain HTTP, and both are paired with langchain and langchain-openai so the summarization step goes through an abstraction rather than a hand written HTTP call to one provider. That is the same reason OPENAI_BASE_URL exists as a setting. scrapy alongside requests suggests two retrieval paths, which fits a project that sometimes needs the arXiv API and sometimes needs to fetch an HTML abstract page, and tqdm is there so a long crawl shows progress in a log you can actually read.

dotenv is the one entry worth noting for anyone running locally, since it is how a local run avoids editing workflow variables. The authors listed in the file are Wei Deng and Jian Guan, with contact addresses attached, and the tree carries a uv.lock next to pyproject.toml, so the intended local workflow is uv rather than a hand built environment.

The SKILL/ directory at the tree root is a separate idea. The README describes plug-and-play skill modules for customizing paper filtering, and points at a one-click copy in Settings that exports your keyword and author configuration so it can be combined with a SKILL for reproducible and shareable setups. That is the feature that distinguishes this from a plain daily dump: the filtering configuration can leave your browser as a value somebody else can apply.

What the reader actually gets on the published page

The README lists the reading side features as personalized paper highlighting based on your interests, cross device compatibility on desktop and mobile, local preference storage for privacy, and flexible date range filtering.

Local preference storage is the part with a design opinion behind it. Highlight rules and keyword interests stay in the browser instead of being sent anywhere, which is why the page needs no account and why the README can say the setup is free to deploy and use. A login.html exists in the tree for the case where you set a password, but for an unpassworded deployment there is nothing to log into.

Date range filtering is the feature that turns a daily list into something you can go back and read. A digest that only shows today punishes anyone who missed a day, and an arXiv run can be a hundred papers, so being able to ask for a window matters more than the daily cadence itself.

The homepage is not the repository README. The README links a live instance at a dw-dengwei.github.io address and also lists a separate deployed domain as the project homepage, which is the arrangement most forks will replace: your fork serves from your own GitHub Pages URL, and the original domain keeps pointing at the original.

One caveat the README puts at the very top is worth taking seriously rather than skimming. In both its Chinese and English versions it warns that if your jurisdiction applies censorship requirements to academic data you should run the code with caution, and that any secondary distribution must remove the entrance accessible to China and handle content review obligations, with legal consequences falling on the downstream party. That is a real constraint on redistribution of a tool whose output is derived from arXiv papers.

The setup path from fork to first digest

The README's customization section is collapsed into a details block, which is a reasonable signal of how optional it is. The path runs from a fork through secrets, variables, a manual workflow run and finally Pages.

The first step is forking the repository and deleting the author's own information from the buy-me-a-coffee directory, a detail that matters more than it sounds for anyone who plans to publish their fork. Then come the two secrets, the optional password secret, and the five repository variables listed earlier. After that the README sends you to your own Actions tab and the workflow named arXiv-daily-ai-enhanced, where you can click Run workflow to test it manually.

That manual run is the honest part of the instructions: the README warns it may take about an hour, and that by default the action runs every day on its own. The schedule lives in .github/workflows/run.yml, which is the single file to edit if you want a different cadence or want to skip weekends.

The order of the steps is worth respecting for one non-obvious reason. Testing the workflow before configuring Pages means you find out about a bad API key or an unreachable base URL while the failure is visible in the Actions log, rather than after you have spent time on deployment settings for a workflow that never produced anything.

Editorial conclusion

The interesting decision in this project is not the summarization but the deployment model. Everything happens inside a GitHub Actions workflow and lands in a branch, which means the whole bill for a personal digest is a few tenths of a yuan a day and there is no server to patch, no container to keep alive and no uptime to worry about at three in the morning. It also means the constraints are GitHub's constraints: the workflow takes about an hour, which is the real reason summaries arrive in batches rather than instantly, and your API key lives in Actions secrets rather than in a config file. If you fork it, the two variables worth changing first are CATEGORIES and MODEL_NAME, since the default set is eight categories and the default model is deepseek-chat with summaries written in Chinese. Leave ACCESS_PASSWORD unset only if you are comfortable with every visitor of your Pages site reading the digests, and remember that the OpenAI-compatible base URL and key mean the arXiv titles, abstracts and any personal keyword configuration are sent to whichever provider you point at.

Frequently asked questions

Official sources

1. dw-dengwei/daily-arXiv-ai-enhanced on GitHub
2. Issues
3. Project website
4. README