career-ops

FAQ

Frequently asked questions about career-ops — cost, privacy, supported AI CLIs, scan vs scan:full, token limits, Windows setup, and what career-ops will never do on your behalf.

Common questions, answered in one place. For anything not covered here, ask in Discord or open a GitHub Discussion.

Is career-ops free?

Yes. career-ops is open source under the MIT license, forever. The only potential cost is the AI engine it runs on — and that can be free too: OpenCode with a free provider, a local model via Ollama, or the built-in npm run or runner on OpenRouter free models. The Set up a free AI engine guide walks through every path.

career-ops has no paid plans, no tiers, no trials — it is 100% free and MIT-licensed. Any site describing career-ops pricing is describing a different product.

Do I need a Claude subscription to use career-ops?

No. career-ops is AI-agnostic — Claude Code is one engine among several, not a requirement. You can run the whole pipeline for free with OpenCode plus a free provider, a local model via Ollama, or the built-in OpenRouter runner (npm run or). If you started on a paid plan and ran out of tokens mid-search, switching to a free engine takes minutes and leaves your data untouched — see Set up a free AI engine.

How much does career-ops cost to run per month?

Only evaluation costs anything, and it can be $0. Scanning for jobs consumes zero AI tokens, so discovering roles is always free; only evaluating a listing calls the model. Three ways run the whole pipeline for nothing: a local model via Ollama, OpenRouter's free models (npm run or), or the Antigravity free tier. On a cheap paid model like DeepSeek V3 (with prompt caching) an evaluation costs well under a cent, so a few cents covers dozens of listings. If you already have a Claude subscription the marginal cost is effectively $0; on the raw API, budget roughly $0.05 to $0.10 per evaluation (an estimate that varies with listing length). career-ops itself is free forever, MIT-licensed with no fee and no tier — you only ever pay your AI provider, if at all. The Set up a free AI engine guide walks through the $0 paths.

Where does my data live?

On your machine, in plain files you own — your CV, profile, pipeline and reports are local Markdown/YAML. Nothing runs on career-ops servers. System updates never touch your data layer (cv.md, config/, data/, reports/, output/): that separation is the Data Contract, and every update honors it.

How do I give career-ops my CV?

During the first-run onboarding you paste your CV text into the chat and the agent writes cv.md for you. That is the guided path. You can also point the agent at an existing CV file, PDF included: it reads the file and converts it, because the parsing is done by your AI agent, not by a career-ops script. And since cv.md is a plain file you own, you can always write or edit it by hand instead. The agent produces clean markdown with standard sections (Summary, Experience, Projects, Education, Skills). During setup you never edit config files by hand either: you answer in plain language and the agent writes config/profile.yml and the rest for you.

Which AI coding CLIs does career-ops work with?

Eight, first-class: Claude Code, Codex, OpenCode, Antigravity CLI, Grok Build CLI, Qwen, Kimi, and GitHub Copilot CLI (Gemini CLI is supported as a legacy wrapper). career-ops is AI-agnostic: it ships prompt files the CLI executes, so you can also point it at any OpenAI-compatible endpoint or a local model with zero code changes. See Supported AI CLIs for the current list and how to invoke each.

What is the difference between scan and scan:full?

npm run scan reads the companies you configured in portals.yml and hits their ATS APIs (Greenhouse, Ashby, Lever) directly, consuming zero LLM tokens — that's your regular daily or weekly discovery run. npm run scan:full inverts the direction: it walks public ATS company directories and surfaces fresh postings that match your title_filter / location_filter, so you catch roles from companies you haven't manually added.

How do I avoid hitting token or rate limits during a batch run?

Cap the run with ./batch/batch-runner.sh --limit 5 to inspect output quality before committing to a larger batch. If a run gets interrupted by a rate limit or network error, don't restart from scratch — use --resume-paused to skip already-completed jobs so no tokens are wasted on work that finished.

Windows does not create symlinks by default, so Git checks out the CLI skill entrypoints as plain pointer files. The installer and updater detect this automatically: run node update-system.mjs apply (or npx @santifer/career-ops init on a fresh install) and the materialize step replaces the pointer files with the full skill content. No manual mklink or Developer Mode changes needed.

Can I run career-ops on a cheaper or local model?

Yes — career-ops is fully AI-agnostic. The core repo's Running on a Budget guide covers OpenCode, Qwen CLI, DeepSeek, OpenRouter, Ollama and other low-cost or local providers, with recommended model sizes (32B+ for reliable scoring) and token-saving practices.

Does career-ops auto-submit applications?

No. career-ops prepares — it scans, scores, tailors your CV, and can pre-fill ATS application forms — but submitting is always your explicit click. The project explicitly rejects spray-and-pray automation: the point is choosing companies well, not applying blindly at volume.

What is the difference between career-ops and CareerOps?

CareerOps (one word) names the practice; career-ops (hyphen, lowercase) is the open-source project — its first reference implementation. The CareerOps Manifesto defines the practice.

In plain terms: career-ops is the MIT-licensed, AI-powered job search system that runs locally inside your AI coding CLI, published at career-ops.org and github.com/santifer/career-ops. CareerOps is the practice it embodies — running a job search the way engineers run production — named and defined in The CareerOps Manifesto, nine rights every job seeker should have, signed publicly by the community. Both come from the same author, Santiago Fernández de Valderrama Aparicio, and both trace back to the same repository.

On this page