- Measure token consumption per pipeline stage before changing anything, and account for how often each stage runs - the expensive-per-record stage is often not the expensive one.
- Most of the available saving is on the input side: strip scripts and page chrome, select only the relevant DOM subtree, deduplicate, and cache unchanged inputs before touching prompt wording.
- Re-measure after each individual change and watch the failure rate alongside the token count - over-pruning removes context the model needed, and retries cost more than the saving.
You have an extraction pipeline with a model in it, and you are keeping it that way.
Maybe the pages vary too much for rules. Maybe the task genuinely needs interpretation. Maybe rewriting the pipeline is not this quarter’s work. Whatever the reason, the model stays - the question is how much you are paying it to read things it does not need.
That question has a good answer. Most pipelines that send page content to a model are sending mostly noise, and the input side is where the savings are: navigation, scripts, styles, cookie banners, footers, and repeated chrome that carry no information relevant to the fields you want.
What this guide covers
Reducing token consumption in a pipeline that keeps its LLM. Finding which stage is actually costing you, cutting input size before the model sees it, batching and deduplicating, and measuring each change so you know whether it worked.
What it does not cover: removing the model. If your pages are structurally predictable and you are open to replacing AI extraction entirely, that is a bigger saving than anything here - build a deterministic extraction workflow without an LLM covers it, and choosing an extraction architecture helps you decide whether that applies to you.
Measure before you optimise
Optimising a pipeline you have not measured is guesswork, and the guesses are usually wrong - teams tune prompt wording while whole HTML documents go into context untouched.
Instrument each stage that calls a model and record, per record processed: input tokens, output tokens, and how often the stage runs. That last one matters more than it seems. A stage costing four times as much per record but running on a twentieth of the volume is not your problem.
| Stage | Input tokens | Output tokens | Runs per 100 records | Relative cost |
|---|---|---|---|---|
| Page content into context | ||||
| Field extraction call | ||||
| Retry or exception path | ||||
| Classification or scoring | ||||
| Generation or summarisation |
Fill this in from your own pipeline before changing anything, then re-measure after each change individually. Changing three things at once tells you the total moved but not which change did it - and one of the three may have made things worse.
Keep the baseline. Token consumption drifts as sources change and prompts get edited, and without a reference point you will not notice until a bill does the telling.
Why sending web pages to AI models is expensive
When you paste a web page into ChatGPT or Claude and ask it to extract specific data - names, job titles, company details, pricing, contact information - you are sending the entire page as part of your prompt.
The page in full is charged as input; the fields you actually wanted are a small part of it. How lopsided that ratio is depends entirely on the site, so measure it on your own pages rather than assuming a figure - the instrumentation section below covers how.
This creates several compounding problems.
Raw pages contain enormous amounts of noise
A typical web page is mostly navigation menus, footer links, cookie banners, sidebar widgets, tracking scripts, boilerplate disclaimers, and metadata that has nothing to do with the data you want. You pay for every token of that noise, even when none of it is useful.
A LinkedIn company page contains the company’s name, industry, size, website, and description - but it also contains dozens of links, navigation elements, suggested connection panels, ad slots, and UI text. If you paste that page into an AI to extract the company details, you are paying for the full context of the page, not just the fields you care about.
You have to repeat the process for every page
If you need to collect data across 100 pages, you run the same extraction request 100 times. Each time, you pay the full token cost of the prompt, the page content, and the model’s response. There is no reusable template that amortises the cost across records. Every page is a fresh, expensive operation.
AI extraction is not consistent
Ask the same AI to extract the same data from three similar pages and you will likely get three slightly different formats. Field names vary. Missing values get handled differently. Sometimes the model makes plausible-sounding inferences instead of leaving a field blank. Cleaning and normalising the output requires additional effort - and often additional prompts.
Context windows fill up fast
Large language models have context limits. When you are processing long pages or maintaining extraction context across multiple queries in a single session, those limits constrain what you can do and may force you to split work across sessions, adding friction and cost.
The more efficient approach: extract first, use AI where it actually adds value
The solution is not to stop using AI. It is to stop using AI for the wrong step.
Generative AI models are excellent at:
- Summarising extracted data
- Classifying and scoring records against your ideal customer profile
- Writing personalised outreach based on structured inputs
- Enriching records with analysis that requires judgment
- Synthesising research across multiple sources
They are not efficient at:
- Navigating raw HTML to locate specific fields
- Producing consistent, schema-aligned output across hundreds of pages
- Handling pagination and multi-page extraction
- Returning structured data without hallucinating missing values
The better workflow separates these two jobs. Extract the structured data first, using a tool built for that task. Then send only the clean, relevant data to the AI for analysis, enrichment, or writing.
Instead of sending a whole LinkedIn profile page to an AI and asking it to pull out a name, title, and company, you extract those fields directly from the page first. The structured output is a small fraction of the page it came from. The AI receives clean inputs and does more meaningful work at a lower token cost.
Where Fetchr fits in this workflow
Fetchr is a Chrome extension that extracts structured data from websites by reading the page DOM directly - without sending any content to an AI model.
For LinkedIn profiles, Fetchr automatically extracts: name, headline, job title, current company, company LinkedIn URL, location, education, email, phone, website, and LinkedIn profile URL - whatever is present and visible on the page given your connection status. See the full breakdown of what Fetchr extracts from LinkedIn
For LinkedIn company pages, Fetchr extracts: company name, LinkedIn URL, website, headquarters address, industry, company size, founded year, specialties, and description.
For websites and pages you can access in your browser, where the relevant data is visible in the page, Fetchr’s custom scraper lets you define an extraction template by pointing and clicking. You hover over a repeating element - a directory row, a search result card, an attendee listing - click to lock in the pattern, then click individual fields inside that element to define what to collect. Fetchr generates a reusable template and runs it across all matching rows on the page. If the site paginates, Fetchr handles that too - clicking through pages automatically until it has collected everything. How Fetchr’s browser-based scraper works step by step
The output is structured data: CSV or JSON. Not raw text. Not a summary of the page.
Once extracted, data can sync to the DataFixr platform - where you can create or update contact and company records, review differences before committing any changes, and maintain a consistent, governed dataset across your workflow.
What this changes in practice
Old workflow: Open page - paste content into AI - AI extracts data - clean inconsistent output - use data.
Token cost: the full page, every time, for every page.
New workflow: Open page - Fetchr extracts - structured data - AI analyses, scores, or writes based on clean inputs.
Token cost: only the fields that matter, formatted consistently, ready to use.
The difference compounds at scale. Extracting 100 profiles with Fetchr produces 100 clean structured records. Sending those records to an AI for analysis costs a fraction of what it would cost to have the AI extract and parse each profile from scratch.
What to use AI for after extraction
Extraction is the input layer. AI is most valuable after the inputs are clean and structured.
Once Fetchr has produced a structured dataset, there are genuinely high-value things AI can do with it:
Lead scoring. Given a list of job titles, company sizes, and industries, ask an AI to rank leads by fit against your ICP. This is a reasoning task - exactly what AI is built for. See how to prepare data for AI prospecting tools
Personalisation at scale. Given a job title, company name, and company description, ask an AI to write a personalised first line for each outreach email. The AI is doing synthesis, not extraction.
Categorisation. Given a list of company descriptions, ask an AI to classify them by vertical, use case, or market segment. Clean text in, consistent labels out.
Gap analysis. Ask an AI to identify which records in your dataset are missing key fields, or which entries look suspicious or inconsistent. The AI is analysing structured data, not navigating raw HTML.
Research synthesis. If you have extracted data from multiple sources, ask an AI to identify patterns, contradictions, or common themes across the full dataset.
All of these are tasks where AI genuinely earns its token cost. None of them require sending raw web pages. They work on the structured output that Fetchr already produced.
The input-reduction checklist
Work down this list in order. It is sequenced by typical impact, and the first three usually account for most of the available saving - which is why prompt tuning appears near the bottom rather than the top.
Cut what reaches the model at all
- Strip
<script>,<style>,<noscript>, and comment nodes before anything else - pure overhead, zero information - Remove navigation, headers, footers, cookie banners, and sidebars; these repeat identically on every page you process
- Select only the DOM subtree containing your target fields rather than passing the document
- Convert the remaining HTML to text or a compact structure - tags cost tokens and rarely carry meaning for the task
- Drop fields you are not going to use, even when they come free from the source
Stop paying twice
- Deduplicate records before processing, not after; the same company appearing four times is four times the cost
- Cache results keyed on input content so unchanged pages are not re-processed on every run
- Skip records that already have the field you are about to generate
- Separate deterministic work from interpretation: parse dates, normalise casing, and validate formats in code, then let the model do only what needs judgement
Batch deliberately
- Group similar records into one call rather than one call per record, where the task allows it
- Watch that batching does not inflate output tokens or degrade accuracy enough to cause retries - a batch that fails costs more than the calls it replaced
- Keep batches small enough that one bad record does not invalidate the whole response
Then tune the prompt
- Trim system prompts to what the task requires, but expect modest returns; the system prompt is usually small next to the content
- Send only the fields the specific task needs, not the whole record
- Constrain output length and format - output tokens usually cost more per token than input
- Request structured output rather than prose you will have to parse
Do not let savings become failures
- Validate output after each reduction; over-aggressive pruning removes context the model needed, and the retries cost more than the saving
- Watch the failure rate alongside the token count - a token reduction that pushes more records onto the retry path can cost more than it saves, so compare the two movements before keeping a change
- Re-measure after each individual change
The general principle: the cheapest token is one you never send. Work outward from the input, and stop when the measurements stop moving.
For the architectural question of whether this pipeline should have a model in it at all, see choosing an extraction architecture. Once you have structured output, preparing extracted data before CRM import covers what happens next.
Fetchr is a Chrome extension for structured data extraction from LinkedIn and websites you can access in your browser - without burning AI tokens on raw page content. Sign up to DataFixr above to access the extension.