The Complete Jina API Guide (2026)

You've probably seen the name "Jina AI" come up repeatedly in RAG (Retrieval-Augmented Generation) technical discussions over the past few months — but it's not the kind of toy that goes viral overnight and floods social media. By GitHub star count alone, the Jina Reader open-source repo sits at roughly 11,000 stars — not even a rounding error next to Firecrawl's 130,000+. But over the past ten months, two things happened that are real enough to put "how do you actually choose a RAG retrieval layer" back on the table: on October 9, 2025, Elastic — the Nasdaq-listed search infrastructure company behind Elasticsearch — completed a full acquisition of Jina AI; and after the acquisition, the Jina team didn't slow down its model-release cadence, shipping two new generations of Embeddings models in February and May 2026.

This piece tries to lay all of that out honestly: why Jina API is worth paying attention to right now, where its real strengths and weaknesses actually are versus Firecrawl / Tavily / Exa / Diffbot, and — using a pipeline we actually tested — how to turn a pile of web pages into a genuinely queryable domain knowledge graph. One thing up front: Jina's product line has no "one-click knowledge graph generation" API — that's closer to what Diffbot offers. The tutorial in this piece walks through a pipeline you have to assemble yourself, where Jina handles the crawling and vectorization layers.

1. What Jina AI Is, and What Happened After the Elastic Acquisition

Jina AI (jina.ai) doesn't do chat completion, and it isn't competing with GPT/Claude on that main battlefield. Instead it goes deep on the three-piece "retrieval layer" that's most critical — and most often overlooked — in RAG engineering: Embeddings, Reranker, and Reader (turning web pages into clean text), plus a family of related products built around the same system: Search (web search), DeepSearch, Classifier, and Segmenter. All of these products share the same API key and the same token pool — that's the core design choice that sets it apart from "single-point embedding providers" like Voyage AI, which only does embeddings. This site's existing Jina AI API review covers pricing, the free-tier quota, and other details; this piece focuses on two things: why it's worth watching, and how to use it to build a knowledge graph.

On October 9, 2025, Elastic (the parent company of Elasticsearch, Nasdaq: ESTC) completed a full acquisition of Jina AI, with its official press release describing Jina AI as "a leader in frontier models for multimodal, multilingual search." Jina AI's founder and former CEO, Han Xiao, became Elastic's VP of AI after the acquisition. Elastic has explicitly stated it will continue Jina AI's prior practice of open-sourcing models on Hugging Face and continuing to publish academic research — meaning Jina's Embeddings/Reranker/Reader product line currently continues to operate independently as part of Elastic's "Search AI Platform" strategy, rather than being shelved or cut.

Model iteration didn't slow down after the acquisition — if anything, the pace stayed brisk:

• February 18, 2026: Released the jina-embeddings-v5-text series (small/nano tiers) — officially reported MTEB English v2 average scores of 71.7 for the 677M-parameter small tier and 71.0 for the 239M-parameter nano tier, the highest score at the time among multilingual embedding models under 1B parameters, supporting 119+ languages with up to 32K tokens of context
• May 11, 2026: Elastic officially released jina-embeddings-v5-omni, the first multimodal model to share the same vector space as v5-text — text, images, video, and audio can all be encoded into the same vector space, meaning users who already built an index with v5-text can drop in the omni model to start feeding images/video/audio into the same vector store without rebuilding the index

Together, these two things form this piece's core argument for "why it's worth watching now" — not social-media virality, but a real corporate acquisition and integration, plus a SOTA model-release cadence that kept going after the deal closed. The next section separates this out from the question of "is it actually a big deal" and discusses it honestly.

2. Why Jina API Is Worth Watching Right Now: Three Verifiable Reasons

Let's be upfront: measured by GitHub stars or social-media buzz, Jina Reader is not the loudest player in this space right now. We specifically verified this while researching this piece — Firecrawl's open-source repo has passed 130,000 stars, putting it in GitHub's site-wide top-100 territory, while Jina Reader's own open-source repo sits at roughly 11,000–12,000 stars, an order of magnitude behind. So if "Jina API is suddenly everywhere" is read literally as "exploded and drowned out its competitors' buzz in a short window," that claim doesn't hold up — and this piece is choosing to say so honestly rather than dodge it for the sake of a catchier headline.

But ask a more precise question instead — "is Jina API still worth a RAG developer's time right now" — and the answer is yes, for three reasons that hold up under scrutiny:

1. Being acquired by — and getting continued investment from — a bigger infrastructure player is a more solid signal than viral spread

An independently-run RAG retrieval-layer startup getting fully acquired by a search-infrastructure public company the size of Elastic is itself a form of validation — it signals that Jina's tech stack was judged "worth integrating into a core enterprise search platform capability," not an isolated developer toy. Elastic explicitly committed to continuing the open-source release cadence after the deal closed, and the founder moved into the acquirer's VP of AI role rather than cashing out and leaving — together these details point to a relatively stable signal: for the foreseeable future at least, Jina's API product line will likely keep being maintained and invested in, rather than getting cut or shelved. This is "enterprise infrastructure acquisition and integration" attention, a completely different kind of heat than "went viral overnight" — but for a developer making a technology-selection decision, the former is actually the more decision-worthy signal.

2. Model releases didn't slow down after the acquisition, and they came with verifiable benchmark results

Many companies go through a quiet product-integration lull after being acquired, but that hasn't happened on the Jina/Elastic line so far — v5-text (February 2026) and v5-omni (May 2026) shipped less than three months apart, and v5-text landed a specific, verifiable result — "highest MTEB score among multilingual embedding models under 1B parameters" (cross-confirmed by the official announcement and the Hugging Face model card) — while v5-omni is a rare technical attempt at sharing one vector space across text/image/video/audio. This suggests the acquisition didn't slow product iteration down; if anything, Elastic's resources may have made the cadence more stable.

3. The structural differentiation itself hasn't gone stale — it was always there, it just now has a stronger endorsement behind it

Several of Jina's long-standing technical selling points still hold up in 2026, and the combination is still uncommon among comparable products: Embeddings + Reranker + Reader sharing the same API key and the same free token pool (10M tokens, no credit card required), plus Embeddings support for Late Chunking (encoding an entire long document in one pass to preserve cross-chunk context, then splitting out chunk-level vectors) and Matryoshka representation learning (vectors can be truncated to lower dimensions on demand to save storage). None of these are brand-new in 2026, but the combination is still rare in the "all-in-one retrieval layer" niche — section 3 compares these point-by-point against competitors, without glossing over where Jina now clearly lags.

3. Jina API vs. the Competition: Strengths, Weaknesses, and an Honest Comparison

By mid-2026, the "URL/web page → LLM-ready clean content + vectorization" niche has become a crowded market with at least three tiers and a dozen-plus players — direct competitors include Firecrawl, Exa, Tavily, Diffbot, and Spider.cloud, while general-purpose scraping services (ScrapingBee, ScraperAPI) have also added "output Markdown for LLMs" features of their own. Below is a verified side-by-side comparison.

Where Jina's advantages actually hold up

• The only provider that bundles embedding + reranking + crawling into a single account system: Firecrawl/Tavily/Exa/Diffbot are all separate billing systems — even if you use several of them together, you still manage quotas and bills separately for each. Jina covers all three with the same key and the same 10M free token pool; for teams already using Jina Embeddings/Reranker, Reader is "one more convenient endpoint," not "another account to open"
• A minimal URL-prefix call pattern: r.jina.ai/<target URL>, a GET request with no JSON body and no SDK required — section 4 tests this live, and even anonymous calls work end-to-end, which is lighter-weight than most competitors (which require a POST with a JSON body plus a key in the header)
• No evidence found so far of a stripped-down self-hosted version: Firecrawl explicitly acknowledges that its self-hosted version is missing the proprietary cloud anti-bot engine (Fire-engine), Agent endpoints, and the browser sandbox; this research didn't turn up any official Jina statement about feature-stripping in its self-hosted version — that doesn't prove "Jina is necessarily more complete" (there's no equivalent item-by-item feature list for a direct comparison), but at least no counter-example turned up

Honestly acknowledged: where competitors are clearly ahead

• The open-source ecosystem is an order of magnitude smaller: Firecrawl's 130K+ stars vs. Jina Reader's ~11K — community activity and third-party integrations (LangChain/LlamaIndex ecosystem presence) are likely stronger for Firecrawl as a result
• Per-page/per-request billing is easier to estimate than per-token billing: most competitors — Firecrawl, Tavily, ScrapingBee — bill "a fixed credit per page" or "a fixed price per request," while Jina's per-token billing is harder to estimate in advance for long-page scenarios; Jina's official pricing page returned a 404 when we checked for this piece, so treat the current logged-in Dashboard page as the source of truth for exact rates rather than assuming a fixed number
• Search-plus-extraction-in-one-call products are eating into the need for a standalone Reader call in the first place: Tavily Extract, Exa Contents, and Brave's LLM Context endpoint can all "search first, then extract on demand" in a single call. Jina does have a standalone Search API (s.jina.ai), but Search and Reader are two separate endpoints — it hasn't merged "retrieve + extract" into a single response. On top of that, Google's Gemini API URL Context tool went fully GA in 2026, letting the model read a URL directly — that's a long-term structural pressure on the entire "standalone Reader API" category, Jina Reader included
• Diffbot is the product that actually earns the words "knowledge graph": Diffbot has a dedicated Knowledge Graph product and a Natural Language API — a capability Jina has none of — though Diffbot is positioned more toward enterprise, starting at $299/month, a clearly higher price barrier. That's also why this piece's title doesn't claim "generate a knowledge graph with one click via the Jina API" — the next section honestly explains what it actually takes

One-sentence summary: if you're already using Jina Embeddings/Reranker as your retrieval layer, Reader is a near-zero-marginal-cost add-on; if you need a mature open-source ecosystem, predictable per-page pricing, or search-plus-extraction in one call, Firecrawl/Tavily genuinely deserve consideration on their respective strengths; if you need an out-of-the-box knowledge graph product instead of assembling your own pipeline, Diffbot is closer to what you're after, but you'll need to accept a higher price barrier.

4. Quick Start: Authentication, Rate Limits, and the Simplest Possible Call

4.1 Getting an API Key

Generate one with a single click at jina.ai/?sui=apikey — no credit card required. Every new key comes with a 10M-token free quota, shared across the Embeddings / Reranker / Reader token pool — if a batch Embeddings job burns through the quota early, Reader gets hit too. The official site notes the free quota is non-commercial use only; treat the current Dashboard page as the source of truth for exact terms.

4.2 Authentication

All APIs use standard Bearer token authentication:

Authorization: Bearer $JINA_API_KEY

4.3 Rate Limits

4.4 The Simplest Possible Call: Reader, No Key Needed

Reader's most intuitive design: append the target URL directly after https://r.jina.ai/, send a GET request, no headers, no API key required. We tested this live for this piece (July 19, 2026):

curl "https://r.jina.ai/https://en.wikipedia.org/wiki/Retrieval-augmented_generation"

Actual result: HTTP 200, took about 2.85 seconds, response header x-usage-tokens: 7486 (tokens consumed), x-ratelimit-limit: 20, 20;w=60 — that header directly confirms the documented "20 anonymous calls per 60 seconds" rate limit, verifiable without needing a key at all. Beginning of the returned content (a genuine excerpt, nothing fabricated):

Title: Retrieval-augmented generation

URL Source: https://en.wikipedia.org/wiki/Retrieval-augmented_generation

Published Time: 2023-11-05T13:19:20Z

Markdown Content:
From Wikipedia, the free encyclopedia

**Retrieval-augmented generation** (**RAG**) is a technique that enables
large language models (LLMs) to retrieve and incorporate new information
from external data sources. With RAG, LLMs first refer to a specified
set of documents, then respond to user queries...

The returned content follows a fixed three-part structure: Title / URL Source / Markdown Content, and the page we fetched this time also included a Published Time field (not every page has one — it depends on whether the target page itself carries publish-date metadata). The tutorial in section 5 builds directly on top of this real fetch.

5. Tutorial: Build Your Own Domain Knowledge Graph with the Jina API

5.1 Overall Pipeline Design

A five-step flow — it's important to keep each step's responsibility boundary clear:

Domain document URL list
   │
   ▼
Step 1  Jina Reader batch fetch          → Clean Markdown text
   │
   ▼
Step 2  LLM extracts entities/relations  → Structured JSON (entities + relations)
   │        (Jina doesn't provide this layer — bring your own LLM)
   ▼
Step 3  Jina Embeddings vectorize entities → Used for semantic dedup/merging similar entities
   │
   ▼
Step 4  Assemble into a graph structure  → JSON nodes/edges / NetworkX / Neo4j
   │
   ▼
Step 5  Query / subgraph retrieval       → Fed into the downstream RAG prompt context

5.2 Step 1: Batch-Fetch Domain Documents with Jina Reader (Live-Tested)

We used two real Wikipedia pages to simulate a "small domain corpus" — Retrieval-augmented generation and Vector database. In practice, swap DOMAIN_URLS for real documents from your own domain (a company wiki, product docs, or paper pages all work):

import requests

DOMAIN_URLS = [
    "https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
    "https://en.wikipedia.org/wiki/Vector_database",
    # swap in real document URLs from your own domain
]

JINA_API_KEY = None  # works anonymously too (20 RPM limit); use your own key in production (500 RPM on the free tier)

def fetch_clean_text(url: str) -> dict:
    headers = {"X-Return-Format": "markdown"}
    if JINA_API_KEY:
        headers["Authorization"] = f"Bearer {JINA_API_KEY}"
    resp = requests.get(f"https://r.jina.ai/{url}", headers=headers, timeout=60)
    resp.raise_for_status()
    return {
        "url": url,
        "tokens_used": resp.headers.get("x-usage-tokens"),
        "text": resp.text,
    }

corpus = [fetch_clean_text(u) for u in DOMAIN_URLS]
for doc in corpus:
    print(doc["url"], "→", doc["tokens_used"], "tokens")

Actual results from this test (July 19, 2026, anonymous calls, no key used): fetching the Retrieval-augmented generation page returned HTTP 200 in about 2.85 seconds and consumed 7,486 tokens, with 28,779 bytes of decompressed body text; fetching the Vector database page consumed 11,581 tokens, with 41,572 bytes of body text. Both calls returned x-ratelimit-limit: 20, 20;w=60, confirming the anonymous rate limit of 20 calls per 60 seconds. These aren't numbers copied from documentation — they're real numbers this piece actually produced.

5.3 Step 2: Extract Entities and Relations with an LLM

This is the one link in the pipeline Jina doesn't provide — you have to bring your own LLM. The example below uses the OpenAI-SDK-compatible call format — base_url can point at any OpenAI-protocol-compatible model or relay, you're not locked into any one provider:

from openai import OpenAI

# Swap base_url for whatever model/relay you're using, and model for the matching model name
# This site has reviewed several solid value picks (GLM-5.2, DeepSeek, etc.) — see "Further Reading" at the end
client = OpenAI(api_key="your-key", base_url="https://your-relay-or-official-endpoint/v1")

EXTRACTION_PROMPT = """You are a knowledge-graph extraction engine. Given a passage of text, extract its entities and the relations between them, and output strictly in the following JSON format with no extra text:

{
  "entities": [
    {"id": "unique_id", "name": "entity name", "type": "PERSON|ORG|CONCEPT|TECHNOLOGY|EVENT", "description": "one-sentence description"}
  ],
  "relations": [
    {"source": "entity_id", "target": "entity_id", "relation": "relation description, as a verb phrase"}
  ]
}

Text:
{chunk}
"""

def extract_entities_relations(chunk: str, model: str = "your-model-name") -> dict:
    import json
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": EXTRACTION_PROMPT.format(chunk=chunk)}],
        response_format={"type": "json_object"},
        temperature=0
    )
    return json.loads(response.choices[0].message.content)

Full disclosure: this task's environment didn't have an LLM API key available, so the "example output" below isn't the result of an actual model call — it's a hand-written illustration based on the real content fetched in section 5.2, meant to show the expected output shape:

{
  "entities": [
    {"id": "e1", "name": "Retrieval-Augmented Generation", "type": "TECHNOLOGY", "description": "A technique that lets an LLM retrieve external documents before generating a response"},
    {"id": "e2", "name": "Large Language Model", "type": "TECHNOLOGY", "description": "A large language model"},
    {"id": "e3", "name": "Vector Database", "type": "TECHNOLOGY", "description": "A database for storing and retrieving vector embeddings"},
    {"id": "e4", "name": "AI Hallucination", "type": "CONCEPT", "description": "The phenomenon of a model generating false content"}
  ],
  "relations": [
    {"source": "e1", "target": "e2", "relation": "augments"},
    {"source": "e1", "target": "e3", "relation": "depends on"},
    {"source": "e1", "target": "e4", "relation": "mitigates"}
  ]
}

5.4 Step 3: Vectorize Entities with Jina Embeddings for Semantic Dedup and Linking

Entities extracted from multiple documents often turn out to be "the same thing, worded differently" (e.g., "RAG" and "Retrieval-Augmented Generation"). Vectorizing each entity's name + description with Embeddings and computing cosine similarity lets you merge them into the same node. The code below is likewise written from the official API docs and wasn't actually called this time (it needs a real key):

import requests

def embed_texts(texts: list, jina_api_key: str, task: str = "retrieval.passage") -> list:
    resp = requests.post(
        "https://api.jina.ai/v1/embeddings",
        headers={
            "Authorization": f"Bearer {jina_api_key}",
            "Content-Type": "application/json"
        },
        json={
            "model": "jina-embeddings-v5-text-small",
            "input": texts,
            "task": task,
            "normalized": True
        }
    )
    resp.raise_for_status()
    return [d["embedding"] for d in resp.json()["data"]]

entity_texts = [f"{e['name']}: {e['description']}" for e in entities]
entity_vectors = embed_texts(entity_texts, JINA_API_KEY)

import numpy as np

def cosine_sim(a, b):
    a, b = np.array(a), np.array(b)
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

def merge_similar_entities(entities, vectors, threshold: float = 0.88):
    """Entities above the similarity threshold are treated as the same node and merged
    (e.g. "RAG" and "Retrieval-Augmented Generation" from different documents)"""
    merged, used = [], set()
    for i, e in enumerate(entities):
        if i in used:
            continue
        group = [i]
        for j in range(i + 1, len(entities)):
            if j not in used and cosine_sim(vectors[i], vectors[j]) >= threshold:
                group.append(j)
                used.add(j)
        merged.append({**entities[i], "aliases": [entities[k]["name"] for k in group[1:]]})
    return merged

5.5 Step 4: Assemble the Graph Structure

The simplest form is a JSON node/edge structure — this step doesn't depend on any external API, it's pure data wrangling, and you can run it directly:

import json

def build_graph(all_entities, all_relations):
    nodes = [
        {"id": e["id"], "label": e["name"], "type": e["type"], "description": e["description"]}
        for e in all_entities
    ]
    edges = [
        {"source": r["source"], "target": r["target"], "label": r["relation"]}
        for r in all_relations
    ]
    return {"nodes": nodes, "edges": edges}

graph = build_graph(merged_entities, all_relations)
with open("domain_knowledge_graph.json", "w", encoding="utf-8") as f:
    json.dump(graph, f, ensure_ascii=False, indent=2)

print(f"Nodes: {len(graph['nodes'])}, Edges: {len(graph['edges'])}")

If the data grows and you need graph-query capability, swap in NetworkX (pure in-memory, good for small/medium scale):

import networkx as nx

G = nx.DiGraph()
for n in graph["nodes"]:
    G.add_node(n["id"], **n)
for e in graph["edges"]:
    G.add_edge(e["source"], e["target"], label=e["label"])

list(G.successors("e1"))  # query all one-hop neighbors of an entity

For persistent storage, concurrent multi-user queries, or a larger graph, switch to Neo4j:

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def load_into_neo4j(graph):
    with driver.session() as session:
        for n in graph["nodes"]:
            session.run(
                "MERGE (e:Entity {id: $id}) SET e.name = $name, e.type = $type",
                id=n["id"], name=n["label"], type=n["type"]
            )
        for e in graph["edges"]:
            session.run(
                "MATCH (a:Entity {id: $source}), (b:Entity {id: $target}) "
                "MERGE (a)-[r:RELATION {label: $label}]->(b)",
                source=e["source"], target=e["target"], label=e["label"]
            )

5.6 Step 5: Query the Subgraph and Feed It to Downstream RAG

The most common use of a knowledge graph once it's built: when answering a user question, first use vector retrieval to locate relevant entities, then expand N hops along the edges to their neighbors, assemble the subgraph relations into structured context, and feed that alongside your normal vector-retrieval results into the LLM:

def query_graph(question_vector, graph, entity_vectors, top_k: int = 3):
    sims = [
        (node["id"], cosine_sim(question_vector, vec))
        for node, vec in zip(graph["nodes"], entity_vectors)
    ]
    top_nodes = sorted(sims, key=lambda x: -x[1])[:top_k]

    context_lines = []
    for node_id, _ in top_nodes:
        neighbors = [e for e in graph["edges"] if e["source"] == node_id or e["target"] == node_id]
        for e in neighbors:
            context_lines.append(f"{e['source']} --{e['label']}--> {e['target']}")
    return "\n".join(context_lines)

# Append the returned structured relation text to your final prompt, as extra context alongside normal vector-retrieval results

5.7 Summary: Who's Responsible for Each Layer in This Pipeline

6. Common Pitfalls and Access from Mainland China

• All three products share the same token pool: a batch Embeddings job burning through the free quota early also affects Reader/Reranker — do capacity planning against the total, not per-product
• The free quota is non-commercial: if you're shipping to production/a commercial project, the officially-listed 10M free tokens may not apply from a compliance standpoint — treat the current Dashboard terms as authoritative
• Reader's X-Timeout caps out at 180 seconds: fetching heavily JS-rendered or anti-bot-protected pages can time out easily — pair it with X-Engine: browser to force the browser engine
• Use the Batch Embeddings API for large-scale vectorization, not the sync endpoint: POST /v1/batch/embeddings submits a job, then you poll status and download JSONL results — better suited than the synchronous /v1/embeddings for "vectorize your entire knowledge base in one go" scenarios
• Mainland China access needs a proxy: the Jina official GitHub repo jina-ai/reader has an issue titled "Jina Reader and Search are blocked," which shows at least some users report r.jina.ai/s.jina.ai being unreachable on mainland networks — but no official statement or long-term status confirmation was found on this. Mainland teams can route through a local proxy, or reach it indirectly via an AI API relay like Chutes that already has Jina's embedding endpoint wired up, in an OpenAI-SDK-compatible format

7. FAQ

Q: Can the Jina API really "generate a knowledge graph with one click"?

A: No. Jina's product line has no such feature — that's closer to what Diffbot's Knowledge Graph product is positioned for. Section 5 of this piece shows a pipeline you have to assemble yourself: Jina handles crawling and vectorization, entity/relation extraction requires your own LLM, and graph storage and querying also need you to pick a tool (JSON/NetworkX/Neo4j).

Q: Since Jina was acquired by Elastic, could the API suddenly get more expensive or shut down?

A: As of this piece's research (July 2026), the official line is that it continues to operate independently and keeps the open-source release cadence going; third-party review sites also confirm the Reader/Embeddings/Reranker APIs are still being actively maintained, with no major changes to the pricing structure. That said, any acquired product line carries some risk of a long-term direction change — keep an eye on official announcements, and don't treat pricing at any single point in time as a permanent commitment.

Q: Which parts of this tutorial can I run without an API key?

A: Step 1 of section 5 (fetching with Jina Reader) can be run entirely anonymously, at a rate limit of 20 calls/60 seconds — the live-test numbers in this piece came from anonymous calls. Step 3 (vectorizing with Jina Embeddings) and Step 2 (LLM extraction) each need their own API key.

Q: Is the free 10M-token quota enough to build a small domain knowledge graph?

A: Based on this piece's live-test numbers, two medium-length Wikipedia pages (roughly 30–40KB of body text each) together consumed about 19,000 tokens — the 10M quota could theoretically cover a few hundred pages of that size for Reader fetching alone. But that quota is shared across Embeddings/Reranker/Reader, so if you're also vectorizing a large number of entities with Embeddings, the number of pages you can actually cover drops noticeably. Run a small-scale validation on the free quota first, then decide whether you need to upgrade to a paid key.

Q: Do I have to use Jina Embeddings for entity vectorization? Can I swap in a different embedding model?

A: Absolutely. The vectorization logic in section 5's Step 3 (merging entities by similarity) isn't tightly coupled to any particular embedding model — any Embeddings API that outputs dense vectors can be swapped in. The main reason to pick Jina is that it shares the same account system as Reader — if you're already using Jina Reader to fetch, using Jina Embeddings for vectorization too saves you managing an extra account.

8. Conclusion