# How the AI Job Search Framework Optimizes Token Usage in LLM Workflows > Discover how the AI Job Search Framework optimizes token usage. Learn about inline draft reviews, single-pass verification, and lazy evaluation to cut LLM costs without sacrificing quality. - Repository: [Mads Lorentzen/ai-job-search](https://github.com/MadsLorentzen/ai-job-search) - Tags: performance - Published: 2026-09-03 --- **The AI Job Search Framework minimizes token consumption by using inline draft reviews, single-pass verification, and lazy evaluation of expensive steps, eliminating redundant LLM calls while maintaining output quality.** The MadsLorentzen/ai-job-search repository implements a token-efficient architecture designed to run cost-effectively on Claude Code and comparable LLM services. By restructuring traditional multi-step workflows into consolidated, context-aware operations, the framework reduces redundant model invocations without sacrificing the quality of generated job application materials. ## Workflow Architecture Optimizations ### Inline Draft Review Eliminates Context Re-reading The framework's reviewer agent receives draft documents inline rather than re-reading the full job posting and CV. This design eliminates a second full-context LLM call that would otherwise be required to refresh the model's memory of the source materials. In [`.claude/commands/apply.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/.claude/commands/apply.md), the drafter creates the CV and cover letter in a single call, then passes these drafts directly to the reviewer. As documented in [`README.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/README.md) (line 258), the reviewer works with the inline content rather than requesting the original context again, cutting token usage by approximately half for the review phase. ### Single Verification Pass Consolidates Quality Checks After document generation, the framework runs a unified "verification checklist" that validates PDF rendering, ATS friendliness, and formatting in one operation. This consolidation avoids the multiple back-and-forth LLM calls typical of sequential validation pipelines. According to the source code in [`README.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/README.md) (line 258), this single-pass approach ensures that validation steps like checking PDF integrity and ATS compatibility execute as one atomic operation rather than separate model invocations. ## Resource Management Strategies ### Compile-and-Inspect Trade-off Prevents Rework The workflow includes an explicit compile-and-inspect phase where LaTeX/Typst templates render to PDF before final delivery. While this consumes tokens for layout rendering, it prevents broken PDFs from reaching users. As implemented in the core workflow, catching formatting errors during generation eliminates the need for additional LLM remediation cycles that would otherwise consume more tokens than the initial compile step. This upstream validation acts as a circuit breaker against expensive downstream corrections. ### Environment-Based Token Handling Reduces Prompt Complexity Portal-specific API tokens are never baked into the repository or passed via CLI arguments. Instead, each job-portal skill reads its required token from environment variables (`_API_TOKEN`). This policy, defined in [`.claude/commands/add-portal.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/.claude/commands/add-portal.md), eliminates the need for extra LLM prompts that would otherwise be required to embed or retrieve credentials during execution. The [`tools/security_guards.py`](https://github.com/MadsLorentzen/ai-job-search/blob/main/tools/security_guards.py) module enforces this isolation, ensuring tokens remain outside the context window entirely. ## Batch Processing and Lazy Evaluation ### Parallel Scoring with Shared Token Budget The `/rank` command batches the scoring of newly scraped postings using parallel agents. Each posting receives a single fit assessment against the framework's criteria, with results aggregated before any further LLM interaction. As shown in [`.claude/commands/rank.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/.claude/commands/rank.md), this approach ensures that identical data is not repeatedly processed through the model. The parallel execution shares a single token budget across all postings in the batch, maximizing efficiency during the evaluation phase. Portal-specific data fetching occurs through `.agents/skills/*/cli/*.js` scripts that operate without LLM involvement, keeping token use constrained to the scoring logic alone. ### Lazy Evaluation of Expensive Operations Steps that consume significant token resources—such as deep company research and interview mock-ups—are only triggered on demand via `/interview` and `/upskill` commands. The core pipeline (`/setup → /scrape → /apply`) remains lean, consuming only the minimal necessary tokens to evaluate fit, generate drafts, and perform verification. This lazy evaluation pattern, evident in the command structure under `.claude/commands/`, prevents token expenditure on speculative operations. Users invoke heavy-weight analysis only when explicitly needed, keeping the default workflow cost-effective. ## Practical Implementation Examples The following commands demonstrate the framework's token-optimized workflow: ```bash # Core workflow – minimal token usage claude # start Claude Code /setup # one-time profile creation (single LLM call) ``` ```bash # Scrape jobs – token use limited to initial queries /scrape # parallel portal skills fetch listings (no LLM involvement) ``` ```bash # Apply – token-efficient drafting and verification /apply https://jobindex.dk/job/1234567 # 1️⃣ Draft CV & cover letter (drafter LLM call) # 2️⃣ Single verification checklist (one LLM call) # 3️⃣ Reviewer receives drafts inline (no extra LLM call) ``` ```bash # Optional heavy-weight steps – invoked only when needed /interview # runs interview-prep LLM calls on demand /upskill # performs gap analysis after core flow completion ``` ## Summary - **Inline document review** eliminates second-pass context loading by passing drafts directly between agents rather than re-reading source materials - **Single verification pass** consolidates PDF, ATS, and formatting checks into one LLM invocation instead of sequential validation calls - **Compile-and-inspect phase** consumes upfront tokens to prevent costly remediation cycles for broken PDF outputs - **Environment variable isolation** keeps API tokens out of prompts and context windows, reducing per-request token counts - **Parallel batch scoring** processes multiple job postings under a shared token budget without redundant model calls - **Lazy evaluation** reserves expensive operations like interview prep and gap analysis for explicit on-demand invocation only ## Frequently Asked Questions ### How does the framework avoid duplicating context in the review process? The reviewer agent receives draft CVs and cover letters inline rather than re-reading the original job posting and CV. According to the source code in [`README.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/README.md) (line 258), this design eliminates a second full-context LLM call that would otherwise be required to refresh the model's memory of the source materials. ### Why does the framework include a PDF compilation step if it uses tokens? The compile-and-inspect phase consumes tokens for LaTeX/Typst rendering but acts as a circuit breaker against broken outputs. Catching formatting errors during generation prevents expensive remediation cycles where the LLM would need to iteratively fix PDF issues, resulting in lower total token consumption for valid final outputs. ### How does token optimization affect the quality of generated applications? The framework maintains quality through consolidated verification rather than repeated checking. By running a single comprehensive checklist that validates PDF integrity, ATS compatibility, and content accuracy in one pass, the system achieves thorough quality assurance without the token overhead of sequential validation calls. ### Where are API tokens stored to minimize prompt complexity? Portal-specific API tokens are read exclusively from environment variables (`_API_TOKEN`) as defined in [`.claude/commands/add-portal.md`](https://github.com/MadsLorentzen/ai-job-search/blob/main/.claude/commands/add-portal.md). This environment-only policy eliminates the need for LLM prompts to handle credential embedding or retrieval, keeping tokens entirely outside the context window and reducing per-request token counts.