SciArgus – Glenn Moncrieff

Keep up with the firehose of scientific literature is exhausting. Often I just want to give up and crawl into a cave of ignorance.

I don’t think this makes me unusual. There are thousands of new papers every week across the journals that might plausibly matter to someones particular interests, and nobody reads that, so what most of us end up doing is relying on whatever floats past on social media or whatever a colleague happens to mention. Which is a pretty bad way to sample the literature. You see the things that are loud and well-marketed, and you miss the quiet paper from some random small lab that solved your exact problem eighteen months ago.

The tools that are meant to fix this have never really worked for me. Journal table-of-contents alerts give you everything a journal publishes, so if you follow anything general you’re wading through chemistry and immunology to get to the one ecology paper you wanted, and after a month you stop opening the emails. Keyword alerts on Scholar have the opposite problem. They only match the words you happened to think of when you set them up, so they miss the paper that describes your problem in different vocabulary, which is most of them, because a remote sensing person and an ML person can write about the same method and share almost no nouns. And a keyword has no idea what you find interesting anyway. “Machine learning” matches something like a hundred thousand papers a year and about nine of them are for me.

What I actually wanted was a colleague who reads everything, knows roughly what I work on, and sends me a note on Monday saying these six are worth your time and here’s why. That’s a reading comprehension problem rather than a search problem, and reading comprehension happens to be something language models got good at recently. So I built SciArgus.

The name

In Greek mythology Argus Panoptes was a giant with a hundred eyes. Hera set him to guard Io, and because he only ever closed a few of his eyes at a time he never actually slept, which made him a very good watchman. That’s roughly what you want from something monitoring the literature, and roughly the opposite of what any actual researcher can manage, so I named it after him.

How it works

It’s a scheduled GitHub Action. It wakes up every Monday morning, does five things, and emails you the result.

1. RESOLVE     plain-text names  ->  OpenAlex IDs
2. SCRAPE      search OpenAlex for papers from the last 7 days
3. SCORE       LLM scores every candidate against all your topics
4. SUMMARISE   LLM writes a personalised note for the ones that made the cut
5. EMAIL       renders an HTML newsletter and sends it

The stage that matters is the scoring, and what makes the scoring work is something you write yourself.

You describe your research interests in your own words, as paragraphs rather than keywords. Not “remote sensing, biodiversity, lidar” but an actual description of what you find interesting and why. Mine for one topic runs to about sixty words and gets fairly specific about sensors, scales, and the kinds of questions I care about. Every candidate paper’s title and abstract then goes off to a language model along with all of your topic descriptions, and it scores relevance from 0 to 10 and picks the single topic each paper best matches.

That’s the bit a keyword can’t do. The model is reading your description of your interests and reading the paper and making some judgement about how the two relate, so it turns up the paper that never uses your words, and it skips the paper that uses all of your words about something you don’t care about.

Journals work as a quality filter here, not a subscription. You give it a whitelist of journals and preprint servers, and topic searches only come back with papers published in those venues. This is why a topic as absurdly broad as “machine learning” still works: you only ever get ML papers out of the journals you already read, not the entire ML literature. Authors work the other way around. Papers by the people you track come through from any venue at all, which is how you catch a collaborator publishing somewhere you’d never think to look.

One detail I’m happy with. When it picks the final list it doesn’t just take the top 10 by score. It takes the best paper from each of your topics first, and only then fills the remaining slots by score. Without that, one hot topic eats the whole newsletter every week and your quieter interests quietly disappear, which is exactly the failure I was trying to avoid in the first place.

The whole thing runs on a small free model (gemini-3.1-flash-lite) and scores papers in batches of ten. A typical week throws up 100 to 200 candidates and costs about 20 model calls.

What it costs

Nothing, and I don’t mean that in the “free tier” sense where you’re three months from a bill. GitHub Actions gives you 2,000 minutes a month and a run takes about 10, so I use maybe 40 minutes of it. Gemini’s free tier allows 15 requests a minute and 500 a day, and a run uses about 20. Gmail will send 500 emails a day and I need one. OpenAlex is free. No credit card goes anywhere.

That’s also why it’s a repository you fork rather than a website I host. If I ran it as a service I’d have to pay for it, so I’d have to charge for it or advertise or harvest something off the back of it. Running in your own GitHub account on your own free quotas, it can just sit there being useful.

Quick start

This takes about 30 minutes and needs no programming experience. You’ll be clicking things in a browser and editing three text files. You never have to run anything on your own machine.

1. Fork the repository

You’ll need a GitHub account first. If you don’t have one, sign up, it’s free.

Then go to the SciArgus repository, click Fork in the top right, and click Create fork. You now have your own copy at github.com/YOUR-USERNAME/SciArgus.

Now the step everyone misses. Forks have Actions switched off by default, so nothing will ever run until you turn them on:

Go to the Actions tab of your fork and click “I understand my workflows, go ahead and enable them”.

Skip this and everything else will look fine and no newsletter will ever arrive.

2. Get a Gemini API key

This is the model that does the scoring and the summaries.

Go to Google AI Studio
Sign in with a Google account
Click Get API key in the left sidebar
Click Create API key
Copy it somewhere for a minute

The free tier is plenty and you won’t be asked for a card.

3. Get an OpenAlex API key

OpenAlex is where the papers come from. You can technically hit the API without a key, but you’ll start collecting 429 rate-limit errors, so get one.

Go to the OpenAlex API key page
Follow the instructions to request a free key
Copy it

4. Create a Gmail app password

The newsletter goes out through Gmail, and Google won’t let a script log in with your normal password. You need an app password, which is a 16-character password that can send mail and do nothing else.

You need 2-Step Verification switched on first, otherwise the app password page simply doesn’t exist, which is a confusing dead end if you’re not expecting it.

Go to myaccount.google.com and click Security
Under “How you sign in to Google”, turn 2-Step Verification on if it isn’t already
Go to myaccount.google.com/apppasswords
Under “App name”, type SciArgus and click Create
Copy the 16-character password straight away, because it’s never shown again

If you’d rather the newsletter didn’t come from your main address, make a throwaway Gmail account and send from that.

5. Add your secrets to GitHub

Secrets are private values the Action can read but which never show up in your code or your logs.

In your fork, go to Settings > Secrets and variables > Actions, and click New repository secret for each of these. The names have to match exactly:

GEMINI_KEY: your Gemini key from step 2
OPENALEX_SECRET: your OpenAlex key from step 3
GOOGLE_APP_PASSWORD: the 16-character app password from step 4
SENDER_EMAIL: the Gmail address you made the app password for
RECEIVER_EMAIL: where you want the newsletter to land

Sender and receiver can be the same address.

6. Describe your interests

Three plain text files in the config/ folder decide everything. Edit them directly on GitHub: click the file, click the pencil icon, edit, click Commit changes.

config/topics.md is the one that matters. Each topic is a heading followed by a description paragraph. The heading gets used as a search query, and the description is what the model uses to judge relevance and to write your summaries.

#Remote Sensing of Biodiversity
Research into the application of remote sensing for the quantification
of biodiversity and ecosystems at both local and global scales. This
encompasses all sensor technologies, including drones, airborne and
satellite LiDAR, radar, and optical sensors (particularly hyperspectral).
Topics should cover the development of new sensor technologies, the
creation of novel algorithms for ecosystem monitoring, and advancements
in leveraging existing sensors to derive critical biodiversity information.

Be specific here. A one-liner like “I like remote sensing” gives the model nothing to discriminate with and you get a noisy useless digest. Mention methods, organisms, scales, sensors, the questions you actually argue about at conferences. Five to fifteen topics is a good range. Each paper gets assigned to at most one topic, so overlapping topics won’t give you duplicates.

config/authors.md is one name per line:

Andrew Balmford
Sara Beery
Hugh Possingham

Use the name as it appears on their papers. OpenAlex resolves to the highest-cited match, so common names usually land on the right person. Twenty to fifty is sensible.

config/journals.md is one journal or preprint server per line:

Nature
Science
bioRxiv
Conservation Biology
Remote Sensing of Environment

Cast a wide net, 50 to 150 is typical, and put in the preprint servers for your field so you see things before formal publication. Remember this list only filters topic searches. Papers by your tracked authors come through regardless of where they appear.

7. Test it before you trust it

Don’t wait until Monday to discover you typed a secret name wrong.

Go to the Actions tab
Click Weekly SciArgus Newsletter in the left sidebar
Click Run workflow > Run workflow
Wait 5 to 10 minutes. You can click into the running job and watch the logs live
Check your inbox, then check your spam folder

That’s it. It’ll arrive every Monday at 08:00 UTC from now on and you never have to touch it again.

8. Changing the schedule

If Monday at 08:00 UTC doesn’t suit you, edit .github/workflows/weekly_newsletter.yml. The cron line is the schedule, in UTC, in the format minute hour day-of-month month day-of-week:

- cron: '0 8 * * 1'   # Monday 08:00 UTC

So '0 14 * * 5' gets you 2pm UTC on Fridays.

When it goes wrong

A few things that catch people out:

Nothing ran at all. You didn’t enable Actions on your fork. See step 1.

“No results for [some name]”. OpenAlex couldn’t resolve that author or journal. Check the spelling against how it appears on their papers or the journal’s own website. Accented characters need to be the real Unicode character.

A journal throws a 400. Some journal names with commas in them break the OpenAlex filter syntax. Shorten the name or drop the comma.

Gemini returns 429 RESOURCE_EXHAUSTED. You’ve hit the rate limit. It retries by itself, and normal usage sits well under the daily cap, so this usually means something ran a lot more often than it should have.

The email never arrived. Check spam. A brand new Gmail sender often gets filtered for the first few sends. Mark it “not spam” once and it settles down.

The papers are boring. Your topic descriptions are too vague. This is nearly always the answer. Go back and write more.

Is it any good?

I’ve been running it on myself for a few months. It’s good at breadth and pretty mediocre at depth, which is roughly what I was after. It reliably turns up two or three papers a week that I wouldn’t otherwise have seen, and I properly read maybe half of those. The obvious limitation is that it’s agreeable. You tell it what you’re interested in, it finds you papers about what you’re interested in, and it will cheerfully help you read the same thing forever. It’s a tool for keeping up. Finding the thing outside what you already know you like is a different problem and I don’t have a good answer for it.

The code is on GitHub. If you fork it and it breaks, open an issue and tell me.