The repository description says 180 roles and the page says 1,117

Two different scales for the same project

The repository description says 180 open software engineering internships from 4,300 employer job boards. The page header says something quite different:

> 1117 open roles (636 listed below) · 181 new this week > > 4,675 employers tracked · data as of Oct 02, 2026 at 23:16 UTC

And the table of features states the polling scope directly: 4,943 job-board endpoints, 4,675 distinct employers, some of which run more than one board, polled every thirty minutes across twelve ATS platforms.

So 180 against 1,117 for the headline number, and 4,300 against 4,675 for employers. The description is a stale copy of an earlier state of the same engine, and the difference is large enough that a reader arriving from the repository page and a reader arriving from the site would not agree on the size of the thing.

The page's own numbers are internally consistent, though. Of the 1,117 open roles, 757 have a cycle the employer stated and 360 are recent postings where no cycle is stated anywhere, and 757 plus 360 is 1,117. The remaining gap is between open roles and the page itself: 636 of them are printed in the README, the rest are reachable through the dashboard and the feeds.

The headline names one cycle and the repository name names two

The repository is called Automated-List-Of-Summer-2027-and-Fall-2026-Tech-Internships. The scope table agrees with two cycles, Summer 2027 and Fall 2026. The heading on the page says Summer 2027 Tech Internships and nothing else, and the repository description mentions no cycle at all, only 180 roles.

The cycle handling inside the list is stricter than the naming suggests, and that is the most transferable idea in the project. A cycle section holds only roles whose employer stated that cycle, whether in the title or in the posting text. Postings that name no cycle anywhere go into a separate Recently posted, cycle not stated section, with no cycle guessed for them. Same quality bar, different amount of evidence, and the two are never mixed.

So a Fall 2026 role exists in the data and may not appear in the Summer 2027 heading, and a role with no stated cycle appears only in the fallback list. The page tells you which is which rather than presenting a single ranked list.

Two of the flags mean the data cannot prove anything

The visa and sponsorship markers are computed rather than crowdsourced, and the documentation is explicit about the difference between a fact and an absence of one.

A visa flag is detected automatically from each job description, and it marks postings that say they will not sponsor a work visa. A check mark after a company name is different: it means that employer had ten or more H-1B petitions approved in fiscal year 2022 to 2023, matched automatically against the official H-1B Employer Data Hub. The stated reasoning is worth repeating, because most published lists do not make it: no check mark does not mean they will not sponsor, it means we cannot prove they have.

Most postings say nothing either way, and the project says those show as unknown rather than guessed. That single policy is what separates the flags from a hand-built list.

The other three markers are simpler. A country flag means the role requires United States citizenship or a security clearance. A new marker means the role was spotted in the last 48 hours. A remote marker after a company name applies to that row's role rather than the whole company, which is a distinction that matters when a firm has both remote and on-site openings.

Three requisitions, three apply links, and a CSV that never groups

One detail in the table documentation is more careful than most job aggregators manage. When an employer has several live requisitions for the same job, in the same place, for the same cycle, the title carries a count in parentheses. Those are separate applications, each taking its own submission, so they are linked individually rather than by repeating the row.

Two consequences follow. The counts count requisitions, not distinct jobs, so the header's 1,117 open roles is a count of things you can apply to. And the CSV export is never grouped, which means a spreadsheet built from it treats those three requisitions as three rows.

The table layout is chosen for the same reason. Apply is the third column, immediately after the role, so the link stays on screen when the table is wider than the window. The Posted column is the date the company published the role, taken from the portal wherever the portal states one, which is what makes newest-first mean something.

Skill tags and pay are extracted from the posting text rather than typed in, with the stack a role wants and the pay it states pulled out so both are searchable on the dashboard and present in the CSV and the API.

The Drop Radar is a forecast that upgrades itself to a fact

The most distinctive feature is a forecast, and its honesty is in the labelling. Each marquee company's typical opening window is estimated and labelled as an estimate. The moment the engine catches the real drop date live, that date replaces the window, and only dates the engine saw itself are marked verified.

So the same field holds two different kinds of claim, distinguished by whether the project observed the event. A window you see in April may be replaced by a date in August, and nothing in the interface suggests the estimate was ever as good as the observation.

The rest of the roadmap is in the same voice. Recently shipped: email alerts, the Drop Radar, the automatic sponsorship flags, the live dashboard. Next up: personalised alerts where you pick your categories, per-company hiring pages, and a ghost-posting detector, which would catch roles that stay listed after they are filled.

The page states who built it and why, which is unusual and useful. The author describes himself as an international student studying in the United States, building for the search he is doing himself, with the list limited to United States roles because that is where he is searching.

Three pinned packages, two HTTP clients, and one hosted database

requirements.txt is three lines:

httpx==0.28.1
requests==2.34.2
supabase==2.31.0

Every version is pinned exactly, which is the right choice for something that runs on a schedule. Two HTTP clients is the odd note, since a scraper normally settles on one.

The third is more interesting. Supabase is a hosted database, so a tracker whose pitch is that the page needs no maintenance from you depends on somebody else's service between polling an employer's board and writing out the HTML. The tree has both a data/ directory, which holds the CSV the README points at, and a db/ directory, which is where a database client of some kind is being used.

pyproject.toml carries no project table at all. It is configuration only: ruff with a line length of 100 and a target of Python 3.11, lint rules E, F, I, UP and B with E501 ignored, and pytest pointed at a tests directory with a test_ file pattern. The dependency story therefore lives entirely in requirements.txt, and the package is not installable, which is consistent with run.py sitting at the root as the entry point.

The page is newer than the last commit, by design

The header says the data is as of Oct 02, 2026 at 23:16 UTC. The last push to the repository is 2026-10-01 at 15:42 UTC, a day earlier. Those two facts are consistent rather than contradictory, and the reason is visible in the badges: a link to a GitHub Actions workflow, and a GitHub Pages site.

The page is served from a project site and rebuilt by that workflow every thirty minutes, so the artefact you read is always newer than the source tree. That is a better design than a list that has to be committed, and it also means the repository's commit history is not a record of what the page contained at any given moment.

The rest of the tree is documentation heavy in a useful way: METHODOLOGY.md, PRIVACY.md, ARCHITECTURE.md, ROADMAP.md, SECURITY.md and CONTRIBUTING.md, alongside src/, tests/, tools/, db/ and data/. There are no GitHub releases, so a data pipeline with no tagged version is something to keep in mind when the numbers on the page need to be cited.

There are no releases, no changelog and no pinned upstream snapshot, which for a project whose entire output is a number is the one gap worth naming.

Editorial conclusion

This tracker is worth using as a first pass, and its real value is that it refuses to guess. Roles appear under a cycle only when the employer said so, unstated ones get their own section, visa flags come from the posting text, H-1B marks come from a federal dataset, and a missing mark is reported as unprovable rather than as absent. That discipline is rarer than the scraping. Two things to check before you rely on the numbers. The scale you read, since the repository description still says 180 roles and 4,300 employers while the page says 1,117 and 4,675, so quote the page and not the repository blurb. And the freshness, since the page is rebuilt by a scheduled workflow while the last commit is older, which means there is no release to pin and no changelog to check when a role disappears. Both are small, and both are the kind of thing that changes how you cite a list of 1,117 openings.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zshah101/Automated-List-Of-Summer-2027-and-Fall-2026-Tech-Internships on GitHub