DEV Community: Sumama-Jameel

14 y/o. Nine products built. Starting a startup. Zero dollars, low-specs PC, very low public attention.

Sumama-Jameel — Tue, 01 Sep 2026 18:42:46 +0000

I am Sumama Jameel. 14 y/o. I live in Karachi, Pakistan. Not a coder, nine products built. Now I am starting a startup.

Let me explain.

Who I Am

I am not a coder. But I can look at a broken system, understand exactly why it is broken, design the architecture to fix it, and direct an AI to build the solution. I did this nine times in the past few months.

I built a privacy-first subscription tracker that finds hidden charges in bank statements without connecting to your bank. I built a threat intelligence API that checks URLs, emails, and phone numbers against multiple sources. I built an AI gateway that gives free access to models like ChatGPT and DeepSeek without API keys. I built a browser debugging tool that lets AI agents see every hidden network event. I built an environment provisioning engine. I built a reading tool for hard science books. And I built three AI agent skills for validating business ideas, debugging software, and understanding user intent.

Nine products. Zero lines of code written by my hands. I designed every system. I wrote every specification. I defined every security model. I chose every architecture. The AI handled the syntax. I handled the thinking.

I tried to sell one of them. I failed. I could not find customers. I could not explain the value simply enough. Instead of hiding, I open-sourced it and learned from the failure.

That failure taught me more than any success could. It taught me that building is ten percent of the work. The other ninety percent is finding the person who is bleeding money and putting the solution in front of them.

Now I am building something that I will not open-source. Something I will sell.

The Problem I Am Solving

I will not tell you the method. I will tell you the problem.

In 2026, AI labs are hitting a wall. They are running out of high-quality training data. Specifically, they are running out of data that teaches AI models how to actually code.

Here is what I mean.

When you look at a git diff, you see the answer. You see what changed. You see the final code. But you do not see the process. You do not see the developer reading files, exploring the codebase, making a plan, writing code, running tests, hitting an error, debugging, trying again, and finally getting it right.

That process is gone. It lived in the developer's head. It was never recorded. It was never captured.

AI coding models need that process. They need to see how a real developer thinks, explores, fails, recovers, and succeeds. Without it, they can only mimic the final output. They cannot replicate the reasoning.

The market for AI training data is projected to grow from $3.19 billion in 2025 to $8.45 billion by 2030. Synthetic data generation is growing even faster. But most synthetic data is garbage. It is hallucinated. The AI pretends to run commands. It invents terminal outputs. It fakes test results. It looks like a coding session, but nothing is real.

That is the problem. AI labs need real, grounded, verifiable coding trajectories. And there is no reliable way to get them at scale.

Until now.

What I Built

I built a system that generates high-quality, grounded, verifiable coding trajectories(data) at scale.

What it actually guarantees:

Every command output is real. Nothing is faked. Nothing is simulated.
Every error is real. When something breaks, the failure is recorded verbatim.
Every trajectory is verifiable. You can check the output against the expected result.
The system prevents the AI from cheating. It cannot look up the answer. It cannot skip the work. It cannot fake the process.
The data mirrors real enterprise software development. Not toy examples. Real tickets, real tests, real code review.

This is not a prompt wrapper. This is not a fine-tuning script. This is a data generation engine that produces training data AI labs actually need.

Why Me

I am not a machine learning researcher. I am not a data scientist. I am an architect who understands systems, understands constraints, and understands how to make AI do real work instead of fake work.

I built nine products using AI as my engineering team. I know exactly what AI can do, what it cannot do, and where it lies. I built anti-faking systems before anyone else cared about them. I built verification gates before synthetic data quality became a talking point.

I also failed to sell a product. I know what it feels like to build something good and not know how to get customers. I am not making that mistake again. This time, I have a partner with 25 years of business experience. He handles the selling. I handle the building.

What Comes Next

I am currently generating the first batch of trajectories. I am validating them. I am testing them against real coding benchmarks. I am preparing sample datasets to send to AI labs.

I am not looking for funding right now. I am looking for validation and public attention. I want AI labs to test my data on their own infrastructure and tell me if it improves their models. An AI company to try our data on their models. If it works, we talk.

If you work at an AI lab, or you are building coding agents, or you are responsible for training data quality, and you want to see a sample batch, send me a message. I will show you what grounded, anti-faked, verifiable coding trajectories look like.

The Honest Part

I have a low-spec PC. I have zero dollars in the bank. I do not have a team of engineers. I do not have a GPU cluster. I do not have a fancy office.

What I have is a working system, a clear market need, a business partner, and the stubbornness to keep going when everything says to stop.

I built nine products in a few months without writing code. I am building the tenth. This one is different. This one is for sale.

If you want to follow the journey, follow me. I will share what I can. I will not share the method. But I will share the results, the failures, the lessons, and the wins.

You can buy compute, not the DATA.

That is all I can say for now.

GitHub (open-source work): https://github.com/Sumama-Jameel

Browser dev tools but for AI agents. Open-sourced. Full visibility.

Sumama-Jameel — Tue, 01 Sep 2026 18:32:24 +0000

I built an open-source tool called Whelmer. It gives AI agents full visibility into what a browser is doing. Every DOM change, every network request, every console message, every storage mutation — nothing is hidden, nothing is filtered.

Here is exactly what it is, why I built it, and how it works.

The Problem

When you connect to a browser debug port, the browser emits events for everything. CDP alone has 53 domains with hundreds of event types. Every DOM change, every network request, every console message, every CSS update, every storage mutation, every security state change — all of it flows out as WebSocket messages.

But existing agent tools give you a filtered view. They show you the events they think you need and drop the rest. You do not see what you do not know exists.

If a page fires a Storage event that reveals how an SPA manages auth tokens, most tools never tell you. If a service worker intercepts a request and modifies the response, most tools never show you. You are working blind.

It gets worse with multi-browser support:

Firefox uses a completely different protocol (BiDi or FDP)
Safari uses WebKit Remote Debugging Protocol
Most tools only support Chrome via CDP
Agent frameworks that claim multi-browser support often hide protocol differences behind opinionated abstractions that drop events

You end up debugging in the dark.

What Whelmer Does

Whelmer shows you everything.

Every event from every enabled domain flows through an EventBus with a 10,000-event ring buffer. You can stream all events as NDJSON. You can filter by domain. You can replay history. You can enable or disable any of the 53 CDP domains at runtime.

Nothing is hidden. Nothing is filtered. You get the full firehose and decide what matters.

It connects to Chrome, Brave, Edge, Opera, and Firefox out of the box. Four protocols. One binary. Same event model.

Why I Built It

I built Whelmer for a specific job: reverse-engineering the web apps and their internal API. This project was built using Whelmer: https://github.com/Sumama-Jameel/Mirage

When OpenAI, Google, Grok, Qwen, or others update their UI or internal API format, integrations that depend on those internal APIs break. You need to see exactly what changed. You need to see every network request, every console message, every storage mutation as raw JSON.

Whelmer exposes all of that in your terminal. You see exactly what changed and fix your integration in minutes instead of hours. No switching to browser DevTools. No manual inspection. Just raw protocol data.

That project (an OpenAI-compatible API wrapper that routes through these internal APIs — Mirage) is what drove the need for Whelmer.

How It Works

The data flow is a pipeline with four stages:

WsConnection — Persistent WebSocket connection to the browser debug port. Writer task sends commands. Reader task routes responses back to callbacks and all other messages to an mpsc channel.
EventBus — Bridges the mpsc receiver to a broadcast channel and a ring buffer. A bridge task reads every event from the mpsc channel and publishes it to all broadcast subscribers while simultaneously appending it to the in-memory history buffer. No events are dropped.
Display Consumer — Spawned automatically on startup. Handles known event types and prints them formatted to the terminal. One directional: reads from the broadcast channel, writes to stdout.
Agent Consumer — Created on demand when you run the events command. Subscribes to the broadcast channel for live streaming, or reads from the ring buffer for history. Supports --json, --history N, and domain filtering. Multiple agent consumers can run simultaneously.

The key design choice: the EventBus decouples event production from consumption. The bridge task never blocks. Every consumer gets every event. There is no "you get this, you do not get that" routing logic at the bus level.

Multi-Protocol Support

Whelmer supports four protocols:

CDP — Chrome DevTools Protocol (Chrome, Brave, Edge, Opera)
BiDi — WebDriver BiDi Protocol (W3C standard, works in Chrome and Firefox)
FDP — Firefox DevTools Protocol (older Firefox versions)
Foxbridge — CDP-to-Firefox proxy

One tool covers every major browser. Add a new protocol by implementing the ProtocolConnection trait.

Commands

Whelmer has a full command set:

tabs — List, create, close, activate browser tabs
attach — Switch to a specific tab
dom — Inspect the page DOM
eval — Run JavaScript in page context
cookies — Read/write/delete cookies
storage — Inspect or modify localStorage / sessionStorage
cache — Show Cache Storage data
indexeddb — Show IndexedDB databases
network — Live request/response monitoring
export — Export all data to JSON
screenshot — Capture page screenshot
perf — Show performance metrics
security — Show page security state
websockets — Show WebSocket connections and frames
events — Stream raw protocol events
domains — List all 53 CDP domains
enable / disable — Toggle CDP domains at runtime
capture — In-REPL capture session
records — List / inspect captured requests
replay — Export captures as HAR, CSV, or JSON
diff — Compare two captures
doctor — Run diagnostic battery

Every data command accepts --json for machine-readable output.

Recording and Replay

Whelmer can record browser sessions:

# One-shot capture: record until the target API responds, then stop
whelmer record --until "api/chat" --output caps.ndjson

# Saved session: reuse your filter set anywhere
whelmer record @myapi --duration 60s

# Background daemon: runs detached, writes a .done marker when finished
whelmer record --until "api/chat" --output caps.ndjson --detach

You can replay captures:

# Replay a capture as HAR, CSV, or JSON
whelmer replay caps.ndjson --grep "api/chat" --export har --output chat.har

# Rebuild a single recorded request as a copy-paste cURL command
whelmer curl caps.ndjson chat-abc123

# Compare two captures — finds what the API contract changed
whelmer diff run1.ndjson run2.ndjson --json

This is how you debug when a provider changes their internal API. You record before the change, record after the change, and diff them.

Machine-Readable Control

Whelmer can expose its session over JSONL for agents and automation:

# Expose the session over JSONL on stdin/stdout
whelmer serve

# TCP listener with auto-generated auth token
whelmer serve --tcp 9876

# Unix domain socket (permission-gated, no token needed)
whelmer serve --unix /tmp/w.sock

This lets AI agents control Whelmer programmatically.

Under the Hood

Whelmer is written in pure Rust. No Node.js. No Python. No npm install. No bundler. One static binary, about 7 MB. Runs on any Linux, macOS, or Windows machine with a browser.

The project structure:

src/
├── main.rs                 # CLI entry point, REPL loop
├── connection.rs           # Persistent WebSocket with command/response routing
├── event_bus.rs            # Broadcast channel + ring-buffer history
├── events.rs               # Event processors + DomainRegistry (53 CDP domains)
├── formatters.rs           # Output formatters (JSON, Table, CSV, YAML, Text)
├── handlers.rs             # Command handlers (cookies, storage, DOM, eval, etc.)
├── protocol.rs             # ProtocolConnection trait + ProtocolEvent enum
├── protocol_detector.rs    # Auto-detect browser and protocol on the network
├── record.rs               # One-shot record orchestration
├── diagnose.rs             # `whelmer doctor` diagnostic battery
├── curl.rs                 # Record → cURL command reconstruction
├── capabilities.rs         # Static per-protocol capability matrices
├── capture/                # Correlation engine, filters, sinks, replay, diff
├── protocols/
│   ├── mod.rs              # Protocol implementations
│   ├── cdp.rs              # Chrome DevTools Protocol
│   ├── bidi.rs             # WebDriver BiDi Protocol
│   ├── fdp.rs              # Firefox DevTools Protocol (RDP)
│   └── foxbridge.rs        # Foxbridge CDP-to-Firefox proxy

All tests run with mock connections. No browser needed. 379 unit tests, 14 binary tests, 2 integration tests passing.

Privacy by Design

Whelmer connects to your local browser only. No cloud. No telemetry. No data leaves your machine. No accounts. No signup.

You run it against your own browser, on your own machine. That is it.

The Honest Catch

Whelmer gives you the raw firehose. That means you get a lot of noise. If you enable all 53 CDP domains, your terminal will be flooded with events. You need to know which domains matter for your use case.

Also, browser protocols change. Chrome updates CDP. Firefox updates BiDi. When that happens, Whelmer needs updates too. This is not a "set it and forget it" tool. It requires maintenance as browsers evolve.

And because Whelmer shows everything, it is not a beginner tool. If you do not understand what CDP domains are or what a Storage event means, Whelmer will overwhelm you. It is built for people who already understand browser internals and need deeper visibility.

Who It Is For

Whelmer is for:

AI agent developers who need to debug why their agents fail on complex websites
Reverse engineers who need to understand how web apps work internally
Security researchers who need to see every network request and storage mutation
Anyone building tools that interact with browsers and needs full protocol visibility

It is not for people who just want to scrape a website. It is for people who need to understand the browser at the protocol level.

How to Run It

Whelmer is open source under the MIT license.

Build from source:

git clone https://github.com/Sumama-Jameel/whelmer.git
cd whelmer
cargo build --release
./target/release/whelmer

Or install from crates.io:

cargo install whelmer
whelmer

Then open a browser with remote debugging enabled:

# Chrome / Chromium
google-chrome --remote-debugging-port=9222

# Firefox (BiDi)
firefox --remote-debugging-port=9222

# Brave
brave --remote-debugging-port=9222

Whelmer auto-detects the browser, protocol, and port. Just run it.

GitHub link: https://github.com/Sumama-Jameel/Whelmer

Introducing: Validator. Know the value of what you are building. Deep validation for your idea - competitors, market size, audience, pivots, etc.

Sumama-Jameel — Tue, 01 Sep 2026 18:26:35 +0000

I built an open-source agent skill called Validator. It validates a product or project idea before you build it. It researches the market, finds every competitor, destroys your assumptions, and gives you a clear GO, CONDITIONAL GO, or NO GO verdict backed by sourced evidence.

Here is exactly what it does, why I built it, and how it works.

The Problem

Most people build things nobody wants.

They get an idea. They get excited. They spend three weeks coding it. Then they show it to the world, and nobody cares. Not because the code was bad. Because the problem was already solved, or the audience was wrong, or the moat was zero.

The real issue is that people skip validation. They validate with vibes. They say things like "I think people would want this" or "I could not find a competitor, so there must be none."

That is not validation. That is wishful thinking.

The other problem is that AI tools make it worse, not better. They can build your product faster, so you skip the thinking step entirely and go straight to shipping. You build the wrong thing in three hours instead of three weeks. The speed does not fix the problem. It makes the problem cheaper to repeat.

What Validator Does

Validator is an agent skill. You install it into your AI coding agent. Then you tell the agent:

"I have an idea for X. Validate it."

The agent then runs a 12-phase research process. It does not build anything. It does not write code. It researches.

When it is done, you get a single markdown file with a verdict.

The verdict is one of three things:

GO — build it. The evidence supports it.
CONDITIONAL GO — build it only if specific conditions are met. Those conditions are listed. A falsification test is included.
NO GO — do not build it. The evidence says it will fail.

There is no "it depends." There is no "maybe you could try." There is a decision.

The 12 Phases

Here is what Validator does, step by step:

Problem validation — does this problem actually exist? Is it painful enough?
Market research — how big is the market? Is it growing or shrinking?
Every single competitor — not just the famous ones. Enterprise, mid-size, startup, open source, side project. All of them.
Head-to-head feature comparison — what does each competitor have? What do they lack?
Destroying your own assumptions — "Our X feature is unique" gets checked against the market. If it is not unique, the skill says so in writing.
Gap analysis — where are the real openings? Are they worth pursuing?
Moat evaluation — what stops someone from copying you in a week? Rated objectively.
Outcome risk — what happens if you build it and nobody pays?
Platform policy check — does your product depend on a platform API or ToS that could break or get you banned?
Technical feasibility — can the core mechanic actually be implemented right now?
Final decision — GO, CONDITIONAL GO, or NO GO.
Pivot recommendations — if the idea fails, what adjacent thing might work?

The Rules That Make It Different

Validator has strict rules that most idea validation tools do not enforce.

One audience, forced.
"All businesses" is rejected. "Everyone" is rejected. "Small and medium companies" is rejected. Validator pushes until you pick ONE segment. Because if you build for five different buyers with five different budgets and five different pains, you solve nothing for anyone.

Every competitor, not just the famous ones.
Most people check for three competitors and stop. Validator checks enterprise tools, startups, open source projects, side projects, and anything else that solves the same problem. If a competitor exists, it gets listed with funding, revenue, pricing, employees, business model, and launch year.

Every claim carries a source URL.
No "trust me." No vibes. Every fact in the report has a source link on the line below it. Unverified assumptions are forbidden. If the agent cannot find evidence, it says so.

Data source priority.
When sources conflict, Validator uses a hierarchy: Government data wins over industry reports. Industry reports win over company filings. Company filings win over academic papers. Academic papers win over surveys. Surveys win over official docs. Official docs win over reviews. Reviews win over social media. Social media wins over blogs.

Falsification test for every CONDITIONAL GO.
If the verdict is CONDITIONAL GO, the report must state a specific, observable condition that would flip it to NO GO. Example: "NO-GO if a funded competitor launches a $0 version within 6 months." This is a written exit gate. Not a vibe.

Evidence saturation, not endless browsing.
Validator knows when it is done. It stops searching when results become repetitive, after 3 consecutive empty searches, or when no new high-value evidence appears. It does not waste time browsing forever.

What the Output Looks Like

The final report is a single markdown file called MAIN.md. It contains:

Market demand metrics with sources
Competitor tiers (enterprise, mid-size, startup, open source)
Problem-already-solved analysis
Head-to-head feature table
Moat table with objective ratings
Verdict (GO / CONDITIONAL GO / NO GO)
Build conditions (if CONDITIONAL GO)
Falsification test
Pivot recommendations
Full source list

The Honest Catch

Validator is not a magic oracle. It is a research process. It forces you to look at evidence instead of feelings. But the quality of the output depends on the quality of the AI agent running it and the search tools available to that agent.

If your agent has bad web search, the research will be shallow. If your agent hallucinates sources, the report will be unreliable. Validator enforces the process, but it cannot guarantee the agent's search results are perfect.

Also, Validator will kill your idea if the evidence says it should die. That is the point. But if you are emotionally attached to your idea, you will hate the output. That is also the point.

How to Install It

Validator is an Agent Skills-format skill. It is a folder with a SKILL.md file. It works in any tool that supports the Agent Skills format.

Clone it:

git clone https://github.com/Sumama-Jameel/validator.git
cd validator

Copy it into your agent's skills directory:

cp -r SKILL.md examples ~/.claude/skills/validator

Or install with the skills CLI:

npx skills add Sumama-Jameel/validator -g

Or install as a Claude Code plugin:

/plugin marketplace add Sumama-Jameel/validator
/plugin install validator@sumama-validator

Then just say:

"I have an idea for X. Validate it."

The skill triggers automatically when you propose a new project or ask whether an idea is worth building.

Who It Is For

Validator is for builders who want to stop wasting time on dead ideas.

It is for solo developers, startup founders, and engineers who build fast but need to check if the direction is right before they commit weeks of work.

It is not for people who want validation in the emotional sense. It will not tell you your idea is nice. It will tell you if it should exist.

It is open source under the MIT license.

GitHub link: https://github.com/Sumama-Jameel/Validator

Introducing: Grasper. Open-source book reading companion for technical and scientific books. No rushing, no summaries.

Sumama-Jameel — Tue, 01 Sep 2026 18:24:02 +0000

I built an open-source reading companion called Grasper. It helps you read hard science books one page at a time, understand each page properly, and only move forward when you actually get what you just read.

Here is what it is, why I built it, how it works, and what it does not do.

The Problem

People read hard books about physics, engineering, math, and computer science. They read a page, think they understand it, then move on. A day later, most of it is gone.

This is not a discipline problem. It is how memory works.

The forgetting curve is a well-known result. If you do not actively recall something, most of it fades very fast. On top of that, many people struggle to finish self-paced learning. More than 80% of people abandon non-mandatory self-paced courses. One of the main reasons is lack of structured support.

There is also a proven fix: testing yourself. Research shows that quizzing improves learning outcomes. It is not just about reading more. It is about checking understanding while you read.

Most AI reading tools do the opposite. They give you summaries. They make reading faster, but they do not make understanding deeper.

Grasper is different. It slows you down on purpose. It makes you understand one page before it lets you move to the next one.

What Grasper Does

Grasper is a reading tool for hard science books.

You open a book in PDF, EPUB, or plain text. Grasper shows you one page at a time. You read that page. Then you can ask Grasper to explain it.

When you click “Explain This Page”, Grasper creates a plain-language teaching document for that page.

It includes:

What the page is about
Why it matters
A worked example
How it works
Three common wrong ideas
A short study card

It does not give you a lazy summary. It teaches the page from first principles.

Then Grasper asks you five quick questions. These questions are tied to the explanation. You need to answer 4 out of 5 correctly on the first try before the next page unlocks.

If you get one wrong, it tells you which part you need to re-read.

This is the core of Grasper: read one page, understand it, prove that you understood it, then move on.

How It Works

The flow is simple.

Open a book.
Grasper parses it into pages.
You read one page.
You ask Grasper to explain that page.
Grasper sends that page to the AI provider you choose.
The AI returns a first-principles explanation and five questions.
You answer the questions.
If you pass, the next page unlocks.
If you fail, you re-read the weak part and try again.

Your progress is saved locally. If you close the app and open it later, you are exactly where you stopped.

Real Math Support

Hard science books have equations. A lot of reading tools treat equations like random text. That does not work for math, physics, or engineering.

Grasper renders equations properly using KaTeX.

It also has a button that explains each symbol in words. So if you see an equation and you do not know what a symbol means, you can check it directly.

This matters because equations are not decoration in these books. They are the actual content.

Diagram Support

Science books also use figures, graphs, and diagrams. Sometimes the figure is more important than the paragraph next to it.

Grasper can show the figure and use a vision model to explain what the picture means.

So you are not just looking at the diagram. You are learning what it is showing.

Understand Chat

Each page can have its own chat thread.

This chat is seeded with the page explanation. It follows the same teaching rules. You can ask follow-up questions about that page only.

This is useful when the explanation helps, but you still have one small confusion left. Instead of leaving the page with a gap in your understanding, you can clear it right there.

The chat survives restarts. It is saved locally.

Grasp Ledger

Grasper keeps a running note of concepts you have understood.

This is called the Grasp Ledger.

It tracks what you have learned so the tool can avoid repeating too much context. It also automatically trims itself so it does not grow too large.

The point is not just to read pages. The point is to build knowledge that stays with you.

Privacy Model

Your book stays on your machine.

Grasper does not upload your whole book to a server. It only sends the single page you are asking the AI to explain.

Your API key is also stored on your machine, not on some remote server.

You can use any OpenAI-compatible provider. So you choose the AI backend. You choose the key. You control what gets sent.

This matters for people reading personal textbooks, research PDFs, or copyrighted material they already own.

Under the Hood

Grasper is built mainly with Rust, Svelte, and Python.

The desktop app uses Tauri. The frontend uses Svelte. The local database uses SQLite.

The project is split into several parts:

grasper-core: shared types, equation extraction, parser traits
grasper-parser: PDF, EPUB, and TXT parsing
grasper-ai: OpenAI-compatible AI client, prompts, settings
grasper-memory: SQLite storage for progress, chat, and grasp ledger
grasper-cli: terminal tool
grasper-app: the desktop app built with Tauri and Svelte
scripts: Python-based PDF pipeline

The CLI lets you test each part from the terminal.

Commands include:

grasper parse
grasper explain
grasper equations
grasper diagrams
grasper chat

This makes it easier to debug parsing, explanation, math extraction, diagram explanation, and chat without opening the full app every time.

What Grasper Is Not

Grasper is not a speed-reading tool.

It is not a “summarize this book in five minutes” tool.

It is not a tool that gives you the illusion of learning.

If you want to skim a book, Grasper is not for you.

Grasper is for people who want to actually understand hard material. It is slower than normal reading. That is intentional. The slowness is the point.

Who It Is For

Grasper is for people reading:

Physics
Engineering
Math
Computer science
Other hard technical books

It is for self-learners, students, and engineers who want a private reading companion that forces real understanding.

The Honest Catch

Grasper depends on the AI model you choose. A better model gives better explanations. A weaker model gives weaker explanations.

Also, hard books are often messy. PDFs can have bad layouts, scanned pages, strange equations, or unclear figures. Parsing them perfectly is not always easy.

Grasper is also intentionally strict. If you do not pass the comprehension gate, you do not move forward. Some people will like this. Some people will hate it.

That is by design.

Final Point

Most AI tools make reading easier. Grasper makes learning stronger.

It keeps your book local. It explains one page at a time. It checks your understanding. It saves your progress. It supports real math, diagrams, and per-page chat.

It is open source.

GitHub link: https://github.com/Sumama-Jameel/grasper

Introducing: Mirage. Get free API for Qwen, Deepseek, ChatGPT, Gemini and other models. Without costing a cent or a heavy GPU.

Sumama-Jameel — Tue, 01 Sep 2026 18:17:37 +0000

Here is exactly why I built it, how it works under the hood, and the reality of using it.

The Problem
LLM APIs are expensive, and they go down a lot. OpenAI logged over 160 incidents in 9 months. When a critical AI dependency goes down, engineering teams just sit there. On top of that, every existing AI gateway on the market (like LiteLLM or Portkey) makes the same assumption: you have API keys and you are willing to pay per token. They just route your paid requests through another paid layer.

I did not want to pay per token, and I did not want to rely on their official API uptime.

How Mirage Works
Mirage bypasses the paid API layer entirely. It uses the exact same internal web APIs that power the chat interfaces you already use in your browser.

You just import your existing browser sessions. Mirage reads your cookies and localStorage from Chrome, Firefox, or Edge. It authenticates as you, and routes your code requests through those free internal endpoints. There is no middleman, no per-token billing, and no API key management.

Under the Hood
To make this work without getting blocked by anti-bot systems, Mirage has to look exactly like a real human using a real browser.

I wrote it in Rust. It uses a custom headless browser engine called Obscura. Obscura runs real JavaScript through V8, maintains a real DOM tree, and speaks the Chrome DevTools Protocol. More importantly, it presents real TLS and HTTP fingerprints so the providers think it is just a normal web browser. It is also about 12x faster and uses way less memory than standard headless Chrome.

Mirage keeps a pool of 10 warmed browser contexts in the background, each on its own OS thread. It has built-in circuit breakers, rate limiting, and exponential backoff so it does not spam the providers and get your account flagged.

What You Get

One local endpoint (runs on 127.0.0.1:3000).
75 models across 6 providers working right now (ChatGPT, DeepSeek, Gemini, Qwen, Mistral, Meta AI).
A drop-in replacement for any OpenAI client. It works natively with LangChain, LlamaIndex, and OpenWebUI.
Streaming, tool calling (via a custom Mirage Tool Protocol), web search, and file uploads.
A single binary. No Docker, no Python, no Node.js required to run it. You just compile it and run it.

The Honest Catch
I need to be completely transparent about how this works. Because Mirage relies on internal web APIs, it is a cat-and-mouse game. The providers are massive companies with huge engineering teams. If they change their web UI or their internal wire format, the adapter will break until it is fixed.

This is not a "set it and forget it" tool. This is why I open-sourced it. I need a community of developers who can capture the new network formats when they change and submit pull requests. If you use Mirage, you are joining that maintenance loop.

How to run it
It is fully open source under the Apache 2.0 license.

Clone the repo, build it with cargo build --release, and run the binary. Point your OpenAI client to http://127.0.0.1:3000/v1 and start making requests.

If you are building with AI and are tired of API costs and rate limits, give it a look.

GitHub link: https://github.com/Sumama-Jameel/Mirage

Nexus Engine: One command to Set Up a Complete production Environment

Sumama-Jameel — Tue, 21 Jul 2026 06:50:11 +0000

I’m 14 and I got tired of spending hours (sometimes days) setting up new machines. Different distros, different package managers, fragile shell scripts, no rollback.

So I built Nexus — a cross-platform environment provisioning engine. One command turns a fresh OS into a fully productive development machine.

The Problem

Setting up a dev machine is painful:

Hundreds of Linux distros with different package managers (apt, pacman, dnf, apk).
Shell scripts break easily with no rollback or state management.
Tools like Ansible are overkill for laptops. Docker doesn’t configure your host. Dotfile managers don’t install dependencies.

Result: Developers lose dozens of hours per year on setup issues.

What Nexus Does

One static Go binary. Detects your OS, chooses the right package manager, applies declarative YAML profiles, and handles everything with security gates and rollback.

No scripts. No manual steps. Works on Linux and Windows (with WSL2 support).

Standout Features

Cross-distro support — apt, pacman, dnf, apk behind one interface.
7-step orchestrator with rollback — PreFlight → Refresh → Execute → Verify → Audit. Failed foundation packages trigger full rollback.
Security gate (SanitizeAndExecute) — Allowlist, metacharacter rejection, timeouts. No raw shell execution.
10 built-in profiles — Go dev, Rust dev, Frontend, Data Science, Ethical Hacking, etc.
WSL2 setup in ~60 seconds on Windows.
Dotfiles + age-encrypted vault + Distrobox containers.
Community profile registry.
Optional Tauri GUI dashboard.

Architecture

Nexus is organized in bounded contexts:

BRAIN — Cobra CLI + core engine (Go)
DNA — YAML profiles with JSON Schema + struct validation + SHA256 integrity
BRIDGE — WSL2 handling (cross-compiled)
CONTAINER — Distrobox management
VAULT — age encryption
REGISTRY — Community profiles

Every command goes through a strict security gate. State is crash-safe with atomic writes and append-only logs.

Quick Start

# Install
go install github.com/Sumama-Jameel/nexus-engine/cmd/nexus@latest

# Initialize
nexus init

On Windows:

nexus wsl setup    # Full WSL2 setup
nexus wsl enter

Competitor Comparison

Tool	Static Binary	Cross-Distro	Security Gate	Rollback	WSL2	One-Command Init
Nexus	Yes	Yes	Yes	Yes	Yes	Yes
Ansible	No	Yes	No	No	No	No
Nix	No	Yes	No	Partial	No	No
chezmoi	Yes	Yes	No	No	No	No

Nexus combines the best ideas into one tool.

Why I Built It

The Linux desktop (and Windows-to-Linux migration) should be accessible to everyone — not just people who’ve memorized package manager flags. Nexus makes reproducible, secure dev environments simple.

Get Involved

Add or improve profiles
Test on your distro and open issues
Contribute to WSL2 or container features

GitHub: https://github.com/Sumama-Jameel/nexus-engine

What’s the most painful part of setting up a new dev machine for you? Have you tried tools like Nix or Ansible? I’d love your feedback.

SubZero: Privacy-First Subscription Detector (Open Source Alternative to Rocket Money)

Sumama-Jameel — Tue, 21 Jul 2026 06:47:38 +0000

I’m 14 and I built an open-source tool that finds every subscription in your bank statement — without Plaid, without storing your data, and without selling your financial history.

SubZero is a Next.js web app where you upload a PDF or CSV bank statement. It scans everything in memory and returns a detailed report of recurring charges, price hikes, and cancellation options.

The Problem

People waste hundreds of dollars every year on forgotten subscriptions. Commercial tools like Rocket Money and Trim solve this by connecting directly to your bank via Plaid — which means giving a third party your login credentials and full financial data.

That’s a privacy nightmare.

SubZero’s Approach

Upload → Scan in memory → Delete. No accounts. No persistent storage. Your data never leaves the server except in the response.

It uses 8 detection methods running in parallel for high accuracy:

Keyword + fuzzy matching (Fuse.js)
Time-delta and amount clustering
500+ vendor database (including local services like JazzCash, Daraz, Foodpanda)
Trigram index + Double Metaphone phonetic matching
Business/SaaS usage-based detection
Cross-report comparison for price hikes and cancellations

Key Features

Privacy by design — Zero data persistence. PII scrubbing (SSNs, account numbers, etc.).
Multi-format support — CSV + PDF (using mupdf).
Smart heuristics — Detects truncated vendor names, variable SaaS charges, and single-occurrence subscriptions.
Optional LLM — Only anonymized hints sent. Cancel URLs restricted to safe whitelist.
5-layer upload security — Validation, sanitization, magic bytes, size limits.
Multi-upload mode — Compare statements across months automatically.
One-click Vercel deploy — No database required.

Architecture Deep Dive

The core is a 10-stage pipeline:

Rate limiting + Upload validation (5 layers)
Parsing (CSV via Papaparse, PDF via mupdf)
PII scrubbing + bank detection
Heuristics Engine (8 parallel methods)
Confidence scoring (0-100 based on 8 signals)
Merge + deduplication
Enrichment (actions, health score A-F)
Optional LLM normalization
Report generation
Response (JSON + optional PDF export)

The entire engine lives in lib/audit/. It’s designed to be easy to extend with new heuristics or vendor patterns.

Security Model

Per-IP rate limiting
Zod schema validation at every boundary
Strict PII regex scrubbing
CSP, HSTS, and other security headers
Body size limits (max 11MB)

Competitor Comparison

Tool	Bank Login	Cost	Open Source	Privacy
SubZero	No	Free	Yes	Zero persistence
Rocket Money	Yes (Plaid)	$6–12/month	No	Full data shared
Trim	Yes (Plaid)	% of savings	No	Full data shared
SubFind	No	One-time	No	Closed source

SubZero gives you comparable detection power with actual privacy.

Tech Stack

Next.js + TypeScript + Tailwind
Zod for validation
Fuse.js, Trigram, Double Metaphone for matching
mupdf for PDF extraction
Deployable on Vercel with zero config

Get Involved

This project needs help expanding the vendor database (especially for non-US banks) and improving detection accuracy.

Try it here: Upload a statement and see what it finds.

GitHub: https://github.com/Sumama-Jameel/subzero

What’s the most annoying subscription tracking problem you’ve faced? Or if you’ve tried it, what did it miss or get right?

Scam Intelligence Network: One API for Threat Intelligence (URL, Email, Phone & Crypto)

Sumama-Jameel — Tue, 21 Jul 2026 06:44:24 +0000

I’m a 14-year-old builder. My first big project using AI was trying to commercialize a threat intelligence tool. I failed to sell it. So I open-sourced it instead.

Scam Intelligence Network (SIN) is an open-source “OpenRouter for threat intelligence.” One unified API to check suspicious URLs, emails, phone numbers, and crypto addresses against 1.43 million local records + 10+ external sources + optional LLM analysis.

The Problem

Cybercrime is exploding, but checking threats is fragmented and painful:

You need 10–12 different APIs (VirusTotal, AbuseIPDB, HIBP, EmailRep, IPQualityScore, etc.).
Each has different keys, rate limits, response formats, and pricing.
Most solutions are either expensive, closed-source, or lack coverage for all four vectors (URL + Email + Phone + Crypto).

This is especially hard for indie developers, small security teams, and self-hosted setups.

What Scam Intelligence Network Solves

One POST request. One consistent response format. Parallel checks. Smart fallback. Local-first design.

Key Highlights:

1.43 million local threat records — Instant offline detection (under 10ms). Skips external calls on matches.
10+ external sources checked in parallel using asyncio.gather().
Unified verdict engine with weighted scoring + rule-based overrides.
Circuit breakers and caching for reliability.
Full Docker deployment + CLI tool.
Privacy-first and self-hostable.

Core Architecture

The system follows a clean vertical-slice + layered design:

REST/CLI Layer → Analyzer Layer → Service Layer → Infrastructure Layer → Local Threat Data

Analyzer Layer — One folder per type (URL, Email, Phone, Crypto). Easy to extend.
Service Layer — Parallel calls to VirusTotal, AbuseIPDB, URLhaus, HIBP, IPQS, Groq LLM, etc.
Infrastructure — SQLite caching (with HMAC integrity), circuit breakers, rate limiting, API key auth.
Verdict Engine — Combines signals into HIGH/MEDIUM/LOW/CRITICAL with confidence scores.

Local blacklist check happens first — massive speed win and cost saver.

Main Features

Four analyzers behind a single /analyze endpoint.
Local + external + optional LLM reasoning (anonymized data only).
Quality gates and tiered confidence scoring.
Prometheus metrics, security headers, correlation IDs.
Analytics database for tracking queries.
Ready for monetization (tiered plans) but fully open source.

Quick Start

Docker (recommended):

git clone https://github.com/Sumama-Jameel/scam-intelligence-network.git
cd scam-intelligence-network
cp .env.example .env
docker-compose up -d

Test it:

curl -X POST http://localhost:8000/analyze \
  -H "X-API-Key: your-key" \
  -d '{"input": "https://suspicious-site.com", "input_type": "URL"}'

Or use the CLI:

python main.py "suspicious@example.com"

Why I Open Sourced It

I tried selling it and failed. Couldn’t find customers or explain the value clearly. But the code is solid and catches real threats. If even one person uses it to block a phishing attempt, it was worth releasing.

Threat intelligence shouldn’t be locked behind enterprise budgets.

Competitor Comparison

Tool	URL	Email	Phone	Crypto	Local DB	Open Source	Self-Hosted
SIN	Yes	Yes	Yes	Yes	1.43M	Yes	Yes
IPQualityScore	Yes	Yes	Yes	No	No	No	No
AlienVault OTX	Yes	No	No	No	No	Partial	No

No other open tool covers all four vectors with this level of local + parallel + resilient design.

Tech Stack & Design Choices

FastAPI + Python
SQLite for cache + analytics + auth
Asyncio for parallel checks
Vertical slice architecture for easy extension
Heavy focus on resilience (circuit breakers, caching, quality gates)

Get Involved

Run it locally or deploy on a cheap VPS.
Add new data sources or blocklists.
Share feedback or issues.

GitHub: https://github.com/Sumama-Jameel/scam-intelligence-network

What’s the biggest pain point you face with threat intelligence today — fragmented APIs, cost, or lack of coverage for certain vectors? Let me know in the comments.

Whelmer: Full-Visibility Browser DevTools for AI Agents

Sumama-Jameel — Tue, 21 Jul 2026 06:40:30 +0000

I’m a 14-year-old builder from Pakistan. After struggling with existing browser automation tools while building AI agents, I decided to create something better.

Whelmer is a Rust-based CLI tool that gives you complete, unfiltered access to everything a browser emits — across multiple protocols and browsers.

The Problem with Existing Tools

When you connect to a browser via CDP (Chrome DevTools Protocol), the browser fires hundreds of event types across 53 domains: Network, DOM, Console, Storage, Fetch, Security, and more.

Most agent frameworks and tools do one (or more) of the following:

Filter events aggressively
Hide protocol differences behind high-level abstractions
Only support Chrome CDP
Drop events they consider “unimportant”

This creates blind spots. You miss critical signals — like how an SPA handles auth tokens in localStorage, or subtle network patterns that reveal rate limiting logic.

Multi-browser support makes it worse. Firefox uses BiDi or its own FDP. Safari has its own protocol. Most tools pretend these differences don’t exist.

What Whelmer Does Differently

Whelmer shows everything.

Native support for CDP, BiDi, FDP, and Foxbridge (CDP-to-Firefox proxy)
Works out of the box with Chrome, Brave, Edge, Opera, and Firefox
A central EventBus with a 10,000-event ring buffer — nothing is dropped
Raw NDJSON streaming for easy piping into other tools/agents
Runtime domain management (enable/disable any of the 53 CDP domains)
Structured JSON output for all commands
Pure Rust static binary (~7MB) — no Node.js, no Python, no heavy dependencies

Key Features

Multi-protocol support — One binary, consistent event model across browsers.
Raw event firehose — Every WebSocket message is available. Use events --json and pipe to jq.
History replay — Access the last 10k events with events --history N.
Powerful commands:
- dom, eval, cookies, storage, network, screenshot, perf, etc.
- All support --json output.
Pluggable architecture — Easy to extend with new protocols or handlers.

Architecture Overview

Whelmer uses a clean pipeline:

WsConnection — Manages persistent WebSocket connection with command/response routing and timeouts.
EventBus — Broadcast channel + ring buffer. Every event reaches every consumer.
Display Consumer — Formats known events for terminal output.
Agent Consumer — For raw streaming and history queries.

This decoupling means the tool never silently drops data. You decide what matters.

Why I Built It

Whelmer was created for a specific use case: reverse-engineering the web interfaces of AI model providers. When OpenAI, Google, xAI, or others update their UIs or internal APIs, agent integrations break. Whelmer lets you see exactly what changed in real time.

It is also the foundation for RynoVider — my upcoming OpenAI-compatible API wrapper that routes through actual model web UIs.

Competitor Comparison

Tool	Protocols	Raw Events	History Buffer	Domain Toggle	Runtime
Whelmer	CDP + BiDi + FDP	Yes	10k events	Yes (53)	Rust
agent-browser (Vercel)	CDP only	No	No	No	Rust+Node
Puppeteer	CDP only	No	No	No	Node

Quick Start

# Install
cargo install whelmer

# Or from source
git clone https://github.com/Sumama-Jameel/Whelmer
cd Whelmer
cargo build --release

Launch your browser with remote debugging:

google-chrome --remote-debugging-port=9222

Then run:

whelmer

Future Plans

Safari WebKit support
Better integration as a library
Enhanced agent-friendly features for RynoVider

Whelmer is open source under MIT. Feedback, issues, and contributions are welcome.

→ GitHub Repository

What’s the most painful hidden browser behavior you’ve encountered while building agents? I’d love to hear your experiences in the comments.

I Spent a Year Setting Up New Machines. So I Built a Tool That Does It in One Command.

Sumama-Jameel — Thu, 11 Jun 2026 08:03:22 +0000

Every time I get a new laptop, the same thing happens. Day one. Fresh install. Nothing works the way I want it. No git. No Docker. No Node. No Vim config. Nothing. So I spend the next three hours Googling. "How to install Docker on Ubuntu." "How to set up WSL2 on Windows." "Why is my pacman command not found." Copy, paste, hope. Break something. Start over.

By the end of the day I have a machine that sort of works, but I'm not sure what I installed or whether any of it is set up right. And I know I'll go through the exact same thing next time. If you've ever set up a new machine, you know this feeling. It's not hard. It's just tedious, repetitive, and easy to get wrong.

I got tired of it. So I built "nexus-engine"(https://github.com/Sumama-Jameel/nexus-engine).

What It Does

You write a simple file that describes what you want on your machine. Then you run one command and it sets everything up.

That's it.

Here is what a setup file looks like:

name: my-setup
packages:
  - name: git
    category: foundation
  - name: curl
    category: foundation
  - name: docker
    category: tool
  - name: nodejs
    category: language

Run this:

nexus init

And it does the rest. Detects your OS, figures out which package manager to use, installs everything in the right order, and gives you a report when it's done.

It Works The Same Everywhere

This was the big one for me. I switch between Ubuntu, Arch, and Fedora depending on what I'm doing. Every distro has its own package manager. Different commands, different syntax, different package names.

nexus-engine handles all four major Linux package managers through one interface:

apt (Ubuntu, Debian)
pacman (Arch, Manjaro)
dnf (Fedora, RHEL)
apk (Alpine)

You write your setup file once. It works everywhere. You don't need to know which command belongs to which distro.

Windows Gets Linux in About a Minute

If you're on Windows and you want a Linux environment, normally you have to:

Enable WSL
Pick a distro
Download it
Import it
Configure wsl.conf
Set up your packages inside it

That's a lot of steps and a lot of places to go wrong.

With nexus-engine:

nexus wsl setup

It checks if your system is ready, downloads a Linux rootfs, imports it into WSL2, configures it with secure defaults, and you're in. About sixty seconds.

Then you can drop into your Linux environment anytime:

nexus wsl enter

If Something Breaks, It Cleans Up

This is the part that always got me with manual setup. You're installing ten things. Number seven fails. Now you have six things installed, one broken, and three that never got attempted. What do you do? Uninstall manually? Start over? Just live with it?

nexus-engine handles this differently. It installs things in priority order. Foundation packages first, then languages, then tools. If a foundation package fails, it removes everything it already installed that run. You're never left with a half-working setup.

It also checks things before it starts. Disk space, network connectivity, whether you have the right permissions. It tells you upfront if something is going to be a problem instead of failing halfway through.

You Can Share and Reuse Setups

I have a base setup that I use on every machine. Git, curl, a few essentials. Then I have specific setups for different projects. One for web development. One for data science. One for a particular client's stack.

nexus-engine lets you layer these on top of each other. A data science setup can extend the base setup. You only define what's different. The rest is inherited.

name: data-science
extends: base-dev
packages:
  - name: python3
    category: language
  - name: jupyter
    category: tool
  - name: pandas
    category: tool

You can also share setups with other people. Your team can use the same setup file. New team member joins, they run one command, they have the same environment as everyone else.

You Should Be Able to Trust It

Here's the thing about a tool that installs stuff on your machine. You need to trust it.

I thought about this a lot. So I made some decisions early on.

It doesn't run whatever it wants. Every command goes through a strict allowlist. If it's not on the list, it doesn't run. No shell metacharacters, no arbitrary execution, no surprises.

It checks setup files for tampering. Every profile gets a SHA256 integrity check. If someone modifies your setup file, nexus-engine will notice and refuse to use it.

Downloads are verified. When it downloads a Linux rootfs or a remote profile, it checks that what it received is what it expected. No man-in-the-middle surprises.

Your state is tracked. It keeps a record of everything it installed, when, and why. You can always see what's on your machine and where it came from.

Getting Started

It's a single binary. No dependencies. Download it and run.

# Install with Go
go install github.com/Sumama-Jameel/nexus-engine/cmd/nexus@latest

# Or download a binary from the releases page
# https://github.com/Sumama-Jameel/nexus-engine/releases

# Initialize your environment
nexus init

On Windows, the fastest path to Linux:

nexus wsl setup
nexus wsl enter

What's Next

This is v1.0.0. It works for my use case and I've been using it daily. But I built it in the open because I want it to work for more people.

Things I'm thinking about:

More rootfs options for WSL2
A community directory of shared setups
Better Windows support beyond WSL
Package managers I haven't covered yet

If any of this sounds useful to you, check it out:

github.com/Sumama-Jameel/nexus-engine

Apache 2.0, fully open source. Read the code, open an issue, tell me what's missing. I want this to be something people actually trust to run on their machines. That bar is high and I want to clear it.