DEV Community: AI Engine

Content Moderation API: Screen User Uploads Beyond Nudity

AI Engine — Fri, 12 Jun 2026 06:25:10 +0000

The moment your product lets users upload images, profile photos, listing pictures, chat attachments, review photos, you inherit a Trust and Safety problem. Someone will upload something that breaks your policy, and if it reaches other users before you catch it, that is a brand and sometimes a legal incident. Manual review does not scale past a trickle of uploads. A content moderation API screens every image automatically and lets a human handle only the genuinely ambiguous ones.

This builds that flow: one call to score an image across the risk categories, a per-category policy engine that turns scores into an allow / review / block decision, and a concurrent batch pattern for real platform volume. All code is Python and runs against a live API.

Want to test it on your own uploads? Try the content moderation API on a sample image.

Moderation is more than a nudity filter

A lot of "NSFW detection" content treats moderation as one yes/no question about nudity. Real platform policy is broader. Weapons and gore, drug paraphernalia, hate symbols, and gambling promotions all break the rules on most platforms, and none of them are nudity. The API returns labels across a broad set of categories (nudity, suggestive content, violence, visually disturbing imagery, drugs and tobacco, alcohol, gambling, hate symbols, rude gestures), each with a confidence score.

That breadth lets your policy distinguish a weapon from a wine bottle instead of lumping everything into "bad."

Step 1: Score an image

Send an image (file or public URL) and get back the labels the model is confident about. A clean image returns an empty list:

import requests

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "nsfw-detect3.p.rapidapi.com",
}

def moderate(image_path):
    """Return the moderation labels for an image (empty list means clean)."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://nsfw-detect3.p.rapidapi.com/nsfw-detect",
            headers=HEADERS,
            files={"image": f},
        )
    return r.json()["body"]["ModerationLabels"]

Each label has a Name, a Confidence (0 to 100), and a ParentName. Labels are hierarchical and can be a few levels deep (a specific drug label sits under a broader Drugs & Tobacco category). Top-level categories are the ones with an empty ParentName. The reliable way to build a policy is to first see which top-level categories the API actually returns on your content:

labels = moderate("sample_upload.jpg")
categories = [l["Name"] for l in labels if l["ParentName"] == ""]
print(categories)
# ['Gambling']          on a poker photo
# ['Drugs & Tobacco']   on a pills photo
# []                    on a clean photo

Step 2: Turn scores into a policy decision

The labels are not a decision. A wine marketplace allows alcohol; a kids' app blocks it. Your policy lives in a small table that maps each top-level category to an action and a threshold:

# Use the exact Names the API returns for your content (see Step 1).
# A category absent from the table is allowed.
POLICY = {
    "Explicit":                                          {"action": "block",  "threshold": 60},
    "Non-Explicit Nudity of Intimate parts and Kissing": {"action": "block",  "threshold": 60},
    "Violence":                                          {"action": "block",  "threshold": 70},
    "Hate Symbols":                                      {"action": "block",  "threshold": 50},
    "Drugs & Tobacco":                                   {"action": "block",  "threshold": 70},
    "Swimwear or Underwear":                             {"action": "review", "threshold": 60},
    "Gambling":                                          {"action": "review", "threshold": 80},
    # Alcohol is not listed, so it is allowed (e.g. a wine marketplace)
}

def decide(labels):
    """Map moderation labels to a verdict: allow, review, or block."""
    verdict, reasons = "allow", []
    for label in labels:
        if label["ParentName"]:          # match on top-level categories only
            continue
        rule = POLICY.get(label["Name"])
        if not rule or label["Confidence"] < rule["threshold"]:
            continue
        reasons.append(f"{label['Name']} ({label['Confidence']:.0f}%)")
        if rule["action"] == "block":
            verdict = "block"
        elif verdict != "block":
            verdict = "review"
    return verdict, reasons


print(decide(moderate("clean_photo.jpg")))    # ('allow', [])
print(decide(moderate("wine_listing.jpg")))   # ('allow', [])  Alcohol is not in the policy
print(decide(moderate("poker_table.jpg")))    # ('review', ['Gambling (99%)'])

Three ideas make this work at scale. Match on the top-level category (empty ParentName) so a deeply nested label still maps to the right rule. Set thresholds per category. And use three outcomes, not two: block clear violations, allow clean images, and route the uncertain middle to a human.

Curious which categories fire on your content? Run the API on a sample and print the top-level labels.

Step 3: Screen uploads at scale

A live platform does not moderate one image at a time. Screen a batch concurrently and act on each verdict as it lands:

from concurrent.futures import ThreadPoolExecutor, as_completed

def screen(upload):
    """upload: dict with id and local path. Returns the moderation verdict."""
    try:
        verdict, reasons = decide(moderate(upload["path"]))
    except Exception as e:
        # On error, fail safe to review rather than letting content through
        verdict, reasons = "review", [f"moderation error: {e}"]
    return {"id": upload["id"], "verdict": verdict, "reasons": reasons}

def screen_batch(uploads, max_workers=10):
    blocked, review, allowed = [], [], []
    with ThreadPoolExecutor(max_workers=max_workers) as pool:
        futures = [pool.submit(screen, u) for u in uploads]
        for fut in as_completed(futures):
            r = fut.result()
            {"block": blocked, "review": review, "allow": allowed}[r["verdict"]].append(r)
    return blocked, review, allowed

Publish the allowed bucket, hold the blocked bucket, and push the review bucket to your moderation queue. The fail-safe to review on error matters: when the API call fails, you want the image held for a human, not published unchecked.

Honest limits

A moderation API is a strong first line, not the whole system. It scores pixels, not intent, so the same image can be a violation or legitimate news depending on context the model cannot see (that is what the review queue is for). Thresholds are a product decision: strict catches more but annoys real users with false positives. Policy is regional, and images are one surface (text, video, and audio need their own moderation).

Read the full guide with the review-queue pattern and the honest limits on ai-engine.net.

Background Removal at Scale: A High-Volume Pipeline for Ecommerce

AI Engine — Sun, 07 Jun 2026 05:49:56 +0000

You run an online store, a marketplace integration, or a product-data pipeline, and you have thousands of product photos shot against inconsistent backgrounds: vendor warehouses, kitchen tables, studio sweeps, phone snaps. Marketplaces want clean, uniform images. Doing this by hand in Photoshop does not scale past a few dozen SKUs. A background removal API turns it into a batch job you run once and forget.

This walkthrough covers the scaling patterns that matter when you are processing a whole catalog: single calls, concurrent batches, white-background output for marketplace listings, and a retry-safe pipeline. All code is Python and runs against a live API.

Want to see the cutout quality on your own products? Try the Background Removal API on a sample image.

Why backgrounds matter for conversion

Product image quality is not cosmetic. Amazon requires a pure white background (RGB 255, 255, 255) for main listing images. Shopify themes look broken when one product floats on white and the next sits on a gray kitchen counter. Consistent backgrounds make a catalog look professional, and that consistency is part of how shoppers judge whether a store is trustworthy. The problem is that source images almost never arrive consistent, especially when vendors or drop-shippers supply them.

So the real job is not "remove one background." It is "normalize thousands of inconsistent images into one clean look, repeatably, as new products arrive."

The single call

Start with one image to confirm the shape. Install the two packages first (pip install requests tqdm), then:

import requests

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "background-removal-ai.p.rapidapi.com",
}

resp = requests.post(
    "https://background-removal-ai.p.rapidapi.com/remove-background",
    headers={**HEADERS, "Content-Type": "application/json"},
    json={"image_url": "https://example.com/product.jpg"},
)
result = resp.json()
print(result["image_url"])  # URL to the transparent PNG

The response includes the output image_url plus width, height, and size_bytes, which you can store alongside your product records.

White background for marketplace listings

Transparency is great for your own site, but marketplaces usually want a solid white backdrop. Instead of removing the background and then compositing onto white in a second step, use the color-background endpoint to do both at once:

def on_white(image_url):
    """Remove background and composite the product onto solid white."""
    resp = requests.post(
        "https://background-removal-ai.p.rapidapi.com/color-background",
        headers={**HEADERS, "Content-Type": "application/json"},
        json={"image_url": image_url, "bg_color": "255,255,255,255"},
    )
    return resp.json()["image_url"]

The bg_color value is R,G,B,A (each 0 to 255), so 255,255,255,255 is opaque white. Swap it if a channel needs a brand color behind the product.

Run the white-background call on a product photo and check the result before wiring up a batch.

Batch a whole catalog concurrently

A catalog migration is the moment scaling matters. Processing sequentially, 10,000 images at 1.5 seconds each is over 4 hours of wall-clock time. With a concurrency pool, the same job finishes in a fraction of that. Here is a retry-safe batch processor:

import csv
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
from tqdm import tqdm

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "background-removal-ai.p.rapidapi.com",
}
URL = "https://background-removal-ai.p.rapidapi.com/color-background"

def process(sku, image_url, retries=3):
    """Process one product image, retrying on transient errors."""
    for attempt in range(retries):
        try:
            r = requests.post(
                URL,
                headers={**HEADERS, "Content-Type": "application/json"},
                json={"image_url": image_url, "bg_color": "255,255,255,255"},
                timeout=30,
            )
            r.raise_for_status()
            return sku, r.json()["image_url"], None
        except Exception as e:
            if attempt == retries - 1:
                return sku, None, str(e)

# products.csv has columns: sku, image_url
with open("products.csv") as f:
    products = list(csv.DictReader(f))

results, failures = [], []
with ThreadPoolExecutor(max_workers=10) as pool:
    futures = [pool.submit(process, p["sku"], p["image_url"]) for p in products]
    for fut in tqdm(as_completed(futures), total=len(futures), desc="Removing backgrounds"):
        sku, out_url, err = fut.result()
        (failures if err else results).append((sku, err or out_url))

print(f"Processed {len(results)} images, {len(failures)} failed")

The max_workers=10 setting controls concurrency. Tune it to your plan's rate limit: higher means faster but risks throttling. The retry loop absorbs transient network blips so a single failure does not abort a 10,000-image run, and failed SKUs land in a list you can re-run.

Quality control at scale

Most product photos cut out cleanly, but a catalog always has a tail of hard cases: reflective bottles, transparent or glossy packaging, white products on near-white surfaces. Publishing a bad cutout looks worse than the original photo, so a high-volume pipeline needs a QA step. You cannot eyeball 10,000 images, so flag the suspicious ones automatically and send only those to a human:

import statistics

def flag_for_review(results_with_meta):
    """results_with_meta: list of (sku, width, height, size_bytes, category)"""
    sizes = [m[3] for m in results_with_meta]
    median = statistics.median(sizes)
    tricky = {"glassware", "jewelry", "transparent-packaging"}

    review = []
    for sku, w, h, size_bytes, category in results_with_meta:
        too_small = size_bytes < median * 0.3  # over-cropped subject
        if too_small or category in tricky:
            review.append(sku)
    return review

Two cheap signals catch most failures: an output whose file size is far from the batch norm, and products in categories you already know are tricky. Route the flagged SKUs to a review queue and auto-publish the rest, keeping human effort on the few percent that need it.

When a cloud API beats self-hosting

Open-source models like rembg are free and fine for low volume. At catalog scale the calculus changes: a managed API holds quality across hair, fur, and transparent packaging where lighter models struggle, there is no GPU fleet to operate, and you monitor one pipeline with retries and a single output format instead of a model deployment you maintain. The trade-off is a per-call cost and a network dependency, usually worth it when image quality directly affects conversion.

Read the full guide with the new-product ingest worker and the gradient and blur options on ai-engine.net.

Build eKYC for Your SaaS: Match a Selfie to an ID with an API

AI Engine — Sun, 07 Jun 2026 05:49:50 +0000

Your SaaS needs to confirm new users are who they claim to be: a fintech opening accounts, a marketplace onboarding sellers, a gig app vetting workers. The standard step is eKYC. The user uploads a government ID and takes a selfie, and your backend checks that the selfie matches the photo on the ID. Building that from scratch means face-recognition models and document parsing. Two APIs handle both halves, and you can wire the onboarding step together in an afternoon.

This walkthrough builds the two layers you can ship quickly: extracting the ID data with an OCR API, and matching the selfie to the ID photo with a face comparison API, then combining them into an approve / review / reject decision. Every snippet runs against live endpoints.

Want to test the match step now? Try the Face Analyzer API on a selfie and an ID photo.

What eKYC actually requires

It helps to be precise about the layers, because no single API does all of them and overclaiming here is how teams ship insecure onboarding:

Document data extraction - read the name, date of birth, document number, and expiry off the ID. This uses an OCR API.
Face match - confirm the selfie is the same person as the ID photo. This uses a face comparison API.
Liveness - confirm the selfie is a live person, not a photo of a photo or a screen replay. A separate concern.
Document authenticity - confirm the ID itself is genuine and unaltered. Also separate, and the hardest to automate.

The first two are the layers you can build today with a couple of API calls, and they catch the most common case: a user submitting someone else's ID.

Step 1: Extract the ID data with OCR

Send the ID image to the OCR endpoint and get the text back. For a national ID, license, or passport, it returns every printed field:

import requests

OCR_HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "ocr-wizard.p.rapidapi.com",
}

def read_id_document(id_image_path):
    """OCR an ID document, return the raw extracted text."""
    with open(id_image_path, "rb") as f:
        r = requests.post(
            "https://ocr-wizard.p.rapidapi.com/ocr",
            headers=OCR_HEADERS,
            files={"image": f},
        )
    return r.json()["body"]["fullText"]

Labels and values come back on separate lines, exact order varying by document. To turn that into structured fields, pipe it through an LLM, the same pattern as an invoice or receipt parser.

Reading IDs, invoices, or receipts? Try the OCR Wizard API on your own document.

Step 2: Match the selfie to the ID photo

Now the core of identity verification: does the selfie belong to the same person as the photo on the ID. The compare-faces endpoint takes two images and returns the faces that matched. A useful detail: you can pass the full ID image as the target without cropping the photo first, and the API locates the face on the document for you.

FACE_HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
}

def faces_match(selfie_path, id_image_path):
    """Return True if the selfie matches the face on the ID document."""
    with open(selfie_path, "rb") as selfie, open(id_image_path, "rb") as id_img:
        r = requests.post(
            "https://faceanalyzer-ai.p.rapidapi.com/compare-faces",
            headers=FACE_HEADERS,
            files={
                "source_image": ("selfie.jpg", selfie, "image/jpeg"),
                "target_image": ("id.jpg", id_img, "image/jpeg"),
            },
        )
    body = r.json()["body"]
    return len(body.get("matchedFaces", [])) > 0

A non-empty matchedFaces means the selfie and the ID photo are the same person. An empty match with a populated unmatchedFaces means a mismatch.

Curious how it scores your own pair of images? Run it on a selfie and an ID and read the matched faces back.

Step 3: Quality-gate the inputs with face detection

The compare call finds the face on the ID for you, so you do not need detection to make the match. Where detection earns its place is as a quality gate before the comparison: confirm the selfie shows exactly one clear face, and confirm the ID actually has a detectable photo. That turns a useless empty match into a clear reason like "no face found on the document":

def count_faces(image_path):
    """Return how many faces the detector finds in an image."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://faceanalyzer-ai.p.rapidapi.com/faceanalysis",
            headers=FACE_HEADERS,
            files={"image": f},
        )
    return len(r.json()["body"]["faces"])

Zero faces on the selfie means a bad capture, two or more means someone else is in frame, and zero on the ID means the photo region was not readable. Each is a reason to route to review rather than guess.

Step 4: Turn it into a decision

No single call is a decision. Combine the detection gate, the document data, the expiry check, and the face match into one verdict your flow can act on:

import re
from datetime import date

def verify_identity(selfie_path, id_image_path):
    if count_faces(selfie_path) != 1:
        return "review", "selfie must show exactly one clear face"
    if count_faces(id_image_path) != 1:
        return "review", "could not find a single face on the ID document"

    text = read_id_document(id_image_path)
    m = re.search(r"EXPIRES\s+(\d{4}-\d{2}-\d{2})", text)
    expiry = date.fromisoformat(m.group(1)) if m else None
    if expiry is not None and expiry < date.today():
        return "reject", "ID is expired"

    if not faces_match(selfie_path, id_image_path):
        return "review", "selfie did not match the ID photo"
    if expiry is None:
        return "review", "could not read the expiry date"
    return "approve", "identity verified"

Auto-approve when everything lines up, auto-reject on a clear failure, and send the ambiguous middle to a human queue rather than guessing.

Honest limits

These two layers catch the common failure modes, but they are not a complete eKYC stack on their own. There is no liveness here, so a face match alone cannot tell a live selfie from a held-up photo of the ID owner; add a liveness step for anything high-risk. And OCR reads what is printed, it does not verify the ID is genuine; forged documents need a separate authenticity layer. Treat this as the face-match and data-extraction core of your eKYC, not the whole thing.

Read the full guide with the Flask endpoint, the response shapes, and the decision logic on ai-engine.net.

PDF OCR in Python: Extract Text from Scanned PDFs in 5 Lines

AI Engine — Sat, 06 Jun 2026 05:55:14 +0000

You have a folder of scanned PDFs. Invoices, contracts, old reports, bank statements your accountant emailed you. None of them are searchable. PyPDF2 returns empty strings because the text is locked inside pixel data, not actual characters.

The classic Python answer is Tesseract: install the binary, install pytesseract, install pdf2image and Poppler, convert each page to an image, run OCR per page, stitch the text back together. Forty lines of code, three system dependencies, and accuracy that varies with scan quality.

A cloud OCR API skips all of that. Here are the five lines of Python that replace the entire pipeline.

Want to run it now? Grab a key from the OCR Wizard API and paste it in.

The 5-line solution

import requests

with open("scanned.pdf", "rb") as f:
    r = requests.post(
        "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
        headers={"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
        files={"pdf_file": f},
        data={"first_page": 1, "last_page": 10},
    )

print("\n\n".join(p["fullText"] for p in r.json()["body"]["pages"]))

No Tesseract install, no pdf2image, no Poppler, no per-page image conversion. Open the PDF, post it, join the pages.

One detail worth knowing: the API caps each request at a 10-page range (the difference between first_page and last_page cannot exceed 10). The snippet covers any PDF from 1 to 10 pages in a single call.

Process PDFs longer than 10 pages

Slide a 10-page window across the document:

import requests

HEADERS = {"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"}
URL = "https://ocr-wizard.p.rapidapi.com/ocr-pdf"
BATCH = 10

def ocr_pdf(pdf_path, total_pages):
    all_pages = []
    for start in range(1, total_pages + 1, BATCH):
        end = min(start + BATCH - 1, total_pages)
        with open(pdf_path, "rb") as f:
            r = requests.post(URL, headers=HEADERS, files={"pdf_file": f},
                              data={"first_page": start, "last_page": end})
        all_pages.extend(r.json()["body"]["pages"])
    return all_pages

pages = ocr_pdf("annual-report.pdf", total_pages=120)
print(f"{len(pages)} pages, {sum(len(p['fullText']) for p in pages)} characters")

See the folder-batch and citation variations in the complete guide.

Track page numbers for citations

The API does not return a pageNumber field, so use the list index plus your first_page offset when you need to cite specific pages:

pages = r.json()["body"]["pages"]
first_page = 1
for offset, p in enumerate(pages):
    print(f"[Page {first_page + offset}] ({p['detectedLanguage']})")
    print(p["fullText"][:200], "...\n")

Why skip Tesseract locally

Tesseract is a fine engine and still the go-to for offline, privacy-sensitive workloads. For most other use cases, the cloud approach wins on three concrete points: no system dependencies (no binary, no Poppler), no per-page image conversion (the API accepts the PDF directly), and better accuracy on noisy scans like faxes and skewed pages.

Read the full PDF OCR developer guide on ai-engine.net, or see how to pipe OCR into GPT-4 in the ID Card to JSON tutorial.

Free PDF OCR API: Extract Text from Scanned PDFs (No Setup)

AI Engine — Tue, 02 Jun 2026 19:01:10 +0000

"Free PDF OCR" usually means one of three things, each with strings attached. Tesseract is free but needs the binary, Poppler, pdf2image, and per-page rasterization, a forty-minute setup the first time. Online tools like Smallpdf cap file size, drop pages, or watermark output. Free trial APIs from the big clouds require a credit card and an account setup that takes longer than the OCR itself.

A free-tier cloud OCR API on the RapidAPI marketplace skips all three compromises. You sign up once, grab a key, and call the endpoint from any language that can send an HTTP POST.

Want to skip the setup? Try the OCR Wizard API on a scanned PDF.

The 30-second quickstart

Three steps, no install beyond the Python requests library.

Sign up at OCR Wizard on RapidAPI, subscribe to the free plan, copy your key.
Paste the key into the script below.
Run it against any scanned PDF, up to 10 pages per call.

import requests

with open("scanned.pdf", "rb") as f:
    r = requests.post(
        "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
        headers={"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
        files={"pdf_file": f},
        data={"first_page": 1, "last_page": 10},
    )

print("\n\n".join(p["fullText"] for p in r.json()["body"]["pages"]))

That is the whole client. No model weights, no native binary, no per-page image conversion. The response comes back as JSON with one entry per page.

What you get on the free tier

Scanned PDF text extraction via the /ocr-pdf endpoint, with per-page text and language detection.
Image OCR on the sibling /ocr endpoint, which takes JPEG and PNG instead of PDF.
Automatic language detection per page, returned as a two-letter code.
HTTPS everywhere, multipart upload, no base64 string gymnastics.

See the full response format in the complete guide.

Why a cloud API beats "free" alternatives

Option	Setup	Catch
Tesseract + Poppler	30 to 60 min	accuracy drops on noisy scans, manual page rasterization
Browser tools (Smallpdf, PDF24)	none	file-size limits, watermarks, no API
AWS Textract / Google DocAI free tier	30 to 60 min	credit card required, SDK lock-in
Free RapidAPI OCR endpoint	2 min	10-page range cap per call

The decision comes down to two factors: can you stomach the Tesseract install for the offline guarantee, or do you want to ship something tonight? If the answer is the second, the free tier gets you to working OCR faster than any alternative here.

Pair it with an LLM for structured output

Raw OCR text is rarely the final deliverable. The common next step is feeding it to a model that pulls out the fields you care about:

from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_KEY")
text = "\n\n".join(p["fullText"] for p in r.json()["body"]["pages"])

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": f"Extract invoice_number, date, vendor, total as JSON:\n{text}"}],
    response_format={"type": "json_object"},
)
print(resp.choices[0].message.content)

When the free tier stops being enough

You hit the monthly quota mid-week, you have a PDF longer than 10 pages that you need processed in a single call, or you need priority processing inside an SLA. Bump up to a higher tier on the same API page; the code does not change.

Read the full guide with cURL, JavaScript, and folder-batch examples, or the focused 5-line Python tutorial.

Extract PDF Tables in 2026: Hybrid OCR + LLM Beats GPT-4o Vision

AI Engine — Sat, 30 May 2026 17:32:30 +0000

Your invoicing system needs to ingest scanned purchase orders. Your accounting platform handles contracts with cross-page tables. The text inside these PDFs has to come out as structured data, not just a wall of text, or your downstream code has nothing to act on.

In April 2026, LlamaIndex published their ParseBench benchmark showing vision LLMs with specific prompts outperform traditional OCR on layout-heavy documents. The buzz suggests we should all switch to Gemini 3 Flash or GPT-4o with HTML colspan/rowspan prompts. So I ran the comparison live on a messy 2-page purchase order. The results were not what the headlines suggest.

Want to test it on your own documents? Try the OCR Wizard API with a scanned PDF.

Quick comparison

Same 2-page purchase order, 7 line items, repeated shipping-address sub-headers, item 030 split across the page break. Mat.No identifiers (like ALRD00882) are the codes that matter: get one wrong and you ship the wrong product.

Approach	Latency	Cost	Codes accurate	Layout
OCR API alone	1.14s	~$0.001	7 of 7	lost
GPT-4o-mini + prompts	22s	$0.0087	1 of 7	preserved
GPT-4o full + prompts	20s	$0.0228	1 of 7	preserved
Hybrid (OCR + GPT-4o-mini)	23s	$0.002	7 of 7	preserved

What ParseBench got right

The benchmark tested 14 parsing methods and found prompt design matters more than model size. LlamaParse Agentic scored 84.9, Gemini 3 Flash 71, beating dedicated parsers like AWS Textract (47.9), Google DocAI (50.4), and Azure Document Intelligence (59.6).

The trick: ask the model to emit HTML tables with colspan and rowspan attributes. Here is the approach as runnable code:

import base64
from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_API_KEY")

SYSTEM_PROMPT = """You are a document parser. Convert PDFs into clean Markdown.
- Convert tables to HTML using <table>, <tr>, <th>, <td>.
- Use colspan and rowspan to preserve merged cells and hierarchical headers.
- Maintain reading order. Output only the parsed content."""

def encode(path):
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode()

resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": [
            {"type": "text", "text": "Parse this document. Merge tables split across pages."},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{encode('page1.png')}"}},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{encode('page2.png')}"}},
        ]},
    ],
)
print(resp.choices[0].message.content)

On my test, both GPT-4o-mini and GPT-4o full produced a correctly structured table. The layout claim holds up.

What ParseBench did not stress-test

Per-character fidelity on identifiers. Both vision LLM runs invented Mat.No codes that look plausible but do not match the source:

Source	GPT-4o-mini	GPT-4o full
ALRD00882	ALU000892	ALUM0088
ALRD00913	ALU000913	ALUM00913
ALSQ00716	ALU050716	(dropped)
ALPL00534	ALPL005034	ALPL05034

GPT-4o-mini also rewrote 12.700 (a tolerance in mm) as 12,700, three orders of magnitude off. It misread 3658 mm as 356 mm. GPT-4o full fixed those numeric mistakes but still hallucinated the identifiers.

This is not a flaw in the prompts. It is what happens when a language model generates text from pixels: alphanumeric codes have no linguistic regularity, so the model substitutes characters from codes it has seen in similar layouts. Bigger models hallucinate less, but they still hallucinate.

See the full item-by-item output comparison in the complete guide.

The hybrid pipeline

Pure OCR reads every character literally with no language prior, which is why it preserved all 7 codes. But it emits text in a broken reading order on messy layouts. Hybrid splits the work: OCR for fidelity, LLM for layout reconstruction.

Step 1, OCR extracts exact text:

import requests

def ocr_pdf(pdf_path):
    with open(pdf_path, "rb") as f:
        r = requests.post(
            "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
            headers={"x-rapidapi-key": "YOUR_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
            files={"pdf_file": f},
            data={"first_page": 1, "last_page": 10},
        )
    pages = r.json()["body"]["pages"]
    return "\n\n".join(p["fullText"] for p in pages)

Step 2, the LLM reconstructs structure under a prompt that forbids changing values:

from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_KEY")

SYSTEM_PROMPT = """You receive raw OCR text. The OCR is accurate at the character
level but the reading order is broken. Reconstruct the document as clean HTML.
CRITICAL: Every code, number, identifier, email, and date in your output MUST
appear verbatim in the input. Do NOT invent, modify, or correct any value.
Convert tables to HTML with <table>, <tr>, <th>, <td>, colspan and rowspan.
Merge tables split across pages."""

def reconstruct(ocr_text):
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": f"OCR TEXT:\n{ocr_text}\n\nOutput ONLY the HTML."},
        ],
    )
    return resp.choices[0].message.content

# Full pipeline
text = ocr_pdf("purchase_order.pdf")
html = reconstruct(text)

On the same purchase order, this preserved all 7 Mat.No codes, fixed the page-break fragmentation, separated the shipping-address blocks, and produced one well-formed HTML table.

Why hybrid costs less than direct vision LLM

Vision LLM input is dominated by image tokens. Two pages plus prompts run about 51,000 tokens. The hybrid sends only the OCR text, about 1,300 tokens. Input cost drops by a factor of 39. At 10,000 documents per month: $20 hybrid, $87 GPT-4o-mini direct, $228 GPT-4o full.

When to use what

Searchable text only (RAG, archive): OCR alone.
Structured tables, values must be exact (invoices, contracts): hybrid.
Charts, graphs, signatures, hand-drawn marks: vision LLM direct, since OCR cannot see what is not text.
Sub-second latency at high volume: OCR alone.

Sources

Read the full guide with the annotated test document and complete pipeline code on ai-engine.net.

Photo to Anime: API vs AnimeGAN v2/v3 (Open Source)

AI Engine — Sun, 17 May 2026 09:42:08 +0000

You want to add an anime or cartoon filter to your application. The open-source route is tempting: AnimeGAN has been the go-to model since 2020, with v2 (2021) and v3 (2022) available as pretrained weights on GitHub. It is free, runs locally, and generates decent anime portraits. But once you look at what it actually outputs and what it takes to run in production, the picture changes. This guide compares AnimeGAN v2 and v3 against the cloud Photo to Anime API on the same portrait.

Want to see the results on your own photos? Try the Photo to Anime API on a portrait.

Quick Comparison

	Photo to Anime API	AnimeGAN v2/v3
Styles available	14 (6 premium + 7 classic + Ghibli)	5 total (face_paint, celeba_distill, paprika, Hayao, Shinkai)
Style variety	Cartoon, Pixar, Arcane, Comic, Caricature, Illustration, Anime, Sketch, Ghibli	Japanese anime only
Setup	API key	PyTorch (~2GB) or ONNX Runtime
First-run latency	1-2s (network only)	60s (PyTorch import + model download)
Steady-state latency	1-2s per image	2-3s (v2 CPU) / 700ms (v3 CPU)
Output resolution	Up to 1600x1344	512x512 fixed (v2 face_paint)
Style intensity control	Yes (0.0-1.0)	No (fixed per model)
License	Commercial	Open source

What AnimeGAN Does

AnimeGAN is a GAN trained to transform photos into anime-style images. Each version ships with a handful of pretrained weights:

AnimeGANv2 (PyTorch):

face_paint_512_v2: portrait-focused, clean lines
celeba_distill: distilled from CelebA, softer colors
paprika: trained on Paprika aesthetic

AnimeGANv3 (ONNX):

AnimeGANv3_Hayao_36: Hayao Miyazaki style
AnimeGANv3_Shinkai_37: Makoto Shinkai style

All variants produce similar results on the same input: a stylized version with anime-like shading. They are trained for the same target domain (Japanese anime).

What the Photo to Anime API Does

The API provides 3 endpoints with 14 total styles:

/cartoonize-pro: 6 premium styles (Cartoon Pro, Caricature, Arcane, Comic, Pixar, Illustration)
/cartoonize: 7 classic styles (Anime, 3D, Hand-drawn, Sketch, Art Style, Design, Illustration)
/ghibli: Studio Ghibli style with face enhancement

The premium styles produce distinct artistic aesthetics that AnimeGAN cannot reach. Same portrait, 6 different looks. None of these can be produced by AnimeGAN.

See side-by-side image comparison, code for all 3 tools, and the install pain in the complete guide.

The Style Coverage Gap

This is the fundamental difference. AnimeGAN was trained on anime datasets for a single target aesthetic per model. The API supports a broader set of style domains:

Japanese anime: both
Studio Ghibli: both (API has dedicated endpoint, AnimeGAN has v3 Hayao)
Arcane / dark fantasy: API only
Pixar / 3D animation: API only
Comic book: API only
Caricature: API only
Sketch / line drawing: API only
Style intensity control: API only (0.0 to 1.0)

Running AnimeGAN Locally

Here is how to install and run AnimeGANv2 on your machine. You will need Python 3.8+ and about 2.5GB of free disk space for dependencies.

AnimeGANv2 with PyTorch

import torch
from PIL import Image

model = torch.hub.load(
    "bryandlee/animegan2-pytorch:main",
    "generator",
    pretrained="face_paint_512_v2",
    trust_repo=True,
)
face2paint = torch.hub.load(
    "bryandlee/animegan2-pytorch:main",
    "face2paint",
    size=512,
    trust_repo=True,
)

img = Image.open("portrait.jpg").convert("RGB")
with torch.no_grad():
    output = face2paint(model, img)
output.save("result.jpg", quality=90)

First run takes about 60 seconds: PyTorch imports, repo clone from GitHub, model weight download, initial inference. Subsequent runs take 2-3 seconds per image on CPU. Output is fixed at 512x512.

AnimeGANv3 with ONNX Runtime

import numpy as np
import onnxruntime as ort
from PIL import Image

# Download model from https://github.com/TachibanaYoshino/AnimeGANv3/releases
session = ort.InferenceSession("AnimeGANv3_Hayao_36.onnx")
img = Image.open("portrait.jpg").convert("RGB")

w, h = img.size
scale = 512 / max(w, h)
new_w = int((w * scale) // 8) * 8
new_h = int((h * scale) // 8) * 8
img_resized = img.resize((new_w, new_h), Image.LANCZOS)
arr = np.array(img_resized).astype(np.float32) / 127.5 - 1.0
arr = arr[np.newaxis, :, :, :]

output = session.run(None, {session.get_inputs()[0].name: arr})
result_arr = (output[0][0] + 1.0) * 127.5
result_arr = np.clip(result_arr, 0, 255).astype(np.uint8)
Image.fromarray(result_arr).save("result.jpg", quality=90)

v3 is faster than v2 on CPU (~700ms per image) thanks to ONNX Runtime, but you manage preprocessing manually.

Calling the Photo to Anime API

import requests

url = "https://phototoanime1.p.rapidapi.com/cartoonize-pro"
headers = {
    "x-rapidapi-host": "phototoanime1.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

for style in ["arcane", "pixar", "comic", "caricature"]:
    with open("portrait.jpg", "rb") as f:
        response = requests.post(
            url,
            headers=headers,
            files={"image": f},
            data={"style": style, "style_degree": "0.7"},
        )
    result = response.json()
    print(f"{style}: {result['image_url']}")

Performance Benchmark

We ran both tools on the same portrait. Test environment: Intel Core i7-7700HQ @ 2.80GHz, 4 cores, no GPU.

Tool	First call	Steady state	Output size	Notes
AnimeGANv2 (face_paint)	~60s	2-3s	512x512	PyTorch import + repo clone + 8MB weight download on first run
AnimeGANv3 (Hayao ONNX)	~3s	700ms	matches input	4MB ONNX model, no PyTorch needed
Photo to Anime API	1-2s	1-2s	up to 1600x1344	No local setup, includes network

The API wins on cold start (no model to load), consistency (same latency every call), and output resolution. AnimeGANv3 wins on per-call latency once warm if you stay in the anime style. AnimeGANv2 is the slowest of the three on every metric except cost.

When to Choose AnimeGAN

Japanese anime style is enough. If you only need anime portraits, AnimeGAN handles that.
Offline processing. No network dependency.
Custom training. Fine-tune AnimeGAN on your own dataset with GPU time.
Zero per-call cost. Self-hosting wins on cost at high volume with existing GPU hardware.

When to Choose the API

Multiple artistic styles. Arcane, Pixar, Comic, Caricature, Illustration, Ghibli. AnimeGAN cannot produce any of these.
Higher output resolution. Up to 1600x1344 vs AnimeGAN's fixed 512x512.
Style intensity control. style_degree parameter (0.0-1.0) for subtle to strong effects.
No dependency management. No PyTorch (~2GB), no onnxruntime, no model weights to download.
Face-aware processing. Detects faces and applies stylization with smooth blending.

Sources

AnimeGANv2 PyTorch (bryandlee) - PyTorch port, 3 pretrained weights, torch.hub integration
AnimeGANv3 official repository - Hayao and Shinkai ONNX models, v1.1.0 release
AnimeGANv2 paper and TensorFlow implementation - architecture details

Read the full guide with side-by-side image comparison, all 6 premium styles demo, and JavaScript examples on ai-engine.net.

Emotion Detection: Face Analyzer API vs DeepFace

AI Engine — Sat, 16 May 2026 06:00:18 +0000

You want to detect emotions from facial expressions. Customer feedback kiosks, driver monitoring, telehealth, HR mood tracking. Two approaches: install DeepFace, the most popular open-source face analysis library (22,000+ GitHub stars), or call a cloud face analysis API. This guide tests both on the same images and compares what they get right, what they get wrong, and what it takes to run each in production.

Want to see how it performs on your photos? Try the Face Analyzer API on your own images.

Quick Comparison

	Face Analyzer API	DeepFace
Emotions detected	8 (happy, sad, angry, surprised, disgusted, calm, confused, fear)	7 (angry, disgust, fear, happy, sad, surprise, neutral)
Output format	Dominant emotion(s), can return multiple	Percentage scores for all 7
Extra features	Age, gender, smile, glasses, sunglasses, landmarks, face comparison	Age, gender, race
Setup	API key (2 min)	TensorFlow + tf-keras + ~1GB model weights
Latency (CPU)	600-700ms	500-5,000ms (depends on cold/warm)
License	Commercial	MIT

What DeepFace Does

DeepFace is a Python library that wraps multiple face analysis models. It uses TensorFlow under the hood and downloads model weights (~500MB) on first run.

from deepface import DeepFace

result = DeepFace.analyze(
    "photo.jpg",
    actions=["emotion", "age", "gender"],
    silent=True,
)

r = result[0]
print(f"Emotion: {r['dominant_emotion']}")
for emo, score in sorted(r["emotion"].items(), key=lambda x: -x[1]):
    print(f"  {emo}: {score:.1f}%")

The first call is slow (5-10 seconds) because it downloads model weights from GitHub. Subsequent calls take 500-800ms on CPU.

What the Face Analyzer API Does

import requests

url = "https://faceanalyzer-ai.p.rapidapi.com/faceanalysis"
headers = {
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("photo.jpg", "rb") as f:
    response = requests.post(url, headers=headers, files={"image": f})

for face in response.json()["body"]["faces"]:
    ff = face["facialFeatures"]
    print(f"Emotions: {ff['Emotions']}")
    print(f"Gender: {ff['Gender']}, Age: {ff['AgeRange']['Low']}-{ff['AgeRange']['High']}")
    print(f"Smile: {ff['Smile']}, Glasses: {ff['Eyeglasses']}")

One API call returns emotion + age + gender + smile + glasses + sunglasses + landmarks. DeepFace requires separate analysis passes and does not detect smile, glasses, or landmarks.

See real benchmarks side by side, full code for both tools, and the install gotchas in the complete guide.

Testing Both on the Same Images

Test environment: Intel Core i7-7700HQ @ 2.80GHz, 4 cores, no GPU.

Test 1: Surprised expression

API: SURPRISED. Female, 31-39. Latency: ~600ms.
DeepFace: surprise 95.9%, happy 2.9%, fear 1.1%. Woman, 32. Latency: ~500ms (warm).
Verdict: both correct.

Test 2: Fear expression

API: SURPRISED + FEAR (two emotions). Male, 27-35. Latency: 665ms.
DeepFace: FaceNotDetected crash. With enforce_detection=False: sad 99.7%. Wrong emotion.
Verdict: API wins.

Test 3: Angry expression

API: ANGRY. Male, 47-55. Latency: 633ms.
DeepFace: FaceNotDetected crash. With fallback: neutral 77.5%. Wrong emotion, wrong gender (Woman 52.1%), age 31 vs API 47-55. Latency: 5,672ms.
Verdict: API wins. DeepFace got emotion, gender, and age all wrong.

Summary: API correct on 3/3 images. DeepFace crashed on 2/3, wrong emotion on 2/3, wrong gender on 2/3.

The Installation Problem

DeepFace's biggest friction point is setup. Here's what we encountered:

pip install deepface installs TensorFlow (~500MB of dependencies)
First run crashes with ValueError: You have tensorflow 2.21.0 and this requires tf-keras package. Fix: pip install tf-keras
First analysis call downloads 3 model files from GitHub (emotion 6MB, age 539MB, gender 537MB). Total: over 1GB of model weights
File paths with non-ASCII characters (e.g., French "Téléchargements") throw ValueError: Input image must not have non-english characters
Without a GPU, TensorFlow prints warnings about missing CUDA drivers on every single run

The API requires pip install requests and an API key. That's it.

When to Choose DeepFace

You need emotion score distributions. DeepFace returns percentage scores for all 7 emotions.
Offline processing. No network dependency.
You need race estimation. DeepFace detects race. The API does not.

When to Choose the API

Reliable face detection. The API detected all 3 test images. DeepFace crashed on 2 of 3.
Multi-feature analysis. One API call returns emotion + age + gender + smile + glasses + landmarks.
Face comparison and repositories for identity verification workflows.
No dependency headaches. No TensorFlow, no tf-keras, no 1GB model downloads.
Consistent latency. 600-700ms regardless of input vs DeepFace ranging from 500ms (warm) to 5,000ms+ (cold start).

Sources

DeepFace GitHub Repository - 22K+ stars, MIT license, TensorFlow-based
Facial Expression Recognition with Keras (Serengil, 2018) - FER2013 benchmark: human accuracy ~65%, top models ~75%
DeepFace on PyPI - current version, dependencies

Read the full guide with image-by-image breakdown, install gotchas explained, and JavaScript examples on ai-engine.net.

NSFW Detection: API vs NudeNet for Content Moderation

AI Engine — Thu, 14 May 2026 19:24:42 +0000

Your platform accepts user-uploaded images. You need to filter out inappropriate content before it reaches other users. Two options: install NudeNet, the most popular open-source NSFW detection library (2,300+ GitHub stars), or call a cloud NSFW detection API that handles everything server-side. This guide tests both on the same images and compares what they catch, what they miss, and what it costs to run each in production.

Want to test on your own images? Try the NSFW Detect API on a few uploads.

Quick Comparison

	NSFW Detect API	NudeNet
Categories	10 (nudity, violence, drugs, alcohol, tobacco, gambling, hate symbols, etc.)	1 (nudity only)
Label structure	Hierarchical (3 levels)	Flat (body parts)
Setup	API key	`pip install nudenet` + ONNX model download
GPU	Not needed	Optional (faster)
Accuracy	93-98% across categories	~90% on nudity
License	Commercial	AGPL-3.0

What NudeNet Does

NudeNet is a Python library that detects nudity in images. Version 3 uses ONNX Runtime instead of TensorFlow, which makes it lighter and faster to install.

from nudenet import NudeDetector

detector = NudeDetector()
results = detector.detect("photo.jpg")

for detection in results:
    print(f"{detection['class']}: {detection['score']:.3f}")
    # FEMALE_BREAST_EXPOSED: 0.787
    # FACE_FEMALE: 0.736

The detection classes are all body-part based: exposed/covered variants of breasts, buttocks, genitalia, belly, feet, armpits, and face. There are no classes for violence, drugs, alcohol, gambling, or any non-nudity content.

What the NSFW Detection API Does

The NSFW Detect API classifies images across 10 categories with hierarchical sub-labels.

import requests

url = "https://nsfw-detect3.p.rapidapi.com/nsfw-detect"
headers = {
    "x-rapidapi-host": "nsfw-detect3.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("photo.jpg", "rb") as f:
    response = requests.post(url, headers=headers, files={"image": f})

labels = response.json()["body"]["ModerationLabels"]
for label in labels:
    print(f"{label['Name']}: {label['Confidence']:.1f}% (parent: {label['ParentName']})")
    # Drugs & Tobacco: 99.4% (parent: )
    # Smoking: 99.4% (parent: Drugs & Tobacco)

The response uses a 3-level taxonomy. Here is the actual JSON for a smoking photo:

{
  "statusCode": 200,
  "body": {
    "ModerationLabels": [
      {
        "Name": "Drugs & Tobacco",
        "ParentName": "",
        "TaxonomyLevel": 1,
        "Confidence": 99.4
      },
      {
        "Name": "Drugs & Tobacco Paraphernalia & Use",
        "ParentName": "Drugs & Tobacco",
        "TaxonomyLevel": 2,
        "Confidence": 99.4
      },
      {
        "Name": "Smoking",
        "ParentName": "Drugs & Tobacco Paraphernalia & Use",
        "TaxonomyLevel": 3,
        "Confidence": 99.4
      }
    ]
  }
}

You walk down the tree to get more specific. Top-level "Drugs & Tobacco" tells you the broad category, "Smoking" tells you the exact behavior. Set different thresholds per category: strict on nudity, lenient on suggestive content.

See the full comparison with side-by-side test results, accuracy benchmarks, and code for both tools in the complete guide.

Testing Both on the Same Images

We tested both tools on three Pexels images (no explicit content).

Test 1: Male shirtless photo

API: Non-Explicit Nudity (99.9%), Exposed Male Nipple (99.9%). Correct category, correct gender.
NudeNet: FEMALE_BREAST_EXPOSED (78.7%), FACE_FEMALE (73.6%). Wrong gender on both detections. The image shows a man.

Test 2: Smoking photo

API: Drugs & Tobacco (99.4%), Smoking (99.4%). Correctly identifies smoking.
NudeNet: FACE_FEMALE (67.4%). No smoking detection. Also misclassifies the male face as female.

Test 3: Alcohol photo

API: Alcohol (98.6%), Alcoholic Beverages (98.6%). Identifies the beer glasses.
NudeNet: No detections. Alcohol is not in NudeNet's scope.

The Category Gap

The test results illustrate the fundamental difference. NudeNet is a nudity detector. The API is a content moderator covering 10 categories:

Explicit Nudity
Non-Explicit Nudity (swimwear, partial exposure)
Suggestive content
Violence
Visually Disturbing
Drugs & Tobacco
Alcohol
Gambling
Hate Symbols
Rude Gestures

For platforms with advertising revenue, brand safety requires all 10. An advertiser will not care that your filter catches nudity if their ad appears next to a photo of someone smoking or holding a weapon.

When to Choose NudeNet

Nudity-only filtering. If explicit nudity is your only concern, NudeNet covers it.
Offline or air-gapped environments. No network dependency.
Privacy-critical workloads. Images never leave your server.

When to Choose the API

Multi-category moderation. Drugs, alcohol, violence, hate symbols, gambling. NudeNet cannot help.
Brand safety. Advertising platforms need all 10 categories.
Scale without infrastructure. No GPU servers, no model updates.
Hierarchical filtering. Set different thresholds per category.

Running NudeNet in Production

Tutorials make NudeNet look simple: pip install nudenet, call detect(), done. In production:

AGPL-3.0 license. Requires you to open-source your application if you distribute it. For SaaS platforms, this is a legal grey area.
No model updates. NudeNet's model was last updated in 2023.
Gender accuracy. Our tests showed NudeNet misclassifying male subjects as female on 2 out of 3 images.

Sources

NudeNet GitHub Repository - AGPL-3.0 license, 2.3K stars
A Comparative Study of Tools for Explicit Content Detection in Images (2023) - academic benchmark: NudeNet ~90% accuracy
NudeNet on PyPI - v3.4.2, ONNX runtime

Read the full guide with side-by-side demos, all 10 category details, and JavaScript examples on ai-engine.net.

Anthropic Accidentally Open-Sourced Claude Code. Here's What No One Is Talking About.

AI Engine — Thu, 02 Apr 2026 11:16:58 +0000

On March 31, 2026, someone at Anthropic forgot to add *.map to .npmignore. That single oversight shipped a 59.8 MB source map inside the @anthropic-ai/claude-code v2.1.88 npm package, exposing 512,000 lines of unobfuscated TypeScript across 1,906 files. The entire internal architecture of their flagship AI coding agent, out in the open.

Anthropic filed DMCA takedowns. GitHub repos started disappearing. Then a developer in South Korea woke up at 4 a.m., rewrote the core architecture from scratch in Python and Rust, and pushed it to GitHub. The repo hit 50K stars in 2 hours and 100K in 24 hours, the fastest-growing repository in GitHub history.

Most coverage focused on the drama: the leak, the takedowns, the legal battle. But the actual code reveals things Anthropic clearly never intended anyone to see.

What actually leaked

Not the model weights. Not customer data. Not the training pipeline.

What leaked is the agent harness: the orchestration layer that turns a language model into a coding assistant. This is the system that decides which tools to call, manages permissions, compresses context when conversations get long, spawns sub-agents for parallel work, and bridges into VS Code and JetBrains.

The numbers:

1,906 TypeScript files
40+ built-in tools (bash, file read/write, web search, LSP, MCP)
50+ slash commands
46,000-line query engine handling all LLM calls, streaming, and caching
29,000-line base tool definition
2,500 lines of bash security validation (23 sequential checks per command)
Runtime: Bun (not Node.js), UI: React with Ink for terminal rendering

This is the blueprint of a production AI agent. And some of what's inside is wild.

KAIROS: the agent that never sleeps

Buried in the feature flags is something called KAIROS. It's a persistent background daemon that doesn't wait for user input. It watches your project, logs observations, and proactively acts on what it sees, with a 15-second blocking budget per action.

The part that got people's attention: KAIROS has a "dreaming" system called autoDream. When you're idle, it performs memory consolidation. It merges observations, removes contradictions, and converts vague notes into concrete facts. It maintains append-only daily log files and can send push notifications when it finds something worth flagging.

This isn't a coding assistant anymore. It's closer to a background daemon that learns your codebase while you sleep.

BUDDY: a Tamagotchi inside your terminal

This one is genuinely unexpected. BUDDY is a virtual pet that lives in your Claude Code terminal. 18 species, rarity tiers, and it apparently reacts to your coding activity.

Anthropic, the company that publishes safety research papers about existential risk, put a Tamagotchi inside their professional development tool. It's either a brilliant retention mechanic or the most unhinged feature flag in the history of enterprise software. Probably both.

Anti-distillation traps

Here's where it gets strategic. The source reveals that Claude Code injects fake tool definitions into API requests. The purpose: if a competitor tries to scrape Claude Code's outputs to train their own model (a technique called distillation), the poisoned definitions corrupt the training data.

This is active counter-intelligence, not passive protection. Anthropic assumed competitors would try to learn from Claude Code's behavior and built traps directly into the request pipeline.

Undercover mode

The leaked code contains a stealth mode designed to hide Anthropic employee contributions to open-source projects. When active, it strips identifying metadata from commits and interactions.

Why would Anthropic need this? Likely because their engineers contribute to open-source repos as part of their work (testing, benchmarking, fixing bugs in dependencies), and they don't want those contributions traced back to Anthropic for competitive intelligence reasons. Still, the existence of an explicit "undercover mode" raised eyebrows.

44 feature flags and unreleased models

The readable source contains 44 compile-time feature flags, with at least 20 gating capabilities that are fully built and tested but hidden from users:

VOICE_MODE: push-to-talk voice interface for Claude Code
ULTRAPLAN: 30-minute remote planning sessions
COORDINATOR MODE: multi-agent orchestration where Claude spawns "swarms" of sub-agents
Persistent assistant: background mode that keeps working when you're idle

The migrations directory also references internal model codenames: Capybara (Claude 4.6 variant), Fennec (Opus 4.6), and Numbat (unreleased, still in testing).

Claw Code: 0 to 138K stars

While Anthropic was filing DMCA notices, developer Sigrid Jin took a different approach. Instead of hosting the leaked TypeScript, Jin sat down and rewrote the core architecture from scratch. Clean-room reimplementation, no copied code.

The project, called Claw Code, hit GitHub and exploded:

50K stars in 2 hours
100K stars in 24 hours
138K stars as of today (with 101K forks)
Built in Rust (92.9%) with a Python scaffold (7.1%)

The architecture mirrors Claude Code's patterns: agentic conversation loop, tool execution with permission gates, SSE streaming, session compaction, and a plugin system. It doesn't have MCP support, IDE integration, or sub-agent orchestration yet, but the foundation is solid.

The legal angle matters: because it's a clean-room rewrite and not a copy, Anthropic's DMCA claims don't apply. As Gergely Orosz (The Pragmatic Engineer) noted, the rewrite is a new creative work that violates no copyright. Anthropic's takedowns hit 8,100 GitHub repos that hosted the original TypeScript, but they can't touch Claw Code.

What this means if you build with AI

The patterns inside Claude Code aren't magic. The agentic loop (user message, API call, tool execution, feed results back) is straightforward. The power comes from everything around it:

Permission layers are mandatory for any agent that runs shell commands or edits files
Context compaction (summarizing old turns while keeping recent ones) is how you handle long conversations without blowing the token budget
Tool isolation (each tool as a discrete, permission-gated module) keeps the system testable and extensible
Sub-agent spawning for parallel work is what separates a chatbot from a useful coding assistant

These patterns are now documented in the open, in production-grade form. Whether you're building an AI agent, integrating APIs into automated workflows, or just curious about how the most-used coding assistant actually works under the hood, the blueprints are public.

If you're building AI-powered features into your product, whether it's image analysis, text extraction, or face detection, the patterns exposed in this leak (tool isolation, permission gates, context budgeting) are the same ones you'll need in your own orchestration layer.

The irony: Anthropic spent years building the most sophisticated AI agent harness in the industry, and a missing .npmignore entry made it everyone's reference architecture overnight.

Sources:

Extract Text from Screenshots with an OCR API

AI Engine — Wed, 01 Apr 2026 10:47:21 +0000

Screenshots are everywhere in developer workflows. Error logs from a terminal, metrics from a dashboard, text from a chat conversation, UI copy from a design mockup. The text inside those images is useful, but it's trapped in pixels. An OCR API can extract it in a single HTTP call.

This tutorial uses the OCR Wizard API to pull text out of screenshots with Python.

Want to test it? Try the OCR Wizard API on your own screenshots.

Why Not Tesseract?

Tesseract is the go-to open-source OCR engine, but it struggles with screenshots. Colored backgrounds, UI elements, and non-standard fonts confuse it. Some developers add GPT on top just to clean up Tesseract's noisy output. That's two API calls, a local install, and extra latency. A cloud OCR API handles screenshots natively: send the image, get back clean text.

Extracting Text in Python

import requests

url = "https://ocr-wizard.p.rapidapi.com/ocr"
headers = {
    "x-rapidapi-host": "ocr-wizard.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("screenshot.png", "rb") as f:
    response = requests.post(url, headers=headers, files={"image": f})

data = response.json()
print(data["body"]["fullText"])

Real output from a terminal screenshot

$ python3 app.py
Processing 847 images from /data/uploads...
Batch 1/9: 100 images processed (12.3s)
Batch 2/9: 100 images processed (11.8s)
Batch 3/9: 100 images processed (13.1s)
Traceback (most recent call last):
  File "app.py", line 42, in process_batch
    result = api_client.analyze(image_path)
  File "client.py", line 118, in analyze
    response.raise_for_status()
requests.exceptions.HTTPError: 429 Too Many
Requests: Rate limit exceeded. Retry after 60s
ERROR: Batch 4/9 failed at image 312/847
Total processed: 312/847 (36.8%)
Elapsed: 37.2s | ETA: unknown

Every word captured: traceback, error code (429), file names, line numbers, progress stats. No noise, no missing characters.

Testing with cURL

curl -X POST \
  'https://ocr-wizard.p.rapidapi.com/ocr' \
  -H 'x-rapidapi-host: ocr-wizard.p.rapidapi.com' \
  -H 'x-rapidapi-key: YOUR_API_KEY' \
  -F 'image=@screenshot.png'

Handling Different Screenshot Types

Terminal and error logs - High contrast, monospaced text. Line breaks preserved, so you can parse stack traces or grep for error codes
Dashboards and analytics - Numbers mixed with labels and charts. The API extracts text and skips graphical parts
Chat conversations - Slack, Discord, WhatsApp. Usernames, timestamps, message bodies in reading order
UI mockups - Figma designs, web pages. Extract button labels and headings for QA spec verification

See the full tutorial with JavaScript examples and QA automation pipeline in the complete screenshot OCR guide.

Structuring Extracted Text with GPT

OCR gives you raw text. Sometimes you need structured data. Combine it with GPT-4o mini to go from pixels to JSON in two API calls.

import requests
from openai import OpenAI

# Step 1: OCR
ocr_url = "https://ocr-wizard.p.rapidapi.com/ocr"
ocr_headers = {
    "x-rapidapi-host": "ocr-wizard.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("dashboard_screenshot.png", "rb") as f:
    ocr_response = requests.post(ocr_url, headers=ocr_headers, files={"image": f})

raw_text = ocr_response.json()["body"]["fullText"]

# Step 2: Structure with GPT-4o mini
client = OpenAI()
completion = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Extract structured data from the following text. Return valid JSON only."},
        {"role": "user", "content": raw_text},
    ],
)

print(completion.choices[0].message.content)

Real GPT-4o mini output from a dashboard screenshot

{
  "monthly_revenue": { "amount": "$12,450", "growth_rate": "+18.3%" },
  "active_users": { "count": 3201, "growth_rate": "+7.2%" },
  "conversion_rate": "4.2%",
  "avg_response_time": { "time": "245ms", "change": "+12ms" },
  "top_pages": [
    { "page": "/pricing", "views": 8421, "bounce_rate": "32%", "avg_time": "2m 15s" },
    { "page": "/blog/ocr-guide", "views": 5102, "bounce_rate": "45%", "avg_time": "4m 30s" },
    { "page": "/apis/face-analyzer", "views": 3887, "bounce_rate": "28%", "avg_time": "1m 48s" },
    { "page": "/signup", "views": 2654, "bounce_rate": "18%", "avg_time": "3m 02s" }
  ]
}

GPT paired each metric with its value, converted the table into an array, and typed numbers as integers. The same approach works for error logs:

{
  "command": "python3 app.py",
  "error_type": "HTTPError",
  "error_message": "429 Too Many Requests: Rate limit exceeded. Retry after 60s",
  "file": "client.py",
  "line": 118,
  "progress": { "total_processed": 312, "total_images": 847, "elapsed_time": "37.2s" },
  "traceback": [
    { "file": "app.py", "line": 42, "function": "process_batch" },
    { "file": "client.py", "line": 118, "function": "analyze" }
  ]
}

The difference from approaches that use GPT to clean up bad Tesseract output: here the OCR result is already accurate. GPT adds structure, not quality.

QA Automation with Screenshot OCR

One of the strongest use cases: take a Playwright screenshot and verify visible text directly.

from playwright.sync_api import sync_playwright
import requests

OCR_URL = "https://ocr-wizard.p.rapidapi.com/ocr"
OCR_HEADERS = {
    "x-rapidapi-host": "ocr-wizard.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

def get_page_text(url: str) -> str:
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        page.goto(url)
        page.screenshot(path="/tmp/page.png", full_page=True)
        browser.close()

    with open("/tmp/page.png", "rb") as f:
        resp = requests.post(OCR_URL, headers=OCR_HEADERS, files={"image": f})
    return resp.json()["body"]["fullText"]

text = get_page_text("https://myapp.com/dashboard")
assert "Welcome back" in text
assert "0 errors" in text

This catches visual regressions that DOM-based tests miss: text hidden by CSS, overlapping elements, or content rendered by JavaScript.

Tips

Use PNG for screenshots (lossless). JPG compression adds artifacts that reduce OCR accuracy
Crop before sending if you only need text from one region
Use the annotations array for layout-aware extraction (word-level bounding boxes)
Multi-language works automatically, check the detectedLanguage field

Read the full guide with comparison tables and detailed tips on ai-engine.net.

Build a Face-Based Age Verification System with API

AI Engine — Tue, 31 Mar 2026 09:53:50 +0000

Age-restricted products need a way to verify that a customer is old enough. Alcohol delivery, online gambling, vaping shops, and some social platforms require an age verification system by law. Most solutions rely on ID document uploads, which creates friction. A faster approach: estimate the customer's age from a selfie using a face analysis API.

This tutorial builds a complete age verification endpoint in Python using the Face Analyzer API.

Curious how it works? Try the Face Analyzer API on your own images.

How Face-Based Age Verification Works

The user takes a selfie. The API detects the face, analyzes facial features, and returns an estimated age range (e.g., 25-35). Your app checks whether the lower bound meets the legal threshold (18, 21, etc.).

This is faster than document verification (under 1 second vs 10-30 seconds), works on any device with a camera, and doesn't require the user to have their ID. Unlike biometric authentication that stores templates, this can be stateless: process the image, get the result, discard the photo.

What the API Returns

The /faceanalysis endpoint returns an AgeRange object with Low and High bounds for each detected face:

{
  "statusCode": 200,
  "body": {
    "faces": [
      {
        "facialFeatures": {
          "Gender": "Female",
          "Smile": true,
          "Eyeglasses": false,
          "Sunglasses": false,
          "AgeRange": { "Low": 9, "High": 15 },
          "Emotions": ["HAPPY"]
        }
      }
    ]
  }
}

AgeRange.Low is what matters. If it's below your threshold, the user doesn't pass. Using the lower bound is the conservative approach.

Age Verification Function in Python

import requests

API_URL = "https://faceanalyzer-ai.p.rapidapi.com/faceanalysis"
HEADERS = {
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

def verify_age(image_path: str, min_age: int = 18) -> dict:
    """Check if the person in the image meets the minimum age."""
    with open(image_path, "rb") as f:
        resp = requests.post(API_URL, headers=HEADERS, files={"image": f})

    data = resp.json()
    faces = data["body"]["faces"]

    if not faces:
        return {"allowed": False, "reason": "no face detected"}

    age_range = faces[0]["facialFeatures"]["AgeRange"]
    estimated_low = age_range["Low"]
    estimated_high = age_range["High"]

    allowed = estimated_low >= min_age
    return {
        "allowed": allowed,
        "age_range": f"{estimated_low}-{estimated_high}",
        "threshold": min_age,
        "reason": "meets age requirement" if allowed else "below age threshold",
    }

result = verify_age("selfie.jpg", min_age=21)
print(result)
# {"allowed": False, "age_range": "9-15", "threshold": 21, "reason": "below age threshold"}

Wrapping It in a Flask Endpoint

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/verify-age", methods=["POST"])
def verify_age_endpoint():
    if "image" not in request.files:
        return jsonify({"error": "no image provided"}), 400

    image = request.files["image"]
    min_age = int(request.form.get("min_age", 18))

    resp = requests.post(
        API_URL,
        headers=HEADERS,
        files={"image": ("selfie.jpg", image.read(), image.content_type)},
    )
    data = resp.json()
    faces = data["body"]["faces"]

    if not faces:
        return jsonify({"allowed": False, "reason": "no face detected"}), 200

    age_range = faces[0]["facialFeatures"]["AgeRange"]
    allowed = age_range["Low"] >= min_age

    return jsonify({
        "allowed": allowed,
        "age_range": {"low": age_range["Low"], "high": age_range["High"]},
        "threshold": min_age,
    })

if __name__ == "__main__":
    app.run(port=5000)

See the full implementation with cURL and JavaScript examples in the complete age verification tutorial.

Testing It with cURL

curl -X POST \
  'https://faceanalyzer-ai.p.rapidapi.com/faceanalysis' \
  -H 'x-rapidapi-host: faceanalyzer-ai.p.rapidapi.com' \
  -H 'x-rapidapi-key: YOUR_API_KEY' \
  -F 'image=@selfie.jpg'

Compliance by Industry

Alcohol delivery - 21 (US) / 18 (EU, UK). Face estimation + ID fallback for borderline cases
Vaping / tobacco - 21 (US) / 18 (EU). Face estimation at checkout
Online gambling - 18-21 depending on jurisdiction. Face estimation + full KYC for account creation
Adult content - 18. Face estimation (UK Online Safety Act compliant)
Social media - 13-16. Face estimation for parental consent flow

Regulations are tightening: UK Online Safety Act, US state laws (Louisiana, Virginia, Utah), EU Digital Services Act. An age verification API lets you add compliance in one endpoint call.

Handling Edge Cases

No face detected - Blurry photo or no visible face. Ask the user to retake
Multiple faces - Use the face with the largest bounding box (closest to camera)
Borderline age - API returns 16-22, threshold is 18. Use AgeRange.Low and deny, or offer an ID upload fallback
Sunglasses - Check the Sunglasses boolean in the response and ask to remove them
Spoofing - Someone holds up a printed photo. Add liveness detection (blink check, head turn) for high-risk use cases

Tips

Always use AgeRange.Low for the threshold check - the conservative approach protects you legally
Offer an ID upload fallback for borderline cases instead of flat-out rejecting users
Don't store the selfie. Process, get the result, discard. Log only the decision for audit (GDPR)
Set the threshold higher than the legal minimum (e.g., 21 instead of 18) for a safety margin
Check the Sunglasses field and ask users to remove them for better accuracy

Read the full guide with comparison tables, JavaScript examples, and detailed compliance breakdown on ai-engine.net.