geekflare.com

A large language model (LLM) is a neural network trained to predict the next token in a sequence, and it generates text by repeating that prediction one token at a time. Under the hood, the text you type is split into tokens, converted into vectors (embeddings), and passed through a stack of transformer layers where an attention mechanism lets each token weigh the others. The final layer scores every possible next token, and one is selected. This explanation fits anyone who wants a working mental model of the pipeline rather than a math-heavy derivation; AnimatedLLM (animatedllm.github.io) is built specifically to visualize these internal steps.

The core components

The vocabulary is fixed, so every input and output is expressed in terms of tokens the model already knows.

From text to prediction, step by step

1. Tokenize. Input text is split into tokens. A word may become one token or several subword pieces.
2. Embed. Each token maps to a vector. Position information is added so the model knows order.
3. Pass through transformer layers. Each layer applies attention (tokens exchange information) and a feed-forward network (each position is transformed).
4. Produce logits. The final representation is projected onto the vocabulary, giving a score for every possible next token.
5. Select a token. The highest score wins under greedy decoding; sampling methods can pick lower-ranked tokens for variety.
6. Append and repeat. The chosen token is added to the sequence, and the loop runs again to produce the next one.

The expected result at each loop is a single new token; a full response is just this loop repeated.

How attention works, in plain terms

Attention answers: "for this token, which other tokens matter right now?" Each token produces a query, and every token produces a key and a value. The query is compared against all keys to get weights, and the values are combined using those weights. So a pronoun can gather information from the noun it refers to, and a verb can look back at its subject.

This is why context length matters: attention can only weigh tokens inside the window it is given. Multi-head attention runs several of these weightings in parallel so different relationships can be tracked at once.

Training vs. inference

These are the same architecture used in two different modes:

• Training: the model sees text with the next token known, predicts it, measures the error, and adjusts weights across many examples. This is where knowledge and language patterns are learned.
• Inference: weights are frozen. The model only predicts forward, token by token, with no learning. This is what happens when you use a chat model.

A useful intuition: training is studying with an answer key; inference is answering without one.

Building intuition with interactive visualizations

Reading the steps is not the same as seeing them. AnimatedLLM is an interactive resource whose stated purpose is to help you understand how large language models work under the hood. Use it to watch tokens become vectors, follow attention weights between positions, and trace how a prediction is produced. For example, if you want to see why a model completes "The cat sat on the ___" with "mat," step through the attention view to observe which earlier tokens the final position is weighting most heavily.

Common sticking points

• Tokens are not words. A single word can be multiple tokens, which is why models sometimes miscount letters.
• Embeddings are not meanings you can read off. They are learned coordinates; similarity is geometric, not definitional.
• Attention is not memory. It operates within the current context window, not a persistent store.
• One token at a time. Fluency comes from repetition, not from generating a whole sentence in one pass.

If you want to go from "I've heard of transformers" to "I can trace the pipeline," work through the tokenize → embed → attend → score → select loop once, then use an interactive demo to watch each stage on real text.

RAG (Retrieval-Augmented Generation) is a pattern where you retrieve relevant chunks of your own documents and pass them to an LLM as context, so the model answers from your data instead of its training memory. You can build a working document Q&A stack entirely from free-tier tools: a free LLM API for generation, an open embedding model, and a local or free-tier vector store. This guide covers the mechanism, the components, and a minimal build path — plus where these pipelines usually break.

The core mechanism in one pass

A plain LLM call sends your question and nothing else. A RAG call does two things first:

1. Retrieve — search your document collection for the passages most semantically similar to the question.
2. Augment — insert those passages into the prompt as context.

The model then generates an answer grounded in the retrieved text. This is why RAG is often described as "giving the model an open-book exam" rather than testing what it memorized.

RAG vs. fine-tuning vs. plain prompting

For document Q&A over a knowledge base that changes, RAG is usually the right first move. Fine-tuning teaches how to respond; RAG supplies what to respond with.

The components of a minimal RAG pipeline

Every RAG stack, free or paid, has the same six stages. The free-tool directory at freeaitoolslist.vercel.app organizes its RAG Stack category (12 tools) around exactly these pieces.

1. Document loading

Pull raw text out of your sources — PDFs, Markdown, HTML, Notion exports, database rows. This is usually a small script, not a service.

2. Chunking

Split documents into passages small enough to embed and retrieve precisely. Typical starting point: 300–800 tokens per chunk with some overlap (e.g., 10–20%) so sentences aren't cut mid-thought.

3. Embedding

Convert each chunk into a vector using an embedding model. Open-weight embedding models can run locally for free; hosted embedding endpoints are also common.

4. Vector store

Store the vectors plus their source text and metadata. Options range from an in-process library (no server) to a hosted free-tier vector database. The directory lists vector database as a tracked category.

5. Retrieval

At query time, embed the question the same way and find the top-k nearest chunks. This is the step that most determines answer quality.

6. Generation

Send the retrieved chunks plus the question to an LLM. Free-tier LLM APIs from the directory's LLM APIs category (20 tools) fit here — for example:

• OpenRouter — unified API across 29 free models, 20 RPM and 50 requests/day (1,000/day with $10+ credits), no credit card required.
• Groq — 1,000–14,400 requests/day depending on model, no credit card required.
• Google AI Studio — free Gemini API, roughly 250 requests/day on Tier 1 for most models, up to 1,500 RPD for Gemini 3 Flash.
• Cerebras — 1.5M tokens/day, 30 req/min, 8,192 context.

Check each provider's current limits before committing, since free tiers change.

A minimal build path

Here's the shortest route from a folder of documents to a working Q&A loop. The exact libraries are your choice; the sequence is what matters.

1. Load your documents into plain text and keep a source field on each one.
2. Chunk each document into ~500-token passages with overlap. Store {text, source, chunk_id}.
3. Embed every chunk with an embedding model and write the vectors into your vector store alongside the metadata.
4. Query: embed the user's question, retrieve the top 3–5 chunks by similarity.
5. Prompt: build a message like "Answer using only the context below. If the answer isn't present, say so. Context: … Question: …"
6. Generate with a free-tier LLM API and return the answer plus the source chunks so the user can verify.

Verify it works: ask a question whose answer exists verbatim in one document, and a second question whose answer does not exist anywhere. A correct build answers the first with the right source and declines the second instead of inventing one.

Where free RAG stacks break

• Chunking too coarse or too fine. Big chunks dilute the signal and blow your context budget; tiny chunks lose the surrounding meaning. Tune this first when answers feel vague.
• Poor retrieval recall. If the right passage never appears in the top-k, no LLM can fix it. Try more chunks, a better embedding model, or hybrid keyword + vector search.
• Context overflow. Free tiers have hard context caps — Cerebras lists 8,192 context, for instance. Stuffing too many chunks will truncate or error.
• Hallucination despite context. The model answers from memory when retrieval is weak. An explicit "answer only from context" instruction plus returning sources reduces this.
• Stale index. If documents change, re-embed the changed chunks. A RAG system is only as current as its vector store.

Choosing your free components

Match tools to your constraints rather than chasing the biggest name:

• Data must stay local → local embedding model + in-process vector store + a locally run open-weight model.
• Fastest to prototype → hosted free-tier embedding + a free-tier vector database + a free LLM API like Groq or Google AI Studio.
• Highest request volume → compare daily request and token caps across providers (Groq's 1,000–14,400 req/day and Cerebras's 1.5M tokens/day are the generous end of the directory's listings).

The directory's Recommended Stacks section groups these into ready-made combinations if you'd rather not assemble each piece yourself.

OpenAPI-generated API documentation is reference documentation that is produced automatically from an OpenAPI description file rather than written by hand. You write (or generate) a machine-readable specification of your API — endpoints, parameters, request bodies, responses, schemas, and auth — and a documentation tool reads that file and renders a browsable, often interactive reference site. The spec becomes the single source of truth; the docs become a build artifact.

This differs from manually written docs in one fundamental way: with hand-written docs, the prose is the source of truth and the API is described separately. With spec-driven docs, the API description is the source, and every page, table, and code sample is derived from it.

How the workflow actually runs

A typical spec-driven documentation pipeline has five stages:

1. Author or generate the spec. You either write an OpenAPI document by hand (YAML or JSON), or generate it from code annotations, framework metadata, or a design-first editor. Design-first means the spec is written before implementation; code-first means it is extracted from existing code.
2. Validate and lint. The spec is checked against the OpenAPI schema and against style rules — consistent naming, required descriptions, no undocumented 4xx responses, no orphaned schemas.
3. Bundle and transform. Multi-file specs are combined, $ref pointers are resolved, and the document is optionally split into per-tag or per-version outputs.
4. Render. A documentation tool converts the spec into HTML: an endpoint list, a sidebar of operations, parameter tables, response schemas, and a "try it" console.
5. Publish and version. The rendered site is deployed, and each API version gets its own snapshot so consumers can read docs matching the version they call.

Steps 2 through 5 are usually automated in CI. If the spec fails validation, the docs build fails — which is the point.

Spec-driven vs. hand-written documentation

The practical conclusion most teams reach: generate the reference, write the guides. Reference material is repetitive and mechanical, which is exactly what generation is good at. Conceptual explanations, migration notes, and tutorials carry judgment that a spec cannot express.

What you get out of the box

Generated reference pages commonly include:

• An operation list grouped by tag or path, with HTTP method and path.
• Parameter tables showing name, location (path, query, header, cookie), type, required flag, and description.
• Request and response schemas rendered as expandable trees, including nested objects and arrays.
• Authentication details pulled from the securitySchemes section.
• Interactive request consoles that let a reader send a real call from the browser.
• Generated code samples in several languages, derived from the same schemas.
• Multiple output formats, such as a static site, a single HTML file, or a mock server.

Because all of these come from one document, changing a field name in the spec updates the parameter table, the schema tree, and every code sample at once.

Where spec-driven documentation breaks down

Generation is not free. The trade-offs are real:

Spec quality becomes documentation quality. A field with no description produces a table row with an empty cell. A vague summary produces a vague heading. Tools can enforce presence of descriptions via linting, but they cannot enforce that the description is useful.

Customization has limits. If you need a page that does not map to an OpenAPI concept — a conceptual overview, a pricing explanation, a comparison of two endpoints — you write it outside the generator and link to it.

Not everything is expressible. Webhooks, streaming responses, long-polling behavior, and complex multi-step flows are awkward or impossible to describe fully in OpenAPI. Those need prose.

The spec can go stale. If the spec is maintained separately from the implementation, it drifts just like hand-written docs. The mitigation is to generate the spec from code, or to test the implementation against the spec in CI.

Interactive consoles need care. A "try it" button that hits a production API with real credentials is a security and rate-limit problem. Point it at a sandbox, or disable it.

Deciding whether to adopt it

Adopt spec-driven reference documentation if most of these are true:

• Your API has more than a handful of endpoints, or changes frequently.
• You ship client SDKs or code samples in more than one language.
• Multiple teams consume the API and need a consistent, always-current reference.
• You already have, or are willing to maintain, an OpenAPI description.

Stay with hand-written docs, or a hybrid, if:

• Your API is small and stable, and the reference fits on one page.
• Your documentation is mostly conceptual and contains little endpoint-level detail.
• You cannot commit to keeping the spec in sync with the implementation.

A reasonable middle path: generate the reference from the spec, and hand-write the getting-started guide, authentication walkthrough, and error-handling page. Link the two directions so readers can move from concept to endpoint and back.

A minimal starting checklist

1. Produce one valid OpenAPI document for a single API version.
2. Add a linter with rules for descriptions, operation IDs, and error responses.
3. Wire the docs build into CI so a failing spec fails the build.
4. Render the reference and review it as a reader, not as the author.
5. Write the two or three conceptual pages the generator cannot produce.
6. Version the published docs alongside the API version.

The core idea is simple: describe the API once, in a format both machines and humans can read, and let the reference documentation fall out of that description. Everything else — tooling, hosting, interactivity — is a detail on top of that decision.

A screenshot API is a hosted service that accepts a URL and returns an image of that page, rendered in a real browser on the provider's infrastructure. You use one instead of taking manual screenshots when you need captures at scale, on a schedule, or from pages that only render correctly with JavaScript. Geekflare's Screenshot API, for example, returns full-page or viewport captures of any URL, with JavaScript rendering and ads and cookie banners blocked. The trade-off: you send the URL to a third party, and you depend on their rendering environment rather than your own browser.

What a screenshot API actually does

You send an HTTP request containing the target URL. The provider loads that URL in a headless browser, waits for the page to render, and returns an image file or a link to one. You never install a browser, manage proxies, or handle bot detection yourself — the provider does that on its side.

That division of labor is the whole point. A local script using a headless browser works fine for a handful of pages, but breaks down when you need many captures, consistent rendering across regions, or resilience against anti-bot measures.

When to use one instead of manual screenshots

Manual screenshots are fine for one-off, human-judged captures. A screenshot API earns its place when any of these apply:

• Volume or repetition — capturing the same pages daily, or hundreds of URLs in a batch.
• Dynamic content — pages where prices, dashboards, or feeds only appear after JavaScript runs.
• Clean output — you want the page without cookie consent modals or ad overlays covering the content.
• Automation — the capture feeds a pipeline, report, or agent rather than a person's clipboard.
• Consistency — every capture uses the same viewport, scale, and rendering rules.

If none of those apply, a manual screenshot is simpler and costs nothing.

Full-page vs viewport captures

The two modes answer different questions, and picking the wrong one is a common source of wasted effort.

Geekflare's example shows a 1440×900 viewport at @2x scale as a full-page capture, which illustrates that viewport size and capture mode are separate settings: the viewport defines the rendering window, and full-page extends the capture beyond it. Decide based on what the image is for — a layout comparison wants a viewport shot; an archive of page content wants full page.

Why JavaScript rendering and banner blocking matter

Two features separate a useful capture from a misleading one.

JavaScript rendering. Many pages ship an empty HTML shell and fill it in with JavaScript. A capture that doesn't execute scripts returns a blank or partial page. Because the API renders in a real browser, the returned image reflects the page as a visitor would see it, including dynamically loaded content.

Ad and cookie-banner blocking. Consent modals and ad overlays frequently sit on top of the content you actually want. Geekflare's Screenshot API blocks both, so the capture shows the page rather than the interruptions layered over it. If you've ever screenshotted a page and gotten a cookie dialog across the middle, this is the fix.

Making a first request

The mechanics are the same across most screenshot APIs: authenticate, send the URL, specify the output. Using the Geekflare playground as the concrete example:

1. Get an API key. The free plan includes 500 credits a month, and no card is required to start. Failed requests cost nothing.
2. Send a request to the screenshot endpoint with the target URL as a parameter. The playground exposes every endpoint and parameter, plus saved requests, so you can build and test the call before wiring it into code.
3. Choose the capture options — full page or viewport, viewport dimensions, and scale.
4. Read the response. You get back the rendered image; the same API suite also returns Markdown, JSON, and PDF for other endpoints, so confirm you're hitting the screenshot endpoint and not a scraping one.

The playground is the fastest way to see the exact request shape for your account, since it lists every parameter rather than making you guess.

Common failure points and how to troubleshoot

• Blank or partial captures. Usually means JavaScript didn't finish before the shot was taken. Check whether the provider waits for rendering, and whether the page loads content after a delay or a user interaction.
• Blocked requests. Some sites actively refuse automated browsers. A provider that handles proxies and anti-bot measures reduces this, but no service guarantees every URL.
• Wrong content in the frame. If a cookie banner or ad still appears, banner blocking may not cover that specific consent framework — verify the feature is enabled for the request.
• Unexpected dimensions. A capture that looks cropped or stretched usually traces back to a viewport or scale mismatch. Set both explicitly rather than relying on defaults.
• Cost surprises. Credits are consumed per request, so a large batch of full-page captures at high scale adds up faster than viewport shots. Track usage against your plan.

Choosing between a screenshot API and doing it yourself

Run a headless browser yourself if you have few pages, full control over the environment, and no objection to maintaining proxies and bot-handling code. Use a hosted screenshot API when volume, dynamic rendering, or clean output matter more than control — and accept that the URL leaves your infrastructure. For teams already using the same provider for scraping and search, keeping screenshots in the same suite means one key, one billing line, and consistent rendering across all three.

Web data, in the context of AI agents and developers, means content pulled from a live URL and returned in a form a machine can use directly — LLM-ready Markdown, JSON, HTML, a screenshot, or PDF — rather than raw HTML you still have to clean. You get it through hosted APIs instead of building your own scraping stack: you send a URL, the provider handles proxies, headless browsers, JavaScript rendering, CAPTCHAs, and anti-bot handling, and returns usable output. This matters most when you're feeding RAG pipelines, agents, or automation and don't want to maintain browser infrastructure. Geekflare's suite is one example, offering a free plan with 500 credits a month and no card to start, with failed requests costing nothing.

Why raw HTML isn't web data

A raw page is mostly noise for an AI system: navigation, cookie banners, ads, tracking scripts, and layout markup. If you feed that into an LLM or a vector store, you burn tokens on boilerplate and degrade retrieval quality.

"Web data" is the cleaned, structured result. The Geekflare scraping API, for instance, returns markdown-llm format that keeps links and headings while stripping boilerplate — exactly the shape you want for LLMs and RAG. Other formats include HTML, JSON, screenshots, and PDF.

The API types you'll actually use

Different tasks need different endpoints. The suite groups them like this:

Search results each link back to their source, which matters if you need to cite or verify what an agent used.

A minimal request

The pattern is the same across stacks: POST a URL, name the format, get data back. From the Geekflare playground:

curl POST /webscraping
{
  "url": "stripe.com",
  "format": ["markdown-llm"]
}

Input: a URL and a desired format. Action: the API fetches, renders, and parses the page. Expected result: clean Markdown with headings and links preserved and boilerplate removed. The same suite exposes Python SDK, cURL/REST, and MCP integrations (Cursor, Claude, Codex) plus n8n workflows, so you can wire it into an agent or automation without writing a fetcher.

What building it yourself actually costs

The page frames this directly: "What an in-house scraping stack actually costs." The hidden work isn't the first request — it's everything that breaks at scale:

• Proxy management — rotating IPs so you don't get blocked
• Headless browsers — running and patching Chrome for JS-heavy pages
• CAPTCHA and anti-bot handling — the part that fails silently and often
• Parsing and cleaning — turning HTML into Markdown/JSON you can trust
• Maintenance — sites change; your selectors and renderers rot

A hosted API folds all of that into one call. The trade-off is per-request cost and provider dependency versus engineering time and ongoing upkeep. If your volume is low or your targets are stable, DIY can be fine; if you're feeding agents or RAG at any real scale, the maintenance burden usually decides it.

Common failure points to plan for

• JavaScript-rendered content — pages that load data client-side return empty without a real browser. Confirm your API renders JS.
• CAPTCHAs and anti-bot walls — these are the most common silent failures; built-in handling is the main reason to use a hosted service.
• Proxy and rate limits — without rotation you get throttled or blocked.
• Format mismatch — asking for HTML when you need LLM-ready Markdown means you still clean it yourself.
• Geo differences — the same page can look different from another country; the suite supports viewing a page as it appears from another region, which matters for localized content and pricing.

Getting started

Open the playground to see every endpoint and parameter with saved requests — free with 500 credits a month. Grab a free API key, run one scrape against a URL you know, and check whether the returned Markdown is clean enough to drop straight into your pipeline. If it is, you've replaced a scraping stack with a request.