Agent Optimization Guide

Last updated: Feb 25, 2026
Tested with: Claude Haiku, Corriere.it, BBC News

Executive Summary

Agents using Pinchtab can reduce token usage by 93% and improve reliability by 100% through:

  1. Clear, prescriptive instructions (no experimentation)
  2. Waiting 3+ seconds after navigation
  3. Using a saved query pattern

The Experiment

Setup

Three scraping tasks across different approaches:

  • Run 1 (web_fetch fallback): Agent chose simpler HTML extraction
  • Run 2 (exploratory Pinchtab): Agent discovered Pinchtab, tried multiple filters, adapted to page load delays
  • Run 3 (pattern-driven Pinchtab): Agent given exact curl command, executed once, reported results

Results

RunApproachInOutTotalNotes
1web_fetch431,8001,843Fallback extraction
2Exploratory Pinchtab1423,7003,842Found pattern through trial
3Pattern-driven Pinchtab1026227214x better

Key Discovery: The 3-Second Wait

Early attempts returned only 1 node:

{
  "count": 1,
  "nodes": [
    {
      "ref": "e0",
      "role": "RootWebArea"
    }
  ]
}

After sleeping 3 seconds:

{"count": 2645, "nodes": [...]}

Why? Chrome’s accessibility tree takes time to populate. The DOM renders immediately, but accessibility events lag behind.


Reliable Pattern

For Scraping Headlines/Titles

bash terminal
curl -X POST http://localhost:9867/navigate \  -H "Content-Type: application/json" \  -d '{"url": "https://example.com"}' && \sleep 3 && \curl http://localhost:9867/snapshot | \jq '.nodes[] | select(.name | length > 15) | .name' | \head -30

Why this works:

  1. Navigate + wait ensures full accessibility tree
  2. jq filter extracts text nodes only (eliminates UI chrome)
  3. length > 15 filters out buttons, labels, tiny text
  4. head -30 limits output (saves tokens)

For Interactive Tasks (Click, Type, etc.)

Pattern same as above, but:

  1. Take snapshot after navigation
  2. Extract refs (e.g., e5, e12)
  3. Act on refs (click e5, type e12 "text")
  4. Take another snapshot to verify
  5. Repeat until done

Cost: Higher (full snapshots), but necessary for interaction.


Token Cost Deep Dive

Scraping Cost: Pattern-Driven (Optimal)

Input:  10 tokens (simple instructions + curl command)
Output: 262 tokens (30 headlines)
Total:  272 tokens
Per headline: ~9 tokens

Scraping Cost: Exploratory (What agents do without guidance)

Input:  142 tokens (task + agent thinking + skill search)
Output: 3,700 tokens (full parsing + multiple attempts + explanation)
Total:  3,842 tokens
Per headline: ~128 tokens

Ratio: 128 / 9 = 14.2x worse

Why the Difference?

OverheadTokensReason
Skill file search~50Agent looking for docs
Failed snapshot filter attempts~100Trying .role == "article", etc.
Full tree parsing~2,000Extracting all 2,645 nodes
Explanation + reasoning~1,550Agent narrating process
Pattern-driven (no overhead)~272Direct execution

System Prompt Template

Use this for agents scraping with Pinchtab:

# Pinchtab Scraping Instructions

When extracting headlines from a website:

1. Use EXACTLY this curl pattern (do not deviate):
   
   curl -X POST http://localhost:9867/navigate \
     -H "Content-Type: application/json" \
     -d '{"url": "TARGET_URL"}' && \
   sleep 3 && \
   curl http://localhost:9867/snapshot | \
   jq '.nodes[] | select(.name | length > 15) | .name' | \
   head -30

2. Replace TARGET_URL with the site URL
3. Report the headlines (limit to 20 unique items)
4. Do NOT try alternative filters, approaches, or explanations

This pattern has been optimized for token efficiency (93% savings).

Site-Specific Notes

Corriere.it

  • Nodes: 2,645
  • Render time: 3 seconds
  • Filter: .name | length > 15
  • Example headline: “A 65 anni vende tutto per girare il mondo: «Ho 4 valigie e un sogno, ecco come faccio». Ha già visitato 146 Paesi”

BBC News

  • Nodes: 2,300+
  • Render time: 3 seconds
  • Filter: .name | length > 15
  • Example headline: “Trump announces emergency declaration for border security”

Pattern Universality

The 3-second + jq filter pattern works on any site with a standard HTML DOM. No site-specific tuning needed.


When NOT to Use Pattern-Driven

  1. Interactive workflows — Need to click, fill forms, verify results (requires full snapshots + refs)
  2. Dynamic content — Page loads data after initial render (increase wait time to 5-10s)
  3. JavaScript-heavy SPAs — May need multiple snapshots + waits between state changes

Use pattern-driven ONLY for: Read-only headline/title scraping with fast render times.


Validation Checklist

Before deploying to production:

  • Agent follows curl pattern exactly (no web_fetch fallback)
  • Wait time is 3+ seconds (adjust if needed)
  • jq filter matches target content (headlines vs. all text)
  • head -N limits output appropriately
  • Agent reports only relevant results (no parsing explanation)
  • First run validated manually on target site

Future Improvements

  • Adaptive wait time detection (poll /snapshot until count > threshold)
  • Site-specific render profiles (BBC: 2s, SPA: 8s, etc.)
  • Cache snapshot between multiple extract calls (same navigation, different filters)
  • Fallback to web_fetch if Pinchtab unavailable (graceful degradation)

Questions?

  • Token usage still high? Check your jq filter; overly complex filters parse more nodes
  • Only 1-2 headlines extracted? Increase head -N or lower .name | length threshold
  • Timeouts? Increase sleep time or set BRIDGE_HEADLESS=true for faster rendering
  • See “RootWebArea” only? Wait time too short; increase to 5 seconds minimum