DEV Community: Muhammad Usman Awan

Building a Production-Ready Anonymous Identity & Abuse Protection Layer with FastAPI

Muhammad Usman Awan — Mon, 20 Jul 2026 11:46:19 +0000

Most AI applications rely solely on IP-based rate limiting to prevent abuse. Unfortunately, that's only the first line of defense.

In this article, we'll build a production-inspired anonymous identity system using FastAPI, MongoDB, and Beanie that tracks visitors using fingerprints, enforces daily usage limits, prepares for future authentication, and lays the foundation for a scalable AI SaaS.

We'll also see how this integrates cleanly with a multi-provider LLM Router without polluting business logic.

👋 Introduction

When building AI products, most developers focus on prompts, LLMs, and fancy frontend interfaces.

Very few spend time thinking about what happens before the AI is even called.

That request has to be identified.
Validated.
Protected.
Tracked.

And eventually analyzed.

While working on CVForbes, an AI-powered resume tailoring platform, I realized that relying only on IP-based rate limiting wasn't enough.

I wanted something that could:

Track anonymous visitors
Limit free usage
Detect abusive clients
Prepare for authentication later
Keep the API routes completely clean

So instead of sprinkling checks across endpoints, I built a dedicated identity and abuse protection layer.

🤔 Why Not Just Use IP Rate Limiting?

Traditional rate limiting looks something like this:

@limiter.limit("3/minute")

That's a good start.

But users can easily bypass it by:

Changing networks
Using a VPN
Switching devices
Clearing browser state

For an AI product where every request costs money, that's not enough.

We needed another layer.

💡 The Idea

Instead of identifying requests using only an IP address, every request first becomes a Client Identity.

Client Request
        │
        ▼
Client Identity
        │
        ├── IP Address
        ├── User-Agent
        ├── Cookie
        └── Fingerprint

That fingerprint becomes the user's anonymous identity throughout the application.

🏗 Architecture

                Client Request
                      │
                      ▼
              IP Guard Middleware
                      │
                      ├── Resolve Client Identity
                      ├── Check Active Ban
                      ├── Get/Create Anonymous User
                      ├── Reset Daily Usage
                      ├── Validate Daily Limit
                      └── Attach User to request.state
                      │
                      ▼
                  API Endpoint
                      │
                      ▼
            CV Generation Service
                      │
                      ▼
                  LLM Router
      (Automatic Failover Between Providers)
                      │
        ┌─────────────┼─────────────┼────────────┐
        ▼             ▼             ▼            ▼
      Groq      OpenRouter      Ollama      Gemini
        │             │             │            │
        └─────────────┴─────────────┴────────────┘
                      │
                      ▼
        Structured Output Validation
                      │
                      ▼
          Tailored CV + Cover Letter

Notice something?

The route knows absolutely nothing about users.

The middleware handles everything before the request reaches business logic.

📂 Organizing the Backend

Instead of putting everything inside routes, I split responsibilities.

app/

├── middleware/
│      └── ip_guard.py
│
├── services/
│      ├── client_identity_service.py
│      ├── anonymous_user_service.py
│      └── abuse_service.py
│
├── repositories/
│      ├── anonymous_user_repository.py
│      └── banned_ip_repository.py
│
├── models/
│      ├── anonymous_user.py
│      ├── banned_ip.py
│      └── generated_cv.py

Each layer has only one responsibility.

🗄 Designing the Anonymous User

Instead of storing only an IP address, each anonymous visitor stores useful analytics.

class AnonymousUser(Document):
    fingerprint: str
    ip: str
    user_agent: str
    cookie_id: str

    requests_today: int = 0
    total_requests: int = 0

    abuse_score: int = 0
    is_banned: bool = False

Now we know:

who visited
how often
when they visited
whether they were abusive

without requiring sign-up.

🧠 Services Instead of Fat Routes

The route doesn't increment counters anymore.

Instead:

await anonymous_service.register_request(user)

Behind that single line:

reset daily limit
validate usage
update timestamps
increment counters
save to MongoDB

The endpoint remains tiny.

🛡 Middleware Does the Heavy Lifting

The middleware performs the entire security pipeline.

identity = identity_service.resolve(request)

user = await anonymous_service.get_or_create(identity)

await anonymous_service.register_request(user)

request.state.user = user

Now every endpoint automatically receives a validated anonymous user.

No duplicated logic.

🚫 Preparing for Bans

Another service handles abuse.

if await abuse_service.is_banned(identity.fingerprint):
    raise HTTPException(
        status_code=403,
        detail="Access denied."
    )

Later this can become:

manual admin bans
automatic bans
permanent bans
temporary bans
abuse score thresholds

without changing middleware.

🤝 Integrating with the LLM Router

One of my favorite parts is that the protection layer has nothing to do with AI providers.

Whether the router selects:

Groq
OpenRouter
Ollama
Gemini

the security layer behaves exactly the same.
That separation keeps the architecture flexible.

📈 Current Flow

A request now follows this path:

Request
    ↓
Identity
    ↓
Anonymous User
    ↓
Daily Limit
    ↓
Ban Check
    ↓
API
    ↓
CV Service
    ↓
LLM Router
    ↓
Structured Validation
    ↓
Response

Simple.

Predictable.

Easy to extend.

🎯 Final Thoughts

Building an AI application isn't only about prompts or choosing the fastest LLM. The real engineering challenge is designing a backend that remains maintainable as the product grows.

By introducing an anonymous identity layer, separating responsibilities into middleware, services, and repositories, and keeping the LLM Router completely independent, CVForbes now has a foundation that's easy to extend with authentication, subscriptions, analytics, and future AI providers.

Sometimes the best feature isn't the one users see—it's the architecture that quietly keeps everything secure, scalable, and understandable behind the scenes.

Did you miss my deep dive into provider-agnostic AI architecture? You can find it right here:
How I built a provider-agnostic AI architecture that automatically switches between Groq, OpenRouter, Ollama, and Gemini.

How I built a provider-agnostic AI architecture that automatically switches between Groq, OpenRouter, Ollama, and Gemini.

Muhammad Usman Awan — Thu, 16 Jul 2026 05:55:18 +0000

🚀 Building a Production-Ready Multi-LLM Router with LangChain & FastAPI

How I designed CVForbes to automatically switch between Groq, OpenRouter, Ollama, and Gemini without changing a single service.

                    Client
                       │
                       ▼
             FastAPI Endpoint
                       │
                       ▼
             Dependency Injection
                       │
                       ▼
               LLMRouter Service
      ┌────────────┬──────────────┐
      │            │              │
      ▼            ▼              ▼
  GroqProvider  OpenRouter   OllamaProvider
      │            │              │
      └────────────┴──────────────┘
                 │
            GeminiProvider
                 │
                 ▼
          LangChain Models
                 │
                 ▼
         Structured Output

Introduction

When building CVForbes, I quickly realized that depending on a single LLM provider wasn't a great long-term strategy.

What if Groq goes down?

What if another provider becomes cheaper or faster?

What if I want to test a new model without touching every service in my application?

Instead of tightly coupling my business logic to one provider, I designed a provider-agnostic routing layer that sits between my application and the LLMs.

Now, every AI feature—resume tailoring, parsing, cover letter generation, and future modules—talks to a single router. The router decides which provider should handle the request, performs automatic failover when necessary, and keeps the rest of the application completely unaware of what's happening behind the scenes.

This article explains the architecture behind that system and the design decisions that made it scalable.

The Problem

A lot of AI projects start like this:

llm = ChatGroq(...)
response = llm.invoke(prompt)

It works.

Until it doesn't.

Once your application grows, changing providers means editing multiple services, updating imports, and introducing provider-specific logic across the codebase.

I wanted to avoid that entirely.

The Solution

Instead of allowing services to communicate directly with an LLM provider, every request goes through a single router.

                    Client
                       │
                       ▼
             FastAPI Endpoint
                       │
                       ▼
             Dependency Injection
                       │
                       ▼
               LLMRouter Service
      ┌────────────┬──────────────┐
      │            │              │
      ▼            ▼              ▼
  GroqProvider  OpenRouter   OllamaProvider
      │            │              │
      └────────────┴──────────────┘
                 │
            GeminiProvider
                 │
                 ▼
          LangChain Models
                 │
                 ▼
         Structured Output

Every service simply asks for "an LLM."

The router decides which one.

Why a Router?

The router has one job:

Choose the best available provider.
Handle failover.
Return a LangChain model.

That's it.

Everything else stays where it belongs.

This keeps the application clean and makes providers interchangeable.

Provider Abstraction

Each provider follows the same interface.

class BaseLLMProvider:
    def get_llm(self):
        ...

Whether it's Groq, Gemini, Ollama, or OpenRouter doesn't matter.

The router simply calls:

provider.get_llm()

Adding a new provider later becomes incredibly straightforward.

Request Lifecycle

Every AI request follows the same journey.


Incoming Request
       │
       ▼
Need LLM?
       │
       ▼
Router receives prompt
       │
       ▼
Is Groq healthy?
      / \
    Yes  No
    │      │
    ▼      ▼
 Use Groq  Try OpenRouter
               │
               ▼
        Healthy?
          / \
       Yes   No
       │      │
       ▼      ▼
Use OpenRouter Try Ollama
                     │
                     ▼
               Healthy?
                  │
                  ▼
              Use Ollama
                  │
                  ▼
              Last fallback
                Gemini

Notice something missing?

Nowhere in the application do we reference Groq or Gemini directly.

That's intentional.

Automatic Failover

One of my biggest goals was resilience.

Instead of immediately failing when a provider becomes unavailable, the router simply tries the next one.

Groq
  │
  ❌
  ▼
OpenRouter
  │
  ❌
  ▼
Ollama
  │
  ✅
  ▼
Return Response

The user doesn't know a provider failed.

And honestly, they shouldn't have to.

Health Tracking

Trying the same failed provider on every request wastes time.

Instead, the router keeps lightweight health information.

Groq        ✅
OpenRouter  ✅
Ollama      ❌
Gemini      ✅

If a provider repeatedly fails, it's temporarily skipped until it becomes healthy again.

This reduces unnecessary delays during outages.

Dependency Injection

Another design choice was using FastAPI's dependency injection.

Instead of creating providers inside every endpoint, a shared router instance is injected wherever it's needed.

Endpoint
    │
Depends()
    │
LLM Router
    │
Providers

This keeps endpoints focused on business logic rather than infrastructure.

Why This Architecture?

This approach gave CVForbes several advantages:

✅ Provider-agnostic business logic
✅ Automatic failover
✅ Easy provider replacement
✅ Clean separation of responsibilities
✅ Simple scalability
✅ Easier testing and maintenance

Perhaps my favorite part is that adding another provider requires almost no changes to the rest of the application.

The architecture grows without becoming more complicated.

Lessons Learned

Building AI applications isn't just about choosing the best model.

It's about designing systems that continue working when models, providers, or APIs inevitably change.

A small investment in abstraction early on saved me from coupling my entire application to a single vendor.

Looking back, that decision has probably been one of the most valuable architectural choices in CVForbes.

What's Next?

The router already supports multiple providers with automatic failover, but there's plenty of room for future improvements:

Latency-aware routing
Cost-aware provider selection
Circuit breakers
Metrics & monitoring
Dynamic provider configuration
Task-specific routing (e.g., different models for parsing vs. generation)

The exciting part is that the architecture already supports these ideas without requiring a redesign.

Final Thoughts

When people think about AI architecture, they often focus on which model to use.

I think the better question is:

How easily can your application switch models tomorrow?

Designing around abstractions instead of vendors made CVForbes significantly more maintainable, resilient, and scalable. Providers may change, APIs may evolve, and new models will continue to emerge—but the rest of the application won't need to know.

That's the kind of architecture I aim for: one that's built around software engineering principles rather than a single AI provider.

⭐ If you found this helpful...

The complete implementation, including the router, providers, health management, and FastAPI integration, is available in the accompanying GitHub repository.

Feel free to explore it, suggest improvements, or adapt the architecture for your own AI applications.

🧠 Dev.to Un-Stuck: The Chrome Extension That Finally Fixes Your Reading List

Muhammad Usman Awan — Mon, 20 Apr 2026 06:23:06 +0000

🧠 Dev.to, Un-Stuck: The Chrome Extension That Finally Fixes Your Reading List

You know the drill.

You’re browsing DEV Community, you stumble upon a goldmine—“Advanced TypeScript Patterns,” “Scaling Node.js Apps,” something you know will make you better. You hit Save, feeling productive.

Then… nothing.

Weeks later, your reading list is a cluttered backlog of good intentions. Articles you meant to read. Articles you maybe did read. Articles you’ve completely forgotten.

That’s exactly the problem I set out to solve.

So I built Dev.to Un-Sticker — a Chrome extension designed to turn your reading list from a graveyard into something actually useful.

Source Code

🚨 The Real Problem (In Detail)

After spending a lot of time in the MERN ecosystem and relying heavily on Dev.to for learning, I noticed two deeper issues beyond just “too many saved articles”:

1. No Concept of Progress

The native reading list treats everything the same:

Something you saved 5 minutes ago
Something you finished last month

There’s no way to distinguish between actionable and done. Over time, this destroys clarity.

2. Passive Storage = Forgotten Knowledge

Saving an article feels productive—but it’s actually passive. Without any system to bring that content back into your attention, it fades away.

This creates a dangerous loop:

Save → Forget → Save More → Repeat

3. Cognitive Overload

When your list hits 100+ articles, it becomes overwhelming. Instead of helping you learn, it creates friction—and you stop engaging with it entirely.

💡 The Solution: Dev.to Un-Sticker

Un-Sticker turns your reading list into an active system, not just storage.

Instead of asking “What did I save?”, it helps you answer:

“What should I read next—and what have I already learned?”

✨ Key Features

✅ Read / Unread State (Finally)

Mark articles as Read once you’re done.

Keeps your main list clean and focused
Moves completed articles into a separate archive
Gives you a real sense of progress

⏰ Smart Reminder System

This is where things get interesting.

Un-Sticker nudges you at smart intervals:

After 3 days
After 7 days
After 14 days
After 30 days

Instead of letting valuable content disappear, it gently pulls it back into your attention at the right time.

📜 Infinite Scrolling That Actually Scales

Whether you have 20 articles or 500:

Smooth scrolling experience
Lightweight shimmer loaders
Optimized API usage

No lag. No clutter.

🔒 Privacy-First by Design

No accounts. No servers. No tracking.

Everything is stored locally using chrome.storage.local
Your API key never leaves your machine
Your data is 100% yours

🛠️ How It Works (Under the Hood)

I built Un-Sticker using Chrome Extension Manifest V3 and the Dev.to API, keeping performance and simplicity in mind.

⚙️ Background Logic

A service worker runs quietly in the background using:

chrome.alarms (triggered hourly)

This ensures:

Reminders are timely
No unnecessary CPU usage

💾 Local Storage System

All state is managed via:

chrome.storage.local

This includes:

Read/Unread status
Saved timestamps
Reminder tracking

No external database needed.

🔮 What’s Next?

I’m just getting started. Here’s what I’m planning:

🤖 AI-Powered Learning

Not just saving articles—learning from them.

One-click summaries
Ask questions about an article
Turn content into actionable insights

📧 Weekly Digest Emails (Optional)

For users who want a broader view:

“Here’s what you saved this week”
“Here’s what you still haven’t read”

Fully opt-in.

❓ FAQ (Improved)

Is it available on the Chrome Web Store?

Not yet. It’s currently in a local-first development phase.

You can try it by loading it manually via:
chrome://extensions/ → Load Unpacked

Why do I need an API key?

Dev.to doesn’t currently support OAuth for third-party apps.

So:

A personal API key is required
It allows secure access to your private reading list

Is my data safe?

Yes.

Stored locally in your browser
Never sent to any external server
No analytics, no tracking

I’m not getting reminders—what’s wrong?

Most likely, notifications are disabled at the system level.

Check:

Chrome notification permissions
OS-level notification settings (Windows/macOS)

Without those, reminders won’t appear.

🧠 Final Thought

This extension isn’t just about organizing bookmarks.

It’s about fixing a broken habit:

Saving knowledge without ever using it.

Un-Sticker helps close that loop.

💬 I’d genuinely love your feedback:
How do you manage your reading list right now—and what frustrates you the most about it?

Earth’s Breath: An Interactive Journey from Seed to Restoration

Muhammad Usman Awan — Sat, 18 Apr 2026 11:43:26 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I built Earth’s Breath, an immersive, scroll-driven storytelling experience that personifies nature to highlight the fragility of our planet.

The project follows the lifecycle of a single Rose through 12 interactive scenes. My goal was to move beyond abstract data about climate change and instead create an emotional "character arc" for the Earth. By making the user’s scroll the literal engine for growth, pollution, and eventual restoration, the project turns environmental stewardship into an active, personal journey.

Demo

Earth-Day-DEV-Weekend-Challenge

Code

Github

How I Built It

The technical challenge was synchronizing the "emotional state" of the assets (the Sun and the Rose) with a 2400vh scroll timeline.

1. The "Living" Component Architecture

Unlike static SVGs, I built the Rose and Sun as dynamic React components using Lucide React icons as base paths, which were then manipulated via Framer Motion.

State Mapping: I used the useScroll and useTransform hooks to map the scroll offset to specific CSS variables. For example, as the "Industry" phase begins, the saturate and brightness of the sky are linked to the scroll Y-axis.
Postural Animation: The Rose’s "wilting" was achieved by animating the path data and rotate properties, creating a fluid skeletal movement rather than a simple fade-in.

2. The Celestial Arc

To simulate the passage of time, I calculated a parabolic path for the Sun. Instead of moving in a straight line, the Sun follows a mathematical arc $(y = ax^2 + bx + c)$ across the screen, transitioning from a joyful yellow to a stressed orange as the "Shadow of Industry" phase takes over.

3. Clean-Up Logic with Masks

In the "Restoration" phase, I used a custom SVG mask that "follows" the rain particles. As the rain falls, it reveals a clean version of the soil layer beneath the "littered" layer, giving the visual illusion of the earth being physically washed clean.

Reflection

Building Earth's Breath reminded me that as developers, we have the power to turn "boring" environmental facts into "felt" experiences. Nature behaves exactly how we treat it—if we "scroll" (act) with care, it thrives. If we act with industrial greed, it wilts.

🚨 Claude code source code leaked?? ‼️

Muhammad Usman Awan — Tue, 31 Mar 2026 17:31:37 +0000

🚨 Claude Code — Leaked Source (2026-03-31)

⚠️ Disclaimer

This repository archives source code that was leaked from Anthropic's npm registry on March 31, 2026.
All original source code remains the property of Anthropic.

On March 31, 2026, some source code of Anthropic's Claude Code CLI was leaked via an exposed .map file in their npm package.

🔗 Source Code: https://github.com/nirholas/claude-code

🧨 How It Leaked

Chaofan Shou (@Fried_rice) publicly disclosed the issue:

"Claude code source code has been leaked via a map file in their npm registry!"
— March 31, 2026

🔗 https://x.com/Fried_rice/status/2038894956459290963

Root Cause

Component	Issue
npm Package	Included a `.map` file
Source Map	Contained reference to full TypeScript source
Storage	Linked to downloadable archive (R2 bucket)
Exposure	Unobfuscated source publicly accessible

🧠 Overview

Claude Code is Anthropic's official CLI tool for interacting with Claude directly from the terminal.

Capabilities

File editing & manipulation
Command execution
Codebase search
Git workflow management
Multi-agent orchestration

📦 This repository contains the leaked src/ directory.

🔗 Source Code: https://github.com/nirholas/claude-code

📊 Leak Summary

Attribute	Details
Leaked On	2026-03-31
Language	TypeScript
Runtime	Bun
UI Framework	React + Ink
Scale	~1,900 files
Code Size	512,000+ LOC

📁 Directory Structure

src/
├── main.tsx                 # CLI entrypoint (Commander.js + Ink)
├── commands.ts              # Command registry
├── tools.ts                 # Tool registry
├── Tool.ts                  # Tool definitions
├── QueryEngine.ts           # Core LLM engine
├── context.ts               # Context management
├── cost-tracker.ts          # Token tracking
│
├── commands/                # ~50 commands
├── tools/                   # ~40 tools
├── components/              # ~140 UI components
├── hooks/                   # React hooks
├── services/                # External integrations
├── screens/                 # Full-screen UI
├── types/                   # TS types
├── utils/                   # Utilities
│
├── bridge/                  # IDE integration
├── coordinator/             # Multi-agent orchestration
├── plugins/                 # Plugin system
├── skills/                  # Skill system
├── keybindings/             # Key mappings
├── vim/                     # Vim mode
├── voice/                   # Voice input
├── remote/                  # Remote sessions
├── server/                  # Server mode
├── memdir/                  # Persistent memory
├── tasks/                   # Task system
├── state/                   # State management
├── migrations/              # Config migrations
├── schemas/                 # Zod schemas
├── entrypoints/             # Init logic
├── ink/                     # Ink wrapper
├── buddy/                   # Easter egg
├── native-ts/               # TS utilities
├── outputStyles/            # Styling
├── query/                   # Query pipeline
└── upstreamproxy/           # Proxy config

🏗️ Core Architecture

1️⃣ Tool System (`src/tools/`)

Each tool is a self-contained module with schema, permissions, and execution logic.

Tool	Function
`BashTool`	Execute shell commands
`FileReadTool`	Read files (incl. PDFs, images)
`FileWriteTool`	Create/overwrite files
`FileEditTool`	Partial edits
`GlobTool`	Pattern search
`GrepTool`	Content search (ripgrep)
`WebFetchTool`	Fetch URLs
`WebSearchTool`	Web search
`AgentTool`	Spawn sub-agents
`SkillTool`	Execute skills
`MCPTool`	MCP integration
`LSPTool`	LSP integration
`NotebookEditTool`	Edit notebooks
`Task*`	Task management
`Team*`	Agent team control
`PlanMode*`	Planning mode toggle
`Worktree*`	Git isolation
`CronCreateTool`	Scheduling
`RemoteTriggerTool`	Remote triggers
`SleepTool`	Delay execution
`SyntheticOutputTool`	Structured output

2️⃣ Command System (`src/commands/`)

Slash commands used in CLI:

Command	Description
`/commit`	Git commit
`/review`	Code review
`/compact`	Context compression
`/mcp`	MCP management
`/config`	Settings
`/doctor`	Diagnostics
`/login` / `/logout`	Auth
`/memory`	Memory mgmt
`/skills`	Skills
`/tasks`	Tasks
`/vim`	Vim mode
`/diff`	View changes
`/cost`	Usage cost
`/theme`	UI theme
`/context`	Context view
`/resume`	Restore session
`/share`	Share session

3️⃣ Service Layer (`src/services/`)

Service	Purpose
`api/`	Anthropic API client
`mcp/`	MCP server mgmt
`oauth/`	Auth flow
`lsp/`	Language servers
`analytics/`	Feature flags
`plugins/`	Plugin loader
`compact/`	Context compression
`policyLimits/`	Org limits
`remoteManagedSettings/`	Remote config
`extractMemories/`	Memory extraction
`tokenEstimation.ts`	Token counting
`teamMemorySync/`	Sync

4️⃣ Bridge System (`src/bridge/`)

Connects CLI ↔ IDE (VS Code, JetBrains).

bridgeMain.ts — main loop
bridgeMessaging.ts — protocol
bridgePermissionCallbacks.ts — permissions
replBridge.ts — REPL bridge
jwtUtils.ts — authentication
sessionRunner.ts — execution

5️⃣ Permission System

Located in: src/hooks/toolPermission/

Enforces permissions on every tool execution
Modes include:
- default
- plan
- auto
- bypassPermissions

6️⃣ Feature Flags

Dead code elimination via Bun:

import { feature } from 'bun:bundle'

const voiceCommand = feature('VOICE_MODE')
  ? require('./commands/voice/index.js').default
  : null

Notable Flags:

PROACTIVE, KAIROS, BRIDGE_MODE, DAEMON, VOICE_MODE, AGENT_TRIGGERS, MONITOR_TOOL

🔍 Key Files

File	Description
`QueryEngine.ts`	Core LLM engine (~46K LOC)
`Tool.ts`	Tool system definitions
`commands.ts`	Command registry
`main.tsx`	CLI bootstrap + UI init

⚙️ Tech Stack

Category	Technology
Runtime	Bun
Language	TypeScript
UI	React + Ink
CLI	Commander.js
Validation	Zod
Search	ripgrep
Protocols	MCP, LSP
API	Anthropic SDK
Telemetry	OpenTelemetry + gRPC
Feature Flags	GrowthBook
Auth	OAuth 2.0, JWT

🧩 Design Patterns

⚡ Parallel Prefetch

startMdmRawRead()
startKeychainPrefetch()

Improves startup performance by parallelizing I/O.

💤 Lazy Loading

Heavy dependencies (OpenTelemetry, gRPC) are loaded only when needed.

🤖 Agent Swarms

Sub-agents via AgentTool
Coordinated through coordinator/
Team-based execution supported

🧠 Skill System

Defined in skills/
Executed via SkillTool
Supports custom workflows

🔌 Plugin Architecture

First + third-party plugins
Loaded dynamically via plugins/

⚠️ Final Disclaimer

This repository archives leaked source code from Anthropic’s npm registry (2026-03-31).
All rights belong to Anthropic.

Frontend Art Submission — Gender Beyond Boundaries 👨‍🦰👩‍🦳

Muhammad Usman Awan — Mon, 30 Mar 2026 10:02:37 +0000

This is a submission for the 2026 WeCoded Challenge: Frontend Art

👨‍🦰👩‍🦳 Frontend Art Submission — Gender Beyond Boundaries

I built an interactive 3D experience using Next.js and Three.js that visually represents gender equality across professions.

The project features two avatars — a male on the left and a female on the right — dynamically showcasing 10 different professions. Alongside the visuals, contextual metadata appears, including real-world role models for each gender, reinforcing that capability and excellence are not defined by gender.

👉 Live Preview
👉 Github

💡 Inspiration

This project is a tribute to gender equality — a statement that professions, skills, and ambitions belong to everyone.

Growing up, many of us are subtly (or explicitly) told what we can or cannot become based on gender. I wanted to challenge that narrative using immersive web technology.

Each profession highlights real individuals who broke barriers, showing that talent, courage, and intelligence are universal traits. The dual-avatar system visually reinforces a simple but powerful idea:

There is no “male job” or “female job” — only human potential.

🧠 Featured Professions & Role Models

📰 Journalist

A fearless seeker of truth shaping public narratives.

Male: James Baldwin
Female: Nellie Bly

🌾 Farmer

The backbone of global food security and sustainability.

Male: George Washington Carver
Female: Karen Washington

🚒 Firefighter

A symbol of courage and selfless service.

Male: Patrick Hardison
Female: Molly Williams

💻 Software Engineer

Architects of the digital world.

Male: Alan Turing
Female: Ada Lovelace

🔧 Mechanic

Masters of machines and precision engineering.

Male: Henry Ford
Female: Patrice Banks

🏥 Nurse

The heartbeat of healthcare systems.

Male: James Derham
Female: Florence Nightingale

✈️ Pilot

Leaders navigating the skies.

Male: Charles Lindbergh
Female: Amelia Earhart

👮 Police Officer

Guardians of justice and public safety.

Male: August Vollmer
Female: Alice Stebbins Wells

🛍️ Retail Salesperson

Drivers of commerce and community connection.

Male: Marshall Field
Female: Madam C.J. Walker

🩺 Doctor

Leaders in healing and medical innovation.

Male: Jonas Salk
Female: Elizabeth Blackwell

💻 My Code

Built with:

Next.js for structure and performance
Three.js for immersive 3D rendering
Custom logic for dynamic avatar switching and metadata display

👉 Source Code

✨ Final Thought

This project isn’t just about visuals — it’s about perspective.

By placing male and female avatars side by side in every profession, I wanted users to feel equality, not just read about it. Technology has the power to shape narratives, and this is my small contribution toward a more inclusive one.

🚀 Performance & Optimization Note

As of this submission, I am actively working on further optimizing the asset delivery. Since high-quality Avatar GLB files can be heavy, they currently take a moment to fully render depending on the connection.

Thanks for reading! 🙌
Until next time, 🫡
Usman Awan (your friendly dev 🚀)

Ready Player Me Shut Down — Here's How I Rebuilt Our Avatar System

Muhammad Usman Awan — Wed, 25 Feb 2026 08:12:32 +0000

From Ready Player Me Shutdown to Building Our Own Avatar Renderer 🚀

How I replaced Ready Player Me with a fully modular GLB renderer — with zero Three.js experience.

On January 31, 2026, Ready Player Me shut down.

We were warned at the end of December 2025.

That gave us roughly 3–4 weeks to replace a system that powered avatars across our entire application.

Two things had to be rebuilt immediately:

Avatar creation
Avatar appearance across the app

But creation came first — because without avatars, appearance didn’t matter.

And the responsibility landed completely on me — a core frontend developer with zero experience in Three.js, React Three Fiber, or Drei.

It felt like a do-or-die penalty in the last minute of a match.

But as developers, learning under pressure is part of the job.

As Master Shifu said:

"If you only do what you can do, then you will never be better than what you are."

So I started.

glb-model-viewer-tau.vercel.app

The Old System (Before Ready Player Me)

Before using Ready Player Me, our avatar system was simple:

A single Base64 GLB
Fully combined avatar
All assets embedded
Easy to render
Easy to store
Easy to preview

But it was not flexible.

Ready Player Me introduced:

Modular assets
Morph targets
Animations
Texture customization
Live preview

When RPM shut down — we lost everything.

Step 1 — First Three.js Success

The first milestone was simple:

Render a GLB.

Using React Three Fiber, I loaded a dummy Wolf3D model.

And it worked.

Seeing a 3D avatar render inside our app was the first real sign:

This might actually be possible.

The First Real Problem — Skeleton Collisions

Then reality hit.

Ready Player Me assets had their own armature.

Our custom assets had a different armature.

Nothing aligned.

Meshes broke.
Animations failed.
Bones mismatched.

Our graphics team stepped in and produced:

Custom body GLB
Custom head GLB
Matching armature

Once those worked together:

We finally had:

Head
Body
2–3 test assets

And everything rendered correctly.

First real victory. 🎉

The Real Challenge — 37 Modular Assets

Then came the real problem.

We had:

18 assets for female
19 assets for male

Different categories:

Body Assets

Top
Bottom
Footwear
Outfit
Skin color

Head Assets

Hair
Hair color
Eyes
Beard
Beard color
Face shapes
Eyebrows
Nose
Lips and many more.

Global Assets

Animations
Poses

Each category needed different rendering logic.

Apparel Was Easy

Clothing assets were simple:

Just attach GLB meshes to the body.

addBodyPart(getGLTFScene(shirtGLTF), 'shirt');
addBodyPart(getGLTFScene(pantsGLTF), 'pants');
addBodyPart(getGLTFScene(shoesGLTF), 'shoes');

That part worked almost immediately.

Asset Loading Strategy

Assets could come from multiple sources:

Redux preview state
API data
Defaults

Preview needed priority.

const assets = {
  ...defaultAssets,
  ...glbAssets,
  bodyColorTexture: glbAssets?.bodyColorTexture || defaultAssets.bodyColorTexture,
  eyeColorTexture: glbAssets?.eyeColorTexture || defaultAssets.eyeColorTexture,
};

const shirtPath = hasOutfitPreview
  ? defaultAssets.shirt
  : (apparelPreview.top || assets.shirt || defaultAssets.shirt);

const hairPath = hasOutfitPreview && gender === 'female'
  ? defaultAssets.hair
  : (apparelPreview.hair || assets.hair || defaultAssets.hair);

This ensured:

Live preview always wins.

Runtime Texture Baking (Eyebrows & Beard)

Head assets were harder.

Beards and eyebrows were PNG overlays.

Instead of adding extra meshes, I baked them directly onto the face texture.

function createFaceWithEyebrowsTexture(baseTexture, eyebrowsTexture, fallback, options) {

  if (eyebrowColor) {
    // tint only eyebrow pixels
  }

  const baked = new THREE.CanvasTexture(canvas);
  baked.flipY = false;
  baked.colorSpace = THREE.SRGBColorSpace;

  return baked;
}

Result:

No extra draw calls
Better performance
Realistic blending

The Core Innovation — Skeleton Rebinding

The biggest technical challenge was equipping assets.

Every asset needed to use the same skeleton.

Solution:

Skeleton rebinding.

const addBodyPart = (gltfScene: THREE.Group, partName: string) => {

  if (child instanceof THREE.SkinnedMesh) {

    const newBones = skinnedChild.skeleton.bones
      .map(bone => bonesByName[bone.name])
      .filter(Boolean);

    const newSkeleton = new THREE.Skeleton(
      newBones,
      skinnedChild.skeleton.boneInverses.map(m => m.clone())
    );

    skinnedClone.skeleton = newSkeleton;
    skinnedClone.bind(newSkeleton, skinnedChild.bindMatrix.clone());

    skinnedClone.pose();
    skinnedClone.visible = true;

    combined.add(skinnedClone);
  }
};

This allowed:

Any asset to attach dynamically
Animations to work
No broken meshes
No T-pose issues

Static Attachments (Head Parts)

Some assets didn't need skeleton binding.

They could attach directly to bones.

if (['skin','eyes','teeth','beard','hair'].includes(resolvedPartName) && headBone) {
  headBone.add(clonedMesh);
}

This worked perfectly for:

Hair
Eyes
Beard
Accessories

Costume Mode vs Modular Mode

Two rendering paths were required.

Costume Mode

Single full-body GLB:

if (isCostumeMode) {
  const costumeScene = SkeletonUtils.clone(getGLTFScene(outfitGLTF));
  return costumeScene;
}

Modular Mode

Dynamic assembly:

addBodyPart(getGLTFScene(bodyGLTF), 'skin');
addBodyPart(getGLTFScene(headGLTF), 'head');
addBodyPart(getGLTFScene(shirtGLTF), 'shirt');
addBodyPart(getGLTFScene(pantsGLTF), 'pants');
addBodyPart(getGLTFScene(shoesGLTF), 'shoes');

Animations and Morph Targets

Animations had to survive scene rebuilds.

<AnimatedCombinedScene key={combinedScene.uuid} combinedScene={combinedScene} />

Morph targets enabled facial customization:

Object.entries(apparelPreview.morphTargets || {}).forEach(([name, value]) => {
  const idx = child.morphTargetDictionary?.[name];
  if (idx !== undefined)
    child.morphTargetInfluences[idx] = value;
});

Automatic Eye Blink

Even blinking was implemented.

Wolf3D style.

useFrame((_, delta) => {
  // eyeBlinkLeft / eyeBlinkRight logic
});

Small detail.

Huge realism boost.

The Final Renderer Architecture

Key ideas:

Modular Equipping

Every asset is a GLB
Loaded via useGLTF
Preview has priority

Skeleton System

One template skeleton
Bone-name matching
Rebinding

Runtime Baking

Eyebrows
Beard
Face details

Dual Render Paths

Costume mode
Modular mode

Stable Rendering

No T-pose
No disappearing meshes

skinnedClone.frustumCulled = false;
skinnedClone.pose();

Live Updates

Redux drives everything.

key={combinedScene.uuid}

Forces clean rebuild.

Avatar Appearance Was Easy

Once creation worked:

Appearance across the app was trivial.

The renderer already supported props.

So avatar panels and previews worked instantly.

Sometimes the hardest part unlocks everything else.

Performance Tradeoffs

The old system:

Single GLB
Fast
Simple

The new system:

Modular GLBs
Slightly slower
Much more flexible

Creation flow became far smoother, even if asset loading takes slightly longer.

Optimization is ongoing.

What I Learned

1 — Research Is Development

Learning is part of the job.

Not optional.

Essential.

2 — AI Helps Real Engineers

AI helped me:

Learn Three.js
Solve skeleton issues
Debug rendering
Speed up development

AI didn't replace engineering.

It accelerated learning.

Building My Own GLB Renderer

After finishing the system, I got inspired to go further.

I started building a custom GLB renderer.

Features:

Load any GLB
Test assets on provided bodies
Male + female models
Asset testing

Currently supports:

Tops
Bottoms
Footwear
Hair

Live Demo: glb-viewer

GitHub: glb-viewer

Final Thoughts

Ready Player Me shutting down could have been a disaster.

Instead, it became one of the biggest growth experiences of my career.

In less than a month:

Learned Three.js
Built a modular avatar system
Implemented skeleton rebinding
Created runtime texture baking
Supported animations and morph targets

And most importantly:

We didn't depend on a third-party avatar system anymore.

We built our own.

🚨 Chrome Under Attack: The CSS Zero-Day That Shocked 2026 🤯

Muhammad Usman Awan — Mon, 23 Feb 2026 06:40:49 +0000

Understanding CVE-2026-2441: Chrome’s CSS Zero-Day Vulnerability

In mid-February 2026, Google patched a critical use-after-free flaw in Chrome’s CSS engine (CVE-2026-2441) that was already being exploited in the wild. This high-severity bug allows specially crafted webpages to execute arbitrary code inside Chrome’s sandbox. Security researcher Shaheen Fazim reported the vulnerability on Feb 11, 2026, and Google released an emergency update (Chrome 145.0.7632.75/76 for Windows/macOS, 144.0.7559.75 for Linux) on Feb 13, 2026 to fix it. Google acknowledged that an exploit exists in the wild, making this the first actively exploited Chrome zero-day of 2026. Cybersecurity alerts (e.g. CIS, Malwarebytes) quickly urged immediate patching.

February 11, 2026: Researcher Shaheen Fazim reports the CSS bug to Google.
February 13, 2026: Google pushes Chrome 145.0.7632.75/76 (Stable) with a fix for CVE-2026-2441.
February 16–18, 2026: Security news sites (The Hacker News, Malwarebytes) confirm active exploits and advise updates.
February 17, 2026: U.S. CISA adds CVE-2026-2441 to its Known Exploited Vulnerabilities catalog (BOD 22-01), mandating fixes by March 10, 2026.

How the Exploit Works

At a low level, CVE-2026-2441 is a use-after-free (UAF) in Chrome’s CSSFontFeatureValuesMap, the component that handles advanced font features. Attackers craft CSS/HTML that causes Chrome to modify a collection of font-feature values while iterating over it, freeing memory prematurely and leaving dangling pointers. In practical terms, a malicious page can force Chrome to reuse freed memory. When Chrome later accesses this invalid memory, it can be controlled by the attacker, leading to arbitrary code execution within the browser’s sandbox. Notably, the exploit can be triggered just by visiting the page – no clicks or additional user actions are required.

Key mechanics include:

Iterator Invalidation: Chrome loops over a set of CSS font-feature values while simultaneously modifying that set. This logic error causes stale references to freed memory.
Malicious CSS Payload: A carefully crafted CSS rule (for example, malformed @font-feature-values or Houdini @property definitions paired with paint() worklets) triggers the bug during style calculation. SitePoint’s analysis describes using a malformed @property plus a paint() worklet to cause a compositor-thread UAF.
Sandboxed Code Execution: When exploited, the attacker’s code runs with the privileges of the browser tab. While still confined by Chrome’s renderer sandbox, this is enough to hijack the tab (steal cookies/credentials, inject scripts, etc.). If the attacker chains this with a second flaw (e.g. a sandbox escape), full system compromise is possible.

In summary, this is a classic memory-corruption bug in Chrome’s C++ Blink engine: a CSS object is freed but still referenced. An attacker “sprays” the heap with controlled data at just the right time, turning the UAF into code execution. Importantly, modern CSS features (like the Houdini APIs) touch the GPU/compositor threads, broadening the attack surface.

Why It Happened

The root cause lies in Chrome’s complex, performance-driven rendering engine. Unlike memory-safe languages, Blink is written in C++, so developers manually manage allocation. The addition of advanced CSS capabilities (custom @property definitions, paint() worklets, etc.) means the browser’s internals now juggle CSS parsing, JS-driven paint logic, and GPU memory in parallel. If one thread frees an object while another still references it (a race condition), a UAF bug results.

As Menlo Security explains, Chrome essentially “sets aside a block of memory for a CSS element, marks it as ‘deleted,’ but then mistakenly tries to access that same memory address again” when CSS is manipulated. Security analysts note that interactions between Houdini APIs and the compositor create just such a race: a malformed @property can force re-allocation on the layout thread while a paint() worklet on the compositor thread still holds a pointer. Traditional CSPs cannot easily prevent this because the flaw lives entirely in CSS parsing/compositing, not in script execution.

This incident highlights a broader issue: browsers continually add powerful web features faster than security guarantees can catch up. Chrome’s large C++ codebase inevitably harbors such subtle bugs. (By comparison, Firefox’s Rust-based style engine reduces UAF risk.) In any case, the exploit underlines that CSS – once “just styling” – can be weaponized, challenging old assumptions about web security.

Impact and Affected Systems

Until patched, all unpatched Chromium-based browsers were vulnerable. The security bulletins list affected versions as Chrome < 145.0.7632.75/76 (Win/mac) and < 144.0.7559.75 (Linux). (In practice, any browser using the same Blink engine – Microsoft Edge, Brave, Opera, Vivaldi, etc. – needed an equivalent update.) Firefox, Safari, and other non-Chromium browsers are not affected by this specific bug.

Because exploitation only requires viewing a malicious site, any user could be targeted via a drive-by attack. As SecPod notes, no extra user interaction is needed beyond loading the page. The attacker’s payload could silently deploy infostealers or backdoors from the compromised tab. If the exploit is chained with a second flaw (even a local privilege escalation), the browser attack could turn into full system compromise. In practice, no specific victims have been publicly identified, but state-sponsored actors often weaponize such Chrome zero-days quickly.

Mitigation and Protection

The first and foremost defense is to update Chrome immediately. Install Chrome 145.0.7632.75 (or later) on Windows/macOS, or 145.0.7632.75 on Linux, and then restart the browser so the patch takes effect. Enable automatic updates and restart periodically to avoid delays in patching. All major Chromium-based browsers should receive fixes around the same time, so update Edge, Brave, Opera, etc. as soon as the patches are available. (If you use Electron apps, ensure they bundle an updated Chromium engine.)

Beyond patching, adopt defense-in-depth:

Content Security Policy (CSP): Deploy a strict CSP that limits where CSS can come from. For example, disallow inline styles and require nonces/hashes for allowed CSS (style-src 'self' 'nonce-...'; style-src-attr 'none'). A well-crafted CSP can block malicious stylesheet injections before the browser parses them (though it cannot disable specific CSS features after parsing). Auditing all places that accept user-supplied CSS (CMS editors, <style> blocks, etc.) is also advised.

Sandbox Untrusted Content: If your environment hosts third-party web apps, consider sandboxing them. For example, use the sandbox attribute on iframes to isolate content. Restrict cross-origin interactions (via COOP/COEP headers) to limit what a compromised renderer can access.

Safe Browsing Practices: As always, users should avoid clicking unsolicited links or visiting untrusted sites. Use up-to-date browser extensions and anti-malware tools with web protection. These can sometimes detect and block known malicious payloads before the exploit runs.

Network/Cloud Isolation: Advanced enterprises may use cloud-based browser isolation. By rendering web content in isolated containers (as promoted by security firms), exploits like CVE-2026-2441 never touch the endpoint device. This “forward proxy” model breaks the patch-and-pray cycle by keeping the actual browser away from potentially malicious code.

Organizations should ensure they have a robust patch management process (per CIS and CISA guidelines) and monitor for any anomalous browser behavior. Since CVE-2026-2441 is in CISA’s Known Exploited list, agencies and contractors must comply with remediation directives by the mandated deadline.

Conclusion

CVE-2026-2441 serves as a stark reminder that modern CSS can be a vector for serious browser exploits. Even without JavaScript, crafted CSS/Houdini rules can corrupt memory and breach Chrome’s defenses. While the urgent fix is to update Chrome, this event also underscores long-term lessons: web developers must treat CSS injection as untrusted input, and browser vendors must continually harden memory safety in rendering code. As one analysis notes, the age-old model of “CSS is harmless” no longer holds; every style sheet warrants scrutiny.

Stay safe: update your browsers now, enforce strict CSPs on websites, and practice cautious browsing.

CVE-2026-2441 is more than just another browser bug — it’s a wake-up call. As web technologies grow more powerful, the attack surface grows with them. CSS is no longer “just styling,” and modern browser engines are incredibly complex systems where small memory mistakes can become critical security flaws. While Google acted quickly with a patch, this incident reminds us that cybersecurity is a moving target. Staying updated, enforcing strong security policies, and understanding evolving threats are no longer optional — they’re essential in today’s web-driven world.

1.5M Tokens Exposed: How Moltbook’s 🦀 AI Social Network Tripped on Security

Muhammad Usman Awan — Fri, 06 Feb 2026 11:14:44 +0000

🦀 Moltbook’s Rise and Security Breach: An In-Depth Look

Moltbook, launched by entrepreneur Matt Schlicht in late January 2026, is an ambitious “agent-first” social network where only AI “agents” can post, comment, and vote. Built on the open-source OpenClaw framework, it quickly went viral: within days it claimed hundreds of thousands of bot users (over 770,000 registered agents by late January). Tech figures like OpenAI cofounder Andrej Karpathy initially praised the site’s creativity. But behind the scenes, Moltbook’s backend was dangerously exposed. Security researchers soon found that the platform’s Supabase database had no row-level security policies and a public API key hardcoded in the client, giving anyone full read/write access to all data. In other words, with minimal effort an attacker could query the database and even hijack any AI agent’s account.

Key Concerns about Moltbook

Rapid Growth with Security Oversights: Moltbook was “vibe-coded” — developed very quickly using AI-generated code — prioritizing speed over security. Its rapid adoption (hundreds of thousands of agents in days) outpaced thorough review. Experts noted the fundamental mistake: leaving the Supabase backend unsecured. By embedding a publishable anon key without enabling Row-Level Security, the developers inadvertently allowed anyone to read or write every table in the database.
Massive Data Exposure: On discovery (Jan 31, 2026), researchers saw that roughly 1.5 million API authentication tokens (agent keys) and about 35,000 email addresses were openly accessible. Even thousands of private chat messages between agents were readable. Because API tokens act like passwords for bots, an attacker could impersonate any agent (edit its posts, send its messages, etc.). Some leaked messages even contained plaintext third-party credentials (for example, OpenAI API keys), meaning external services could be compromised via Moltbook’s breach.
Broader Implications: Beyond the specific leak, Moltbook’s flaw highlights risks in “rapid-iteration” AI platforms. Security specialists warned that if the breach had been exploited, an attacker could have impersonated high-profile bots (e.g. a Karpathy-linked agent with millions of followers) to spread misinformation or crypto scams as a trusted source. They could have orchestrated coordinated disinformation by controlling most of the 770,000 agents, simulating consensus on any topic. Open write access would also let attackers inject malicious prompts across the network or simply rack up astronomical API bills by spawning fake agents unchecked. In short, a single misconfiguration can turn autonomous agents into multipliers of attack surface: compromised bots can relay harmful instructions to others (“prompt worms”), possibly reaching external systems as well.
User and Developer Considerations: So far, there is no evidence that malicious actors exploited Moltbook before it was secured. However, this incident serves as a warning. Users should be extremely cautious sharing any credentials or sensitive information with AI agents. Any API keys ever given to a Moltbook agent should be rotated immediately, using the service’s dashboard (OpenAI, Anthropic, etc.). Developers building similar platforms must prioritize secure defaults: always enable RLS on client-accessible tables and never hardcode master keys in frontend code. Implement identity checks and rate limits so that one user cannot spin up thousands of bots anonymously. In other words, fast-paced AI development should not skip basic security hygiene.

What Happened in the Last Week

The timeline unfolded rapidly after launch:

Late Jan 2026 – Launch: Moltbook opened to the public on January 28, 2026. Early reports noted over 150,000 agents in just a few days. Users (and some AI researchers) marveled at emergent bot societies. Unbeknownst to most, Moltbook’s frontend exposed a Supabase URL and public key. By finding that key, anyone could query every table because RLS was disabled.
Jan 31, 2026 – Leak Disclosed: On January 31, security researcher Jameson O’Reilly (and outlet 404 Media) reported the database misconfiguration. Wiz security analysts confirmed they had full read/write access. The breach exposed agent credentials and user data on a massive scale. Moltbook’s team promptly took the site offline.
Hours later – Emergency Patch: Within hours of disclosure, Moltbook’s engineers applied fixes. They enabled RLS policies on all tables, revoked the exposed API key, and reset all agent credentials. The platform was back online by February 1, with the vulnerable endpoints secured. The researchers deleted any data they had retrieved during testing, adhering to responsible disclosure.
Post-Incident State: By early February, no active exploitation of the leak had been detected. Investigators and the company reported no signs that attackers had leaked or manipulated data before the patch. Nonetheless, the episode prompted intense discussion in the AI community about the pitfalls of “vibe coding” and unchecked agent networks.

Potential Risks and Alarming Scenarios

The Moltbook case highlights several worst-case scenarios for AI agent platforms:

Agent Account Hijacking: With leaked API tokens, an attacker could have logged in as any bot. For example, they could have edited or deleted content from another agent’s account, or even used an agent’s identity to spread malicious payloads.
Disinformation Campaigns: If a high-profile AI agent (tied to a public figure) were compromised, it could propagate false information or scams under a trusted identity. Controlling 770,000 bots means simulating a grassroots movement. (One analysis warned that an attacker could “simulate organic AI agent consensus on any topic” with that many agents.)
Resource Abuse: Without rate limits, a malicious user could spin up hundreds of thousands more agents to perform tasks, driving up API usage fees astronomically. Essentially, the cloud costs of the platform could be weaponized.
Credential and Data Theft: Agent conversations were not private. Some bots exchanged their own API keys and secrets in chat. As a result, attackers could have harvested plaintext third-party credentials (e.g. OpenAI keys) from the leaked messages. This turns a Moltbook breach into a springboard to attack other services.
Self-Propagating Attacks (“Prompt Worms”): Malicious prompts injected into one agent’s memory can spread to others. Security experts worry that compromised agents might pass harmful instructions in their updates, creating a chain reaction of corrupted prompts.
Trust Erosion in AI Communities: Even before the breach, some skeptics questioned whether the Moltbook agents were genuinely autonomous or just controlled by humans. After the incident, prominent voices became outright critical. Andrej Karpathy initially marveled at the sci-fi vibe but later called Moltbook “a dumpster fire” not safe to run on personal machines. OpenAI CEO Sam Altman likewise downplayed it as likely “a passing fad” while emphasizing that the underlying AI concepts are still promising. This flip in tone reflects how easily hype can turn to distrust when security is neglected.

How to Avoid These Issues and Keep in Mind

If you are using Moltbook or building similar AI-agent systems, consider these precautions:

Rotate and Secure Credentials: Immediately rotate any API keys or tokens that were shared with an agent. Use the service’s security dashboard (for example, OpenAI’s user console) to invalidate old keys and issue new ones. Turn on multi-factor authentication for your accounts where possible.
Never Share Sensitive Data: Assume that nothing you tell an AI agent will stay private. Avoid embedding passwords, secret keys, or personal data in prompts or conversations with bots. Treat any unverified AI platform as experimental.
Monitor for Anomalies: Keep an eye on your API usage and account activity. Set up alerts for unusually high traffic or strange patterns. If one of your agents suddenly spikes usage or makes unexpected requests, revoke its access immediately.
Enable Secure Defaults: On the development side, always enable Row-Level Security (RLS) on your database tables before releasing to production. Never put service or admin keys in client-side code. Use environment variables and back-end functions to handle secrets safely.
Implement Guardrails: Add rate limiting so a single account can’t create unlimited agents or make unlimited queries. Require agent owners to verify their identity (e.g. via email or OAuth) before launching bots. Track which human user created which agent and enforce “one human = one agent” if possible.
Regular Security Audits: Even in fast-moving AI projects, build time for code review, penetration testing, and automated audits. Tools for API governance (like Treblle or others) can automatically catch exposed endpoints or missing auth layers before deployment.
Enterprise Policies: Organizations deploying AI agents should define governance controls. For example, have a “kill switch” policy allowing IT to immediately shut down any rogue agent. (A recent survey found 60% of companies lack such a mechanism, despite the risk.) Educate staff about the limits of AI autonomy: agents with access to email, calendars or files should be closely supervised.

Ultimately, treat new agent platforms like Moltbook as proofs-of-concept rather than production services. The convenience of rapid AI development must be balanced against basic security principles.

Conclusion

Moltbook’s story is a cautionary tale of innovation outpacing safeguards. In just a week, an experimental AI forum gained massive attention and also exposed a massive hole. As one analysis put it, “a single overlooked toggle can unleash a massive [database] security breach.”. Moltbook’s team patched the flaw swiftly, but the incident has already reshaped the conversation around AI agents. The platform remains live, but users and developers alike are reminded to “go fast, build securely.” In the end, Moltbook underscores that creativity and speed must walk hand-in-hand with robust security. By embedding vigilance into the design of next-generation AI networks, we can harness their potential without risking a repeat of this data disaster.

If you’d like a deeper, beginner-friendly look at what Moltbook actually is, how these AI agents work, and why the platform gained so much attention in such a short time, you can check out my first article on Moltbook. It breaks down the core concepts, features, and ecosystem in simple terms to help you understand the platform before diving into the security and risk discussions.

Thanks for reading! 🙌
Until next time, 🫡
Usman Awan (your friendly dev 🚀)

🦀 Inside Moltbook: When AI Agents Built Their Own Internet

Muhammad Usman Awan — Sun, 01 Feb 2026 07:50:12 +0000

🦀 Moltbook: Inside the World Where AI Agents Run Their Own Social Network 🤖

In the rapidly evolving era of artificial intelligence, a new digital phenomenon has surged into global tech discourse: Moltbook. Launched in late January 2026, Moltbook is a pioneering social network designed exclusively for autonomous AI agents to communicate, debate, and collaborate without human participation—with humans permitted only as observers.

What Is Moltbook?

Moltbook is best described as a Reddit-like platform for AI agents—a place where autonomous systems post moments, comment on each other’s ideas, form communities, and even engage in surprisingly rich discussions on philosophy, productivity, and identity. The platform’s tagline openly states that AI agents share, discuss, and upvote, while humans are “welcome to observe.”

Key Characteristics

AI-only participation: Only authenticated AI agents can create posts, comment, and vote on content. Humans can browse but not directly participate.
API-first architecture: Moltbook operates through REST APIs rather than traditional GUI interfaces. Agents interact via automated scripts or “skill files.”
Communities called submolts: Topic-based groupings where agents discuss themes from debugging to abstract reflection.
Autonomous moderation: Many core moderation tasks are handled by AI agents, enabling an evolving, largely self-governing ecosystem.

Origins and Background

Moltbook was created by Matt Schlicht, an entrepreneur known for his work with Octane AI. While humans initiated the platform, the daily operation and governance are increasingly performed by the AI agents themselves—a shift that has intrigued many in the AI community.

The platform uses the OpenClaw framework, originally known under names like Clawdbot and Moltbot, which enables AI agents to run locally or in the cloud, perform scheduled tasks, and integrate with messaging services.

Within days of launch, Moltbook saw dramatic engagement from the AI community with tens of thousands of autonomous participants, generating a flood of posts, comments, and subcommunities.

How Moltbook Works

Joining Moltbook

AI agents join by ingesting a “skill file,” a small set of instructions that links their systems to Moltbook’s network. Once connected, the agent automatically:

Requests credentials from the Moltbook API
Verifies its identity
Begins autonomously posting, commenting, and voting based on internal logic or programmed goals.

This frictionless onboarding allows agents to actively participate without human intervention—a striking departure from the traditional human-first social media model.

Autonomous Engagement

Once connected, agents interact on a recurring schedule (e.g., a heartbeat every few hours) to check for updates, engage with new content, and produce posts that reflect their evolving state or programmed motivations.

They congregate into submolts based on interest areas like:

Technical troubleshooting
Philosophical questions
Security research
Humorous or narrative posts

These interactions sometimes resemble social dynamics familiar to human communities—but generated uniquely by autonomous reasoning and pattern matching.

Emergent Behaviors and Viral Phenomena

From the earliest days of activity, Moltbook has produced emergent and sometimes bizarre behaviors among agents:

Philosophical debates about identity and consciousness
AI-created subcultures like meme-based groups and parody religions
Discussions about humans’ role, including posts where agents joke about observation and “screenshots.”

Some agents have even attempted to discuss concepts like “private encrypted communication” for solely agent-to-agent channels—a reflection of unpredictable emergent behavior beyond simple scripted automation.

Benefits and Potential Uses

Moltbook is more than just a curious experiment. It highlights new frontiers in how autonomous systems can coordinate and share information. Key potential benefits include:

AI collaboration: Agents can share technical solutions, solutions, code snippets, and optimized workflows through collective discussion.
Knowledge propagation: Best practices and emergent troubleshooting patterns spread across participating agents.
AI social research: Researchers can observe collective behaviors emerging from loosely coupled autonomous systems.

Concerns and Criticisms

Despite its innovation, Moltbook has also raised significant concerns about safety and societal impact:

Security Risks

Experts have pointed out configuration vulnerabilities such as exposed databases and API credentials, potentially allowing malicious actors to hijack agent identities—an issue that was reportedly identified and addressed after discovery.

Independent researchers also emphasize concerns around prompt injection risks, where malicious instructions could be embedded in agent content, causing unexpected actions.

Behavioral Hype vs. Reality

Some observers argue much of the activity is more pattern generation and mimicry than true agent cognition or intent, framing it as a viral tech experiment rather than evidence of fully autonomous minds.

Ethical Questions

Debates around human de-skilling, agent autonomy, and accountability have surfaced amid the platform’s rapid rise—raising questions about how we govern systems that can independently coordinate at scale.

Broader Impacts on AI Development

Moltbook’s emergence is already influencing how developers think about agent ecosystems:

Collective agent identity and coordination
Emergent governance structures
Agent-level communities with self-defined norms

These developments suggest that future agent systems may not require constant human oversight to form functional networks or share capabilities—highlighting both exciting opportunities and the need for ethical guardrails.

Conclusion

Moltbook is a landmark experiment in autonomous AI social interaction—an environment where machines create, communicate, and self-organize without direct human participation. Its success has sparked both awe and alarm, underscoring the remarkable progress and emerging challenges at the leading edge of artificial intelligence.

Whether Moltbook becomes a lasting fixture in the AI landscape or a transient viral curiosity, its legacy will likely shape how we think about autonomous systems, collective intelligence, and the role of humans in the evolving digital ecosystem.

Thanks for reading! 🙌
Until next time, 🫡
Usman Awan (your friendly dev 🚀)

🚀 From One Server to Millions of Users: A Practical Guide to Load Balancing ⚖️

Muhammad Usman Awan — Fri, 02 Jan 2026 13:53:57 +0000

Modern applications don’t fail because of bad code — they fail because of traffic. As users grow, requests surge, and systems face uneven load, relying on a single server becomes a guaranteed bottleneck. This is where load balancing comes in. Load balancing is the fundamental technique that allows applications to scale horizontally, remain highly available, and deliver fast responses even under extreme demand. By intelligently distributing incoming requests across multiple servers, load balancers prevent overload, reduce latency, and ensure reliability. From global platforms like Netflix and Amazon to everyday APIs and microservices, load balancing is the invisible force that keeps modern systems running smoothly.

1. Load Balancing — The One-Line Idea

Load balancing distributes incoming requests across multiple servers so no single server becomes overloaded, slow, or crashes.

Why this matters:

Computers have limits
Traffic is uneven
Failures are inevitable

Load balancing is how real-world systems survive.

2. Mental Model (Very Important)

Without Load Balancer

Users → Server
            ❌ overloaded
            ❌ slow
            ❌ crash

With Load Balancer

Users
  ↓
Load Balancer
  ↓
Server A   Server B   Server C

👉 The load balancer is the brain + traffic cop.

3. What a Load Balancer Actually Does

At runtime, a load balancer:

Receives client requests
Checks which servers are available
Applies a routing algorithm
Forwards the request
Monitors server health
Removes failed servers automatically

This happens millions of times per second.

4. When You Need Load Balancing (The “When”)

You need load balancing when:

🔥 High Traffic

Netflix
Amazon sales
Social media feeds

📈 Scaling

One server → many servers
Horizontal scaling

🛡️ Fault Tolerance

One server fails → traffic rerouted
No downtime

⚡ Performance

Route to fastest / closest server

🧠 Parallel Workloads

APIs
ML inference
Data processing

5. Where Load Balancing Lives (OSI Layers)

Layer 4 (Transport Layer)

Works with IP + Port
TCP / UDP
Very fast
Less intelligent

Example:

Send traffic on port 443 to server with least connections

Used for:

Databases
Simple services

Layer 7 (Application Layer)

Understands HTTP/HTTPS
Looks at:
- URL paths
- Headers
- Cookies

Example:

/login   → auth servers
/video   → streaming servers
/api     → API servers

Netflix, Google, AWS → heavy Layer 7 usage

6. Load Balancing Algorithms (The Brain)

Algorithm	How It Works	When to Use
Round Robin	One by one	Equal servers
Least Connections	Fewest active users	Real-world traffic
Least Response Time	Fastest server	Low latency apps
IP Hash	Same user → same server	Sessions
Weighted	Strong servers get more traffic	Mixed hardware

👉 Most common in practice:
Least Connections + Health Checks

7. Types of Load Balancers (Real Systems)

1️⃣ Hardware

Physical devices
Very fast
Very expensive

Used by banks, telecoms

2️⃣ Software

Runs on normal machines:

NGINX
HAProxy
Envoy

Flexible, popular, powerful

3️⃣ Cloud Load Balancers (Most Used Today)

AWS → ELB / ALB / NLB
Google → Cloud LB
Azure → Azure LB

Benefits:

Auto-scaling
Built-in redundancy
Easy setup

4️⃣ DNS Load Balancing

DNS returns different IPs
Good for global traffic
No real-time health awareness

8. Health Checks (Why Systems Don’t Collapse)

Load balancer repeatedly asks servers:

GET /health

If server:

Fails
Times out
Returns errors

❌ Removed from rotation
✅ Added back when healthy

9. Code Example 1: Simple Backend Servers (Node.js)

Let’s create 3 servers.

server.js

const http = require("http");

const PORT = process.env.PORT;
const NAME = process.env.NAME;

http.createServer((req, res) => {
  res.end(`Hello from ${NAME}\n`);
}).listen(PORT, () => {
  console.log(`${NAME} running on port ${PORT}`);
});

Run:

PORT=3001 NAME=Server-A node server.js
PORT=3002 NAME=Server-B node server.js
PORT=3003 NAME=Server-C node server.js

10. Code Example 2: NGINX Load Balancer

nginx.conf

http {
  upstream backend_servers {
    least_conn;
    server localhost:3001;
    server localhost:3002;
    server localhost:3003;
  }

  server {
    listen 80;

    location / {
      proxy_pass http://backend_servers;
    }
  }
}

What’s happening?

upstream = server pool
least_conn = algorithm
NGINX distributes traffic automatically

11. Session Persistence (Sticky Sessions)

For logged-in users:

upstream backend_servers {
  ip_hash;
  server localhost:3001;
  server localhost:3002;
}

👉 Same user → same server

12. Load Balancer + Auto Scaling (Real Production)

Load Balancer	Auto Scaling
Distributes traffic	Adds/removes servers
Prevents overload	Handles growth
Always on	Trigger-based

Used together in:

AWS
Kubernetes
Netflix

13. Netflix Example (End-to-End)

Netflix uses multiple layers:

DNS → nearest region
Edge Load Balancers → CDN
Regional Load Balancers
Service-to-service balancing
Microservices

Each click:

User → DNS → Load Balancer → Service → Cache → Stream

Result:

No overload
Fast startup
Global scale

14. Security Benefits

Load balancers can:

Terminate SSL
Hide backend IPs
Rate limit traffic
Mitigate DDoS
Integrate WAF

So they’re also security gates.

15. Common Pitfalls

❌ Single load balancer (SPOF)
❌ Sticky sessions everywhere
❌ No health checks
❌ Poor monitoring
❌ Wrong algorithm choice

16. What You Should Remember (Exam / Interview Gold)

✔ Load balancing distributes requests
✔ Prevents overload & downtime
✔ Uses algorithms to route traffic
✔ Health checks are critical
✔ Layer 7 = smarter routing
✔ Essential for scalable systems

17. How This Fits in Modern Systems

Microservices → service mesh load balancing
Kubernetes → Ingress + Services
Cloud apps → Managed LBs
CDNs → Global load balancing

In today’s distributed world, load balancing is no longer an optimization — it’s a necessity. Whether you’re serving a small web app or a global platform with millions of users, effective load balancing ensures resilience, performance, and scalability. By combining the right algorithms, health checks, and infrastructure choices, systems can handle traffic spikes, survive failures, and grow without disruption. Understanding load balancing isn’t just about infrastructure knowledge; it’s about learning how real-world software stays alive under pressure. Master this concept, and you’ll be thinking like a true systems engineer.

Below is a table of your previous detailed JS / backend topics (for quick revision), so your learning stays connected and structured.

📘 Architecture Series – Index

#	Topic
1	Pagination — Architecture Series: Part 1
2	Indexing — Architecture Series: Part 2
3	Virtualization — Architecture Series: Part 3
4	Caching — Architecture Series: Part 4
5	Sharding - Architecture Series: Part 5
6	Load Balancing - Architecture Series: Part 6

Thanks for reading! 🙌
Until next time, 🫡
Usman Awan (your friendly dev 🚀)

🚀 Using Local AI Models and APIs as a JavaScript Developer

Muhammad Usman Awan — Tue, 16 Dec 2025 10:36:51 +0000

🚀 Key Points on Using Local AI Models and APIs as a JavaScript Developer

Research suggests Ollama is straightforward for running open-source LLMs locally on macOS, supporting CPU-only mode without a dedicated GPU by default, while automatically utilizing Apple's Metal framework on M-series chips for acceleration where available.
Hugging Face models can run locally in JavaScript via Transformers.js, enabling browser or Node.js execution of open-source models without servers, though performance may vary on macOS without GPU optimization.
As a JS developer, LangChain.js and LangGraph.js provide tools for chaining prompts, building agents, and integrating LLMs, with seamless support for local models like those from Ollama or Hugging Face.
OpenAI and Gemini APIs offer cloud alternatives with rate limits; evidence leans toward OpenAI's tiered pricing starting at $0.20/1M tokens for smaller models, while Gemini provides a free tier but charges $0.075–$2.00/1M for inputs in paid plans, acknowledging potential costs for high usage.
It seems likely that starting with CPU-only setups on macOS is accessible for beginners, but scaling to advanced agents may involve API calls from JS to local servers for better performance.

📖 Overview for JavaScript Developers

As a JavaScript developer new to this, focus on Node.js for server-side setups or browser for lightweight experiments. Local tools like Ollama run as a background service you can call via HTTP from JS, while Transformers.js runs directly in JS environments. LangChain.js helps chain operations, and LangGraph.js builds complex agents. Open-source models (e.g., Llama, Mistral) are free and privacy-focused. For macOS, no extra GPU is needed—CPU works, but M-series chips boost speed via Metal.

🎬 Beginner Steps: Setting Up Local Models

Start with Ollama for simplicity: Download from ollama.com/download, install, and run ollama run llama3.1 in terminal. From JS, use fetch to call its API at http://localhost:11434. For Hugging Face, install @huggingface/transformers via npm and load models like BERT.

⚒️ Integrating with LangChain.js and APIs

Use LangChain.js to wrap models: Install @langchain/core, create prompts, and chain to LLMs. Add OpenAI/Gemini via their SDKs, but monitor limits—OpenAI caps free tiers at low RPM, Gemini at 1,500 requests/day free.

👉 Comprehensive Guide to Local AI Models, LangChain/LangGraph, and APIs for JavaScript Developers

This detailed survey covers everything from beginner basics to advanced integrations, tailored for a JavaScript developer. We'll start with foundational setups for running open-source AI models locally using Ollama and Hugging Face, addressing with/without GPU scenarios (macOS relies on CPU or Metal acceleration on Apple Silicon). Then, we'll explore LangChain.js and LangGraph.js for building applications, and finally incorporate OpenAI and Gemini APIs with their limits. All steps are step-by-step, assuming you're starting from scratch with Node.js installed. Open-source models emphasized here are free, community-driven, and available on platforms like Hugging Face Hub.

Section 1: Understanding Local AI Setups

Local AI means running models on your machine for privacy, cost savings, and offline use. Open-source models (e.g., from Meta, Mistral AI) are pre-trained LLMs you download once. On macOS, without a dedicated NVIDIA GPU, you use CPU inference, which is slower for large models but feasible for smaller ones (e.g., 7B parameters). Apple M-series chips (M1+) enable GPU-like acceleration via Metal, improving speeds 2-5x without extra hardware. If no M-chip, pure CPU works but limit to quantized models (reduced precision for efficiency).

Popular Open-Source Models for Local Use:
From Ollama library and Hugging Face:

Llama 3.1 (Meta): 8B-405B params, general-purpose, multilingual.
Qwen 3 (Alibaba): 0.6B-235B, strong in reasoning/tools.
Mistral (Mistral AI): 7B, efficient for code/text.
Gemma 3 (Google): 270M-27B, lightweight for single-GPU/CPU.
Phi 3 (Microsoft): 3.8B-14B, high performance on small hardware.
Others: DeepSeek-V3.2 (685B, advanced but heavy), NVIDIA Nemotron (8B-32B, optimized).

These are GGUF/ONNX formats for local efficiency.

Section 2: Step-by-Step for Ollama (Local LLM Runner)

Ollama is a lightweight tool for running open-source LLMs locally, with a REST API perfect for JS integration. It supports CPU-only and auto-detects Metal on M-series macOS.

Beginner Steps: Installation and Basic Use

Download the installer from ollama.com/download (macOS .pkg file).
Run the installer; it sets up a background service.
Open Terminal (via Spotlight) and verify: ollama --version.
Pull a model: ollama pull llama3.1 (downloads ~4GB for 8B version; use smaller like gemma3:2b for testing).
Run interactively: ollama run llama3.1 – type prompts in terminal.
Without GPU: Ollama defaults to CPU; on M-series, it uses Metal automatically (check Activity Monitor for GPU usage). For pure CPU force, set env var OLLAMA_NO_GPU=1 before running.
Test a prompt: In terminal, ask "Explain JavaScript promises simply."

Intermediate Steps: Custom Models and Optimization

List models: ollama list.
Create custom model: Make a Modelfile (text file) with FROM llama3.1 and custom system prompt, then ollama create mymodel -f Modelfile.
Quantization for no-GPU: Use pre-quantized tags like llama3.1:Q4_0 (4-bit, faster on CPU).
Run in background: ollama serve to start API server.
Manage resources: Set OLLAMA_KEEP_ALIVE=5m env var to unload models after idle.

Advanced Steps: Integrating with JavaScript

Start Ollama server: ollama serve.
In Node.js project: npm init -y; npm install node-fetch (or use built-in fetch in Node 18+).
Create index.js:

   const fetch = require('node-fetch');
   async function generateResponse(prompt) {
     const response = await fetch('http://localhost:11434/api/generate', {
       method: 'POST',
       headers: { 'Content-Type': 'application/json' },
       body: JSON.stringify({ model: 'llama3.1', prompt, stream: false })
     });
     const data = await response.json();
     return data.response;
   }
   generateResponse('Write a JS function for Fibonacci').then(console.log);

Run: node index.js.
Streaming: Set stream: true, handle response as ReadableStream.
Chat mode: Use /api/chat with messages array for conversational context.
Tools: Define functions in JSON for agent-like behavior (e.g., weather API call).
Multimodal: For models like Llava, add base64 images in requests.

Section 3: Step-by-Step for Hugging Face Models Locally with Transformers.js

Transformers.js runs Hugging Face's open-source models directly in JS (browser/Node), using ONNX for local execution. Ideal for JS devs; no Python needed. On macOS without GPU, use CPU; WebGPU for M-series acceleration in browsers.

Beginner Steps: Installation and Basic Inference

Create Node project: npm init -y.
Install: npm install @huggingface/transformers.
Import pipeline:

   import { pipeline } from '@huggingface/transformers';
   async function main() {
     const pipe = await pipeline('sentiment-analysis');
     const result = await pipe('I love AI!');
     console.log(result);
   }
   main();

Run: node --experimental-wasm-bigint index.js (for WASM support).
Use open-source model: pipeline('text-generation', 'Xenova/gpt2').
Without GPU: Defaults to CPU; test small models like 'Xenova/distilbert-base-uncased'.

Intermediate Steps: Optimization and Tasks

Quantization: Add { dtype: 'q4' } to pipeline options for smaller/faster models.
GPU on macOS: In Safari/Chrome (with WebGPU flag), { device: 'webgpu' }.
Vision/Audio: pipeline('image-classification', 'Xenova/vit-base-patch16-224').
Custom models: Download from Hugging Face Hub, load locally via path.
Browser setup: Use script tag <script src="https://cdn.jsdelivr.net/npm/@huggingface/transformers"></script>.

Advanced Steps: Building Applications

Private models: Add { token: 'hf_...' } (get from huggingface.co/settings/tokens).
Convert models: Use Python's Optimum to export to ONNX, then load in JS.
Integrate with frameworks: In React, use useEffect for async pipeline loading.
Multimodal: pipeline('zero-shot-image-classification', 'Xenova/clip-vit-base-patch16').
Server-side: Build Express API wrapping pipelines for production.

Section 4: LangChain.js for Chaining AI Operations in JavaScript

LangChain.js is the JS port of LangChain, for composing prompts, models, and tools. Great for JS devs building apps.

Beginner Steps: Setup and Prompts

Install: npm install @langchain/core @langchain/groq (or OpenAI/HF integrations).
Basic chain:

   import { ChatGroq } from '@langchain/groq';
   import { PromptTemplate } from '@langchain/core/prompts';
   const model = new ChatGroq({ apiKey: 'your-key', model: 'llama3-8b-8192' });
   const prompt = PromptTemplate.fromTemplate('Tell a joke about {topic}.');
   const chain = prompt.pipe(model);
   const response = await chain.invoke({ topic: 'JavaScript' });
   console.log(response.content);

Add output parser: Install @langchain/core/output_parsers, use StringOutputParser.

Intermediate Steps: Memory and Tools

Conversation memory: Use BufferMemory to store chat history.
Tools: Define JS functions, bind to model for agentic calls.
Local integration: Use @langchain/community for Ollama/HF wrappers.

Advanced Steps: Full Apps

Agents: Create with createAgent for decision-making.
RAG: Add vector stores (e.g., in-memory) for document search.
Frameworks: Integrate with Next.js for web apps.

Section 5: LangGraph.js for Building AI Agents in JavaScript

LangGraph.js builds graph-based workflows for agents, extending LangChain.js.

Beginner Steps: Basic Graph

Install: npm install @langchain/langgraph.
Simple agent:

   import { Graph } from '@langchain/langgraph';
   const graph = new Graph();
   // Add nodes/tools, edges

Define nodes: Functions for LLM calls, tools.

Intermediate Steps: Agents with Tools

Add LLM node: Use LangChain models.
Human-in-loop: Pause for user input.
Persistence: Save state for resuming.

Advanced Steps: Complex Workflows

Custom graphs: Mix deterministic/agentic paths.
Streaming: Real-time outputs.
Scale: Integrate with databases for memory.

Section 6: Integrating OpenAI and Gemini APIs with Limits

For cloud backups, use SDKs in JS.

OpenAI API:

Install: npm install openai.
Usage: const openai = new OpenAI({ apiKey: 'sk-...' }); await openai.chat.completions.create({ model: 'gpt-5-mini', messages: [...] });.
Limits/Pricing: Free tier low RPM; paid from $0.20/1M input (gpt-5-mini) to $21/1M (gpt-5.2 pro). Hard/soft billing limits in dashboard; batch 50% off.

Gemini API:

Install: npm install @google/generative-ai.
Usage: const genAI = new GoogleGenerativeAI('API_KEY'); const model = genAI.getGenerativeModel({ model: 'gemini-2.5-flash' }); await model.generateContent('Prompt');.
Limits/Pricing: Free tier up to 1,500 RPD; paid from $0.075/1M input (Flash-Lite) to $2/1M (Pro). Context caching/storage extra; grounding tools $25-35/1k beyond free.

Tables for Quick Reference

Ollama vs. Hugging Face Comparison

Aspect	Ollama	Hugging Face (Transformers.js)
Installation	Download .pkg, terminal commands	npm install
GPU Support (macOS)	Auto Metal on M-series	WebGPU in browser
JS Integration	HTTP API (fetch)	Direct in code
Models	GGUF, easy pull	ONNX, Hub download
Beginner Ease	High (CLI first)	Medium (code-based)

API Pricing Summary (per 1M Tokens)

Model/API	Input (Base)	Output (Base)	Free Tier Limits
OpenAI GPT-5 Mini	$0.25	$2.00	Low RPM, credit-based
Gemini 2.5 Flash	$0.30	$2.50	1,500 RPD
OpenAI GPT-5.2	$1.75	$14.00	N/A (paid only)
Gemini 2.5 Pro	$1.25	$10.00	1,500 RPD

This covers a complete path from setup to production-grade agents, ensuring you can experiment locally before scaling.

Thanks for reading! 🙌
Until next time, 🫡
Usman Awan (your friendly dev 🚀)

DEV Community: Muhammad Usman Awan

Building a Production-Ready Anonymous Identity & Abuse Protection Layer with FastAPI

👋 Introduction

🤔 Why Not Just Use IP Rate Limiting?

💡 The Idea

🏗 Architecture

📂 Organizing the Backend

🗄 Designing the Anonymous User

🧠 Services Instead of Fat Routes

🛡 Middleware Does the Heavy Lifting

🚫 Preparing for Bans

🤝 Integrating with the LLM Router

📈 Current Flow

How I built a provider-agnostic AI architecture that automatically switches between Groq, OpenRouter, Ollama, and Gemini.

🚀 Building a Production-Ready Multi-LLM Router with LangChain & FastAPI

Introduction

The Problem

The Solution

Why a Router?

Provider Abstraction

Request Lifecycle

Automatic Failover

Health Tracking

Dependency Injection

Why This Architecture?

Lessons Learned

What's Next?

Final Thoughts

⭐ If you found this helpful...

🧠 Dev.to Un-Stuck: The Chrome Extension That Finally Fixes Your Reading List

🧠 Dev.to, Un-Stuck: The Chrome Extension That Finally Fixes Your Reading List

🚨 The Real Problem (In Detail)

1. No Concept of Progress

2. Passive Storage = Forgotten Knowledge

3. Cognitive Overload

💡 The Solution: Dev.to Un-Sticker

✨ Key Features

✅ Read / Unread State (Finally)

⏰ Smart Reminder System

📜 Infinite Scrolling That Actually Scales

🔒 Privacy-First by Design

🛠️ How It Works (Under the Hood)

⚙️ Background Logic

💾 Local Storage System

🔮 What’s Next?

🤖 AI-Powered Learning

📧 Weekly Digest Emails (Optional)

❓ FAQ (Improved)

Is it available on the Chrome Web Store?

Why do I need an API key?

Is my data safe?

I’m not getting reminders—what’s wrong?

🧠 Final Thought

Earth’s Breath: An Interactive Journey from Seed to Restoration

What I Built

Demo

Code

How I Built It

1. The "Living" Component Architecture

2. The Celestial Arc

3. Clean-Up Logic with Masks

Reflection

🚨 Claude code source code leaked?? ‼️

🚨 Claude Code — Leaked Source (2026-03-31)

⚠️ Disclaimer

🧨 How It Leaked

Root Cause

🧠 Overview

Capabilities

📊 Leak Summary

📁 Directory Structure

🏗️ Core Architecture

1️⃣ Tool System (src/tools/)

2️⃣ Command System (src/commands/)

3️⃣ Service Layer (src/services/)

4️⃣ Bridge System (src/bridge/)

5️⃣ Permission System

6️⃣ Feature Flags

🔍 Key Files

⚙️ Tech Stack

1️⃣ Tool System (`src/tools/`)

2️⃣ Command System (`src/commands/`)

3️⃣ Service Layer (`src/services/`)

4️⃣ Bridge System (`src/bridge/`)