career-ops: An Open-Source, Local-First AI Job Search Agent That Judges Before It Applies

What it is: an open-source AI job search agent on the candidate's side

career-ops is an open-source project on GitHub. Its tagline is "The open-source AI job search agent." The author is santifer (Santiago Fernandez de Valderrama Aparicio). The origin story is plain. He spent months sending CVs into silence. Instead of sending more, he built the filter he needed. The README gives his own numbers: 740 listings evaluated, 68 applications, 12 interviews, 1 offer. He says he was the first user of the tool, and that he open-sourced it after he got the job. According to the README, he left that job six months later, and the team now keeps building career-ops so that others can land theirs.

The workflow is compressed into one idea. You paste a job. On your own machine, the tool tells you two things: whether the listing is still open, and whether it fits you. It then tailors your CV and drafts your answers to the application questions. The last step belongs to a person: "You press Submit." That design choice matters, and we discuss it below.

Core design: judge first, act second

Most AI job tools solve an output problem. They generate CVs faster and submit applications in bulk. career-ops starts from the opposite end. It solves a judgment problem first. The README opens with a simple contrast: companies use AI to filter candidates, and the author gave candidates AI to choose companies. The first thing the tool returns is not a document. It is a verdict. If the verdict is "do not apply," you just got your night back. If it comes back with a plan, you know what to do next.

The demo animation shows the author's own search: a list of scored listings, a red count of the ones marked "do not apply," and then a full evaluation report. The interface in the demo is in Spanish, which hints at the multilingual use of the project. The README itself exists in 17 languages, including English, Spanish, German, French, Japanese, Korean, and both Simplified and Traditional Chinese.

How it works, and what can be verified

A boundary first. The background text we have is the opening of the README. It does not describe internals such as scoring dimensions, prompt structure, how listings are fetched, or how data is stored. So this section covers only what the README states, and the engineering meaning that follows from those statements. First, local-first operation. The README says: "Open source. Local. In the AI CLI you already use." The tool runs inside the AI command-line client you already have, not in a hosted service. The entry point is one command: npx @santifer/career-ops init. That implies distribution as an npm package that sets up the workflow in your local environment. Sensitive personal material, such as your CV, your application history, and the evaluation verdicts, does not need to live on a third-party platform.

Second, replaceable models. The README links a document called RUNNING_ON_A_BUDGET and says free and local models are included. For a job seeker who does not want to pay for every evaluation, this lowers the barrier. The tradeoff is clear as well. Small local models are usually weaker than cloud flagship models at long-document judgment and at the quality of wording. The quality of an evaluation will follow the model you choose. Third, the "is it still open" check. Many applicants waste hours on listings that are already gone. Putting "still open" and "fits me" into one evaluation is a practical idea. The README does not say how the check is done, so we do not guess. Fourth, a human in the loop. The tool drafts answers and tailors the CV, but a person submits. The README turns this into a six-line manifesto: apply better to fewer; signal over volume; evidence over keywords; a human decides; local-first; dignity on both sides of the table.

Key numbers and how to read them

The headline numbers are 740, 68, 12, and 1. The funnel is telling. The author evaluated more than ten times as many listings as he applied to, and he applied to roughly five or six times as many as the interviews he got. Most listings were rejected at the evaluation stage, and only a few were sent. That is the reverse of a spray-and-pray strategy.

Readers should stay careful. This is one person's search, not a controlled experiment. The README gives no conversion rate for the same person without the tool. It cannot rule out the effect of industry, seniority, region, or timing. So it is a strong anecdote, not proof of effect. The README also gives no latency or cost benchmark. Cost depends on the model you choose to run.

The community signals are stronger. The project is marked as the number one repository of the day on Trendshift, it is featured on Product Hunt, and it is supported by the Vercel Open Source Program. The README also cites coverage by WIRED and Business Insider. A file named HIRED.md counts public "got hired" stories with a live badge, and each card is a public issue you can open and read. These are the project's own adoption claims. They can be checked on the linked pages. We did not verify each one.

Impact on developers and the wider market

For developers, career-ops is a useful case study. It turns a very personal task into a distributable workflow that runs inside a general AI command-line tool, instead of a standalone app. The benefit of this path is reuse of the model access you already have, a low distribution cost, and easy community modification.

For the job market, it is an attempt to balance power. Employers have used algorithms to filter résumés for years. Candidates had templates and keyword stuffing. career-ops gives candidates an evaluation tool and openly opposes volume. It is notable that "do not apply" is treated as a core product value. Most tools measure success by the number of applications sent.

Limits and risks

First, evaluation quality depends on the model. Scores, fit judgments, and the "do not apply" verdict are model output and can be wrong. Treat them as advice, not as a ruling. Second, privacy. Local-first lowers the risk of data leaving your machine. But if you use a cloud model, the content of your CV still goes to that provider. A local model avoids this, with a quality tradeoff.

Third, the truth of drafted content. Automatic tailoring must stay faithful to your real experience. The README says "evidence over keywords," which is the right direction. But the tool cannot verify facts for you. The person who presses Submit owns the result. Fourth, the evidence base is narrow. Public material is mostly the author's account and community stories. There is no independent, reproducible evaluation.

Where it may go next

The README structure points to a few directions: more languages for docs and interface, a growing library of hired stories, and a community built around the manifesto. The manifesto page carries a signature counter, which suggests an effort to turn a job search practice into a shared norm.

The most useful next step would be a public benchmark. For example, compare several models on a fixed set of listings for "apply / do not apply" decisions, and report agreement with human judgment.

Conclusion

The value of career-ops is not that it helps you apply more. It helps you apply less, and better.

It puts judgment before action, leaves the decision to a person, and keeps data on your machine. The evidence is mostly one author's case and community stories, so read it with care. But the idea is clear and the cost to try it is low: one npx command and one job you were about to apply to tonight.