MethodologyMethodology
Collection
Each day, we scrape Anthropic’s careers page and OpenAI’s job board. We publish the counts and posting records with a seven-day delay.
| Term | Definition |
|---|---|
| Posting | An advert identified by the lab’s own ID. A new ID counts as a new posting. |
| Open | Returned by that day’s scrape. |
| First seen | The first date our scrape returned the posting. |
| Last seen | The most recent date our scrape returned the posting. |
| Closed | No longer returned by a subsequent scrape. It stops counting as open from that date; its last seen date stays unchanged. |
| Reopened | Returned again under the same ID. It counts as open again and retains its original first seen date. |
| Revision | A change to the title, department, advert text, location or link, dated to when we first observe it. |
Classification
We give a language model each posting’s title, department and full advert text. We ask it to choose one of sixteen sub-categories grouped within five main categories, or Other if none of these fits. We include postings classified as Other in the downloads, but do not show them on the chart. As of September 2026, none of the 3,646 postings we have collected from Anthropic and OpenAI has been classified as Other in any of its revisions.
We developed the definitions and classification instructions by manually reviewing samples of labels. When we found misclassifications, we revised the definitions and instructions. The taxonomy is currently at version 1.0 (October 2026).
Category definitions
The five main categories group roles by the kind of work the lab is hiring for.
| Category | Description |
|---|---|
| Research | Roles that build and understand the models themselves. This covers the scientists and engineers who train and evaluate models, the teams that acquire and produce training data, and safety work on the models’ harmful behaviour and misuse. |
| Compute | Roles that build the hardware and low-level software the models run on. This spans the labs’ own chips, the datacenters from site to rack, and the cluster, training and inference software layered on top. |
| Product | Roles that build the things customers use. This includes the API and developer platform, consumer and business apps, coding products, robotics, consumer devices and the advertising business, together with the product managers and designers embedded in those teams. |
| Go-to-market | Roles that sell to and serve customers. This covers sales, marketing, partnerships and growth, the forward-deployed engineers who build for a named customer after the sale, and customer support at scale. |
| Corporate | Roles that run the company. This covers finance, recruiting and people operations, workplace and IT, information security, and the lab’s interface to governments and the public through policy, legal and communications. |
| Other | Roles that do not fit any category above. These are included in the download but not shown on the chart. |
Each main category is divided into the sub-categories below, which are the labels the model assigns.
| Sub-category | Category | Definition |
|---|---|---|
| Research | Research | Model training and experimentation: pretraining, post-training and RL, fine-tuning, evaluations and benchmarks, model architecture, data science on model behaviour, and research on data mixtures and synthetic data. Includes infrastructure and tooling for researchers: sandboxing and execution environments for training, research CI, and developer productivity for research workflows. |
| Data | Research | Acquiring and producing the data models learn from: human-data programmes (raters, annotators, feedback and preference pipelines, task design), data vendor and licensing management, large-scale dataset acquisition, curation and quality operations, and the tooling built for those pipelines. The output of the work is data rather than a trained model. |
| Safety & safeguards | Research | Work whose subject is the model’s harmful behaviour or misuse: safeguards, trust & safety, model policy, preparedness, dangerous-capability evaluations, CBRN and cyber-harm analysis, red-teaming of models, abuse and enforcement, alignment and interpretability research, societal impact, and model welfare. |
| Silicon | Compute | In-house chips: architecture, RTL, design verification, physical design, packaging and signal integrity, ASIC firmware, silicon bring-up, and accelerator runtime software for in-house chips. |
| Datacenters | Compute | Siting, power, cooling, construction, commissioning and electrical work; server and fleet hardware; and datacenter supply and capacity planning where the role is technical rather than financial. |
| ML infrastructure | Compute | Clusters, scheduling, training runtime, kernels, and inference serving and performance. |
| Product & platform | Product | The API and developer platform, the consumer and business applications, coding products, and frontend, mobile, full-stack and application engineering, together with the product management, design, analytics, UX research and developer tooling embedded in the product organisation. |
| Robotics | Product | Actuators, manipulation, teleoperation, humanoid hardware, robot learning, and robotics simulation and test infrastructure. |
| Consumer devices | Product | Dedicated consumer hardware: device software and firmware, camera, connectivity, industrial design, wearables, and device-specific product work. |
| Ads | Product | The lab’s advertising business: ad products, ad formats and delivery, ad sales and measurement, advertiser platforms, and the sales and marketing roles dedicated to selling advertising. |
| Go-to-market | Go-to-market | Account executives and sales management, sales strategy and operations, deal desk, partnerships and channel, marketing, brand, communications aimed at customers, demand generation, growth, customer success in its commercial sense, competitive intelligence, and sales enablement. Also brand and marketing web engineering, in-house creative studios, and pre-sale technical evangelism and solutions engineering. |
| Forward deployed | Go-to-market | Forward deployed engineering, applied AI engineering and architecture, deployment engineering, technical success, customer engineering, and professional services. Work must involve building or configuring something for a named customer after the sale. |
| Customer support | Go-to-market | Support engineers and specialists, support delivery, support operations, support automation, user operations, and the vendor management behind them. |
| Information security | Corporate | Protecting the company and its systems from adversaries: security engineering, detection and response, application, platform, infrastructure and network security, identity and access, threat intelligence and investigations, vulnerability management, privacy engineering, governance and security compliance, insider risk, and offensive security against the company’s own systems. |
| Finance, people & workplace | Corporate | Finance, accounting, tax, treasury, audit, procurement and sourcing; recruiting and talent; people operations, compensation and benefits; workplace, facilities, real estate, physical and corporate security, health and safety; corporate IT and helpdesk; and company-wide programme management, business analytics and operations not embedded in one organisation. |
| Policy, legal & comms | Corporate | Public policy, global affairs, regulatory affairs, all legal and counsel work wherever it is filed, communications and press, public-benefit and economic-impact research, and externally facing societal and economic research. |
| Other | Other | Roles that fit none of the above. |
Classification rules
We give the model the following rules to guide its choices where the categories overlap.
- Duties and department names. The duties take precedence over the department in which a lab files the role. A safeguards engineer filed under Security therefore belongs in Safety & safeguards, while a network security engineer filed under Research belongs in Information security.
- Safety and security. Work on model misuse, harmful capabilities, alignment and user abuse belongs in Safety & safeguards, whereas protecting the company’s systems belongs in Information security. Fraud, chargebacks and billing operations for the company’s own payments are treated as Finance, people & workplace.
- Specialist and embedded functions. Legal, finance, HR, recruiting, IT, workplace and customer support retain their category regardless of whom they serve. For engineering, product and programme management, data science, design and operations, the classification instead follows the organisation in which the role is embedded. A programme manager in an inference team, for example, belongs in ML infrastructure; programme management, analytics and operations belong in Finance, people & workplace only when their remit is company-wide.
- Compute. The Compute sub-categories cover technical work on the hardware and software, while commercial, legal, financial, procurement, sourcing, supply-chain and deal-making roles follow rule 3. Tooling is classified by whom it serves, with tools for researchers placed in Research and tools for product engineers in Product & platform.
- Customer engineering. Work that involves building or configuring something for a named customer after the sale belongs in Forward deployed. Pre-sale technical selling, demos and evangelism belong in Go-to-market, while a team building a product for a market segment belongs in Product & platform.
- Forward deployed and support. The distinction rests on how the work is organised: Forward deployed covers project-based engineering embedded with a customer, while Customer support covers queue- or ticket-based work delivered at scale.
- Advertising and other commercial work. Ads covers the lab’s advertising business, while marketing its own products belongs in Go-to-market. Subscription, checkout and in-product commerce features belong in Product & platform, and pricing strategy and revenue operations in Go-to-market. Billing platforms, revenue accounting and payments infrastructure for the company’s own transactions belong in Finance, people & workplace.
- Robotics and Consumer devices. These categories take precedence for technical and embedded roles, so a research engineer on a robotics team is classified as Robotics. Specialist functions still follow rule 3, which places a recruiter for that team in Finance, people & workplace.
- Data and research. Work that produces, acquires, licenses or curates data belongs in Data, including procurement specifically for training data. Work that produces a trained model or findings about training belongs in Research, while general procurement remains in Finance, people & workplace.
- Market research and product marketing. Both belong in Go-to-market.
- Customer-facing products and services. These roles follow the product or service they provide, so a security product manager belongs in Product & platform and support for advertisers belongs in Customer support.
- Boilerplate. We instruct the model to disregard company and team mission statements, benefits, pay and equal-opportunity text when deciding the classification.
Labels over time
When a lab changes a posting’s title, department or advert text, we ask the model to classify the revised posting. It may assign a different label. We use that label in the daily counts from the date we first observe the change, and keep the earlier label for earlier dates. Changes to the location or link do not affect the label.
When we update the taxonomy or the classification instructions, and when a change of language model warrants it, we reclassify the full history so that every posting is labelled the same way. Earlier counts can change as a result.
As of September 2026, roughly half of postings had been revised at least once, most of them small edits to the text. About 3% of postings changed label across their revisions. In some cases, the model assigned different sub-categories to near-identical descriptions, so a change in classification may reflect variation in the model’s judgement rather than a change in the role or the lab’s hiring priorities.
Confidence
Alongside each classification, we ask the model to rate its confidence in the label it has chosen. Our instructions specify high confidence when the title and responsibilities clearly point to the same sub-category, and medium confidence when the choice requires the department or a closer reading of the advert. We ask it to use low confidence when two sub-categories remain plausible and it has to make a judgement between them. The ratings therefore express the model’s assessment of its choice, rather than a measured probability that the classification is correct.
The confidence ratings for postings open on Oct. 3, 2026 were distributed as follows:
| Lab | High | Medium | Low | Open postings |
|---|---|---|---|---|
| Anthropic | 66% (423) | 30% (190) | 4% (28) | 641 |
| OpenAI | 62% (514) | 32% (267) | 6% (49) | 830 |
| Both labs | 64% (937) | 31% (457) | 5% (77) | 1471 |
Geography
Location sources
We take each posting’s locations from the job board’s location field. If the location field and the advert text disagree, we use the location field. Anthropic’s Greenhouse board gives locations as free text. OpenAI’s Ashby board lists a primary location and any secondary locations separately.
In a separate step from role classification, we ask a language model to map each location to a country and city. We instruct it to use the location field wherever that field names a place. If the field is blank or names no place, we ask it to use locations explicitly stated in the title or the first 1,500 characters of the advert. We record the source used for each location in the downloads.
In September 2026, we reviewed the latest text of 3,307 postings and compared the locations in the advert text with those in the location field. They differed in 200 cases (6%). Most differences involved adding or removing a US city. Only 23 postings (0.7%) implied a different country.
Location labels and counts
We ask the model to use a consistent English name for each city. For example, it records both “NYC” and “New York City, NY” as “New York”. Where a location is marked remote or does not name a city, we ask it to use one of three labels:
| Label | When it applies |
|---|---|
| Remote | Remote work within a named country, state or province. This label applies whether or not the posting also names a city. |
| Unspecified | A country, state or province is named, but no city is given and the location is not marked remote. |
| Unmapped | No country can be determined. |
When a posting lists both cities and a remote option, we count it under each city and under Remote. Remote therefore includes all postings that allow remote work within the country.
We count each posting once per distinct country and city listed. Geographic totals can therefore exceed the number of postings.
The chart shows the six countries with the most postings separately and groups the rest under Other. Downloads retain individual country names. In the city view, Unspecified locations are also grouped under Other.
When a lab changes a posting’s location, we update the counts from the date we first observe the change. Earlier counts may also change if we revise our location mapping rules and apply them to the archive.