DEV Community: Likhit Kumar V P

I Built an MCP Server That Lets AI Autonomously Debug Salesforce - Here's How

Likhit Kumar V P — Sun, 05 Apr 2026 12:54:29 +0000

I built sf-log-mcp, an open-source MCP server that gives AI assistants (Claude, Copilot, Cursor) the ability to autonomously fetch, analyze, and manage Salesforce debug logs. It detects "silent failures" that Salesforce marks as "Success" but are actually broken. Published on npm, 9 tools, 7 parsers, 101 tests.

GitHub: github.com/Likhit-Kumar/SF-Logs

npm: npx sf-log-mcp

The Problem Nobody Talks About

If you've ever debugged a Salesforce integration, you know the drill:

Open Setup > Debug Logs
Stare at a wall of logs showing Status = "Success"
Manually download each .log file
Ctrl+F through 50,000 lines looking for what went wrong
Find out the "successful" callout actually returned {"error":"rate_limit_exceeded"} inside an HTTP 200

The Status field lies. In my experience, over 90% of real production issues are silent failures the code didn't crash, Apex didn't throw an unhandled exception, but the right thing didn't happen.

Here's what "Success" actually hides:

HTTP 200 with {"error":"rate_limit"} in body - Integration silently failing
Exception caught by try-catch - Error swallowed, moved on
SOQL returned 0 rows - Wrong filter, no data processed
Governor limits at 95% - Works now, breaks at scale
Flow path skipped entirely - Expected automation never fired

Now here's the kicker: no existing MCP server can even fetch these logs, let alone analyze them.

The Gap in the Ecosystem

I spent weeks researching the Salesforce MCP landscape. Here's what I found:

Certinia's `@certinia/apex-log-mcp`

A solid parser, great for performance profiling and bottleneck detection. But 3 out of 4 tools require a local .log file path as input. It cannot list, fetch, or download logs from an org. You still have to manually download them first.

Salesforce's `@salesforce/mcp`

The official MCP server with 60+ tools across metadata, data, testing, DevOps, and code analysis. Impressive scope. But: zero debug log tools. No list_logs, no fetch_log, no manage_trace_flags. Nothing.

The Workflow Today (Even With MCP)


You: "Something's wrong with our Vendor X integration"

AI: "I'd love to help! Can you download the debug log
and give me the file path?"

You: *opens Setup, clicks Debug Logs, downloads file,
saves to Desktop, types the path*

AI: "Thanks, here's the analysis..."

The AI is supposed to be autonomous. But it can't even get the logs it needs.

What I Built

sf-log-mcp, a standalone MCP server that fills the missing layer between your Salesforce org and your AI assistant.

The Philosophy

Don't filter. Fetch. Read. Reason.

Instead of filtering logs by status (which catches <10% of real issues), sf-log-mcp downloads the raw log content and lets the AI reason about what actually happened such as callout responses, DML results, swallowed exceptions, governor limits, flow paths.

The Workflow Now


You: "Something's off with our Vendor X integration — check the recent logs"

AI autonomously:

1. manage_trace_flags → checks if logging is active
2. fetch_latest_logs → downloads 5 most recent logs
3. analyze_log → health score: 35/100 (CRITICAL)
4. get_log_content → drills into callouts section
5. get_log_content → checks exceptions section

AI: "Found it. Log 07L... shows the callout to
api.vendorx.com/sync returned HTTP 200, but the
response body contains {"error":"rate_limit_exceeded"}.
This happened in 3 of the 5 recent logs. The
integration looks healthy from the Status field
but is actually being rate-limited."

Zero manual steps. The AI fetches, reads, reasons, and explains.

Architecture


You (natural language)
│
v
AI Assistant (Claude / Copilot / Cursor)
│ MCP tool calls via stdio
v
sf-log-mcp (this project)
│ Salesforce Tooling API (REST)
v
Your Salesforce Org (auth via SF CLI)

Key Design Decisions

1. Direct Tooling API, not CLI subprocesses

Instead of shelling out to sf apex list log (which spawns a subprocess, has CLI version dependencies, and limited filtering), I use @salesforce/core to make direct REST calls to the Salesforce Tooling API. This gives fine-grained query control and eliminates subprocess overhead.

2. Reuse SF CLI auth

No new credentials, no OAuth setup, no tokens to configure. If sf org list shows your org, sf-log-mcp can connect to it. It reads from ~/.sf/ - the same auth your Salesforce CLI already uses.

3. Standalone, not bundled

sf-log-mcp runs alongside Certinia's parser, not replacing it. You get the best of both: sf-log-mcp fetches and analyzes for silent failures, Certinia does deep performance profiling. The AI combines both results.

9 Tools, 4 Tiers

Tier 1: Log Acquisition

list_debug_logs - List logs with rich filtering (user, operation, date range, size)
fetch_debug_log - Download a specific log by ID
fetch_latest_logs - Batch-download the N most recent logs

Tier 2: Content Intelligence

get_log_content - Extract structured sections (callouts, exceptions, SOQL, DML, governor limits, flows, debug messages)
analyze_log - One-call health analysis with a 0-100 score
search_logs - Regex search across all downloaded logs

Tier 3: Lifecycle Management

manage_trace_flags - Create, list, update, delete trace flags
delete_debug_logs - Delete logs (with dry-run mode)

Tier 4: Cross-Log Intelligence

compare_logs - Side-by-side diff of two logs for regression detection

The Health Score: Diagnosing Logs in One Call

The analyze_log tool is the entry point for debugging. It returns a health score from 0-100:


Health Score: 65/100 — DEGRADED

Critical Issues:

- Silent callout failure: HTTP 200 with error in body (api.vendorx.com)

Warnings:

- 2 handled exceptions (verify error handling is correct)

- Governor limit: SOQL queries at 82% (approaching limit)

- Zero-row SOQL: SELECT Id FROM Account WHERE ExternalId__c = '...'

How it's calculated:


healthScore = 100

healthScore -= (critical issues × 20)

healthScore -= (warnings × 5)

Health Ratings:

HEALTHY (90-100) - No significant issues
WARNING (70-89) - Minor concerns worth checking
DEGRADED (50-69) - Multiple issues, needs attention
CRITICAL (0-49) - Serious failures detected

The AI uses this score to decide what to drill into next callouts? Exceptions? Governor limits? It's the triage step that makes the whole workflow efficient.

Detecting Silent Failures: The 7 Parsers

Each parser is purpose-built to extract and warn about a specific class of silent failure:

1. Callout Parser - The HTTP 200 Lie Detector


CALLOUT_REQUEST|[42]|System.HttpCallout[endpoint=https://api.vendor.com/sync]

CALLOUT_RESPONSE|[42]|System.HttpCallout[status=200, body={"error":"rate_limit_exceeded"}]

Most monitoring checks the HTTP status code. 200 = good, right? Wrong. The callout parser pairs every request with its response and scans the body for error keywords. This catches the most common class of integration failure.

2. Exception Parser - Handled vs. Unhandled


EXCEPTION_THROWN|[15]|System.NullPointerException: Attempt to de-reference a null object

Salesforce only flags unhandled exceptions in the Status field. But most production code wraps everything in try-catch. The exception parser uses a 10-line lookahead : if EXCEPTION_THROWN is followed by FATAL_ERROR, it's unhandled. If followed by METHOD_EXIT, it was caught. Both are reported, because a caught NullPointerException is still a bug.

3. SOQL Parser - The Zero-Row Detector


SOQL_EXECUTE_BEGIN|[23]|SELECT Id FROM Account WHERE ExternalId__c = 'VND-001'

SOQL_EXECUTE_END|[23]|Rows:0

A query that returns 0 rows isn't an error. But if your integration expects to find a matching record and doesn't, the entire downstream process silently does nothing. The SOQL parser flags zero-row results as data issues.

4. Governor Limits Parser - The Time Bomb Detector


Number of SOQL queries: 82 out of 100 (82%) → WARNING

Number of DML rows: 9,800 out of 10,000 (98%) → CRITICAL

At 95% of governor limits, everything works. At 101%, everything breaks. The governor parser calculates percentages and flags anything over 80% as a warning.

5-7. DML, Flow, and Debug Message Parsers

DML Parser: Flags bulk operations (>200 rows) that might cause partial failures
Flow Parser: Tracks 16 flow event types, flags FLOW_ELEMENT_ERROR and FLOW_ELEMENT_FAULT
Debug Messages: Extracts System.debug() output where developers log errors the system doesn't track

Smart Error Handling

Salesforce API errors are notoriously cryptic. sf-log-mcp classifies them into 9 categories with actionable messages:

Session expired → "Re-authenticate with: sf org login web --alias <org>"
API limit exceeded → "Wait and retry, or check API usage in Setup"
Insufficient permissions → "User needs View All Data or Manage Users"
Entity already traced → "Use manage_trace_flags to find the existing flag"

No more googling Salesforce error codes.

Security Model

No credentials stored - Reuses SF CLI auth from ~/.sf/
Org allowlist - --allowed-orgs restricts which orgs the server can access
Stdio transport - No HTTP server, no open ports
SOQL injection protection - All user inputs are escaped
Read-only by default - Only delete_debug_logs and manage_trace_flags modify state (and only debug infrastructure, not business data)

The Numbers

9 MCP Tools
7 Log Parsers
2,488 Source Lines
1,069 Test Lines
101 Tests Passing
15 Test Suites
3 Production Dependencies
44.8 KB npm Package Size
3 Node.js Versions Supported (18, 20, 22)

Try It in 2 Minutes

Prerequisites

Node.js >= 18
Salesforce CLI (sf) authenticated to an org

Setup


npx sf-log-mcp --allowed-orgs ALLOW_ALL_ORGS

Configure Your AI Client

Claude Desktop:


{

    "mcpServers": {

        "sf-log-mcp": {

            "command": "npx",

            "args": ["-y", "sf-log-mcp", "--allowed-orgs", "ALLOW_ALL_ORGS"]

        }

    }

}

VS Code / Cursor:


{

    "servers": {

        "sf-log-mcp": {

            "command": "npx",

            "args": ["-y", "sf-log-mcp", "--allowed-orgs", "ALLOW_ALL_ORGS"]

        }

    }

}

Then ask your AI: "List my recent Salesforce debug logs"

Multi-Server Setup

sf-log-mcp is designed to complement, not replace:


AI Client (Claude Desktop / VS Code / Cursor)
│
├── sf-log-mcp (this project)
│ Fetch, analyze, search debug logs
│ Detect silent failures
│
├── @certinia/apex-log-mcp (optional)
│ Deep performance profiling
│ CPU bottleneck detection
│
└── @salesforce/mcp (optional)

SOQL queries, metadata, test runs

sf-log-mcp fetches the log and saves it to disk. Certinia's tools read the same file for performance analysis. The AI combines both results -> silent failure detection + performance profiling in one conversation.

What I Learned Building This

1. The Status Field is a Lie

This was the core insight that shaped the entire architecture. Filtering by Status = 'Fatal Error' catches maybe 5-10% of real issues. The rest are silent : HTTP 200s with error bodies, caught exceptions, empty query results, skipped flow paths. The only way to find them is to read the actual log content.

2. MCP is the Right Abstraction

Before MCP, I would have built a CLI tool or a VS Code extension. MCP means I build once and it works everywhere (Claude Desktop, VS Code, Cursor, Windsurf, any future client). The AI decides when and how to use the tools. I just expose the capabilities.

3. Parsers Need to Be Opinionated

A generic parser that returns "here are all the events" is useless to an AI. The parsers need to warn - "this callout returned 200 but the body contains an error keyword." That opinion is what makes the AI's analysis actionable.

4. Health Scores Drive Efficient Debugging

Without the health score, the AI would analyze every section of every log. With it, the AI triages first: "This log is CRITICAL, let me check callouts and exceptions." It cuts the number of tool calls in half.

5. Three Dependencies is Enough

@modelcontextprotocol/sdk for MCP, @salesforce/core for auth + API, zod for validation. That's it. No express, no axios, no lodash. The entire package is 44.8 KB.

What's Next

Windsurf testing - Verifying compatibility with the Windsurf AI IDE
Real-time log tailing - Stream logs as they're generated (SSE transport)
Custom analysis rules - User-defined patterns for domain-specific silent failures
Certinia integration guide - Step-by-step workflow combining both servers

Agentforce Scripts: Hybrid Reasoning, Action Chaining, and What It Actually Looks Like in Practice

Likhit Kumar V P — Sat, 28 Mar 2026 13:37:38 +0000

Salesforce gave agents a scripting language. I tested it by building something that matters.

If you've been following the Salesforce ecosystem lately, you've probably heard the buzz around Agentforce (Salesforce's AI agent platform). But buried inside that buzz is something genuinely powerful that doesn't get talked about enough: Agent Script.

Agent Script is a high-level, declarative scripting language designed specifically for controlling Agentforce agents. It lets you combine deterministic business logic (IF conditions, guaranteed action sequences, hard rules) with generative AI reasoning (LLM-powered natural language, contextual responses, empathetic communication).

Salesforce calls this hybrid reasoning. And after spending time building with it, I think it's the most important feature Agentforce has shipped.

In this post, I'll walk through the key Agentforce features what they do, how they work together and show how I put them to the test by building an Employee Burnout Prevention Agent for the Agent Script Quest.

What Is Agent Script and Why Should You Care?

Before Agent Script, building Agentforce agents meant configuring topics and actions, then hoping the LLM would reason through them correctly. The LLM was both the brain and the decision-maker. That works for simple use cases, but the moment you need guaranteed behaviour "if this condition is true, you MUST do this, no exceptions" you were stuck. LLMs are probabilistic. Business rules are not.

Agent Script changes this entirely.

It's a compiled language that generates an Agent Graph specification consumed by the Atlas Reasoning Engine. You write instructions that blend two layers:

Deterministic layer — IF/ELSE conditions, action calls, variable assignments. These execute exactly as written. The LLM cannot override them.
Generative layer — Prompts that let the LLM generate natural language responses, adapt tone, personalise messages. The LLM gets creative freedom here.

The result: agents that are predictable where it matters and human where it counts.

This isn't a theoretical concept. The Agent Script Recipes library on Salesforce Developers provides working patterns for multi-action chaining, conditional routing, variable passing, and more. These recipes are what inspired me to go further and apply them to a real-world use case.

The Agentforce Features — Explained

Let me break down each feature I explored and what it brings to the table.

1. Agentforce Builder — Canvas View

When you open an agent in Agentforce Builder, you land in Canvas view. This is the visual layer, it summarises your Agent Script into easily understandable blocks that you can expand to see the underlying script.

What makes Canvas view useful:

You get a bird's-eye view of your agent's structure — topics, actions, and how they connect
Type / to quickly add expressions for common patterns (if-else conditionals, loops)
Type @ to add resources like topics, actions, and variables
Non-technical stakeholders can read and review agent logic without touching code

Canvas view is the communication layer. It's how you show your team what the agent does without drowning them in script syntax.

2. Agentforce Builder — Script View

Switch to Script view, and you're looking at what's happening under the hood — the actual Agent Script instructions that drive the agent's reasoning.

Script view is a code editor interface where you can:

Write Agent Script directly with full syntax support
Make fast, precise changes
Dig into error messages when things break
See the deterministic and generative layers side by side

The critical thing: Canvas view and Script view are always in sync. Edit in one, and it reflects in the other. This means you can prototype visually in Canvas and fine-tune in Script — or vice versa.

3. Agent Script — Hybrid Reasoning

This is the core. Agent Script enables what Salesforce officially calls hybrid reasoning — the configurable Atlas Reasoning Engine balancing LLM creativity with structured business logic.

Here's what this looks like conceptually:

// DETERMINISTIC LAYER — Hard rules. Non-negotiable.
IF riskLevel == "Red":
CALL Schedule_Manager_Meeting
CALL Create_HR_Alert

IF riskLevel == "Amber":
// No escalation. Period.

IF riskLevel == "Green":
// No escalation. Just acknowledgement.

// GENERATIVE LAYER — LLM takes over.
GENERATE a personalised, empathetic message

- Use the employee's first name
- Reference their situation without exposing internal scores
- Speak like a caring colleague, not a system notification

The IF conditions are business rule guarantees. The LLM cannot skip them, reinterpret them, or override them. They fire deterministically, every single time.

The message generation below is pure LLM. It gets creative freedom to write something warm, contextual, and human.

Hard rules in code. Warmth in language. That's hybrid reasoning.

4. Action Chaining

Action chaining is one of the most practical patterns from the Agent Script documentation. It enables multiple actions in a guaranteed sequence — reliable multi-step workflows without relying on the LLM to remember multiple steps.

There are several ways to chain actions:

Sequential instructions — Actions run deterministically before LLM reasoning occurs
Variable passing — Store the output of one action in a variable, use it as input to the next action
Reasoning actions — Define a follow-up action that automatically fires when the LLM calls a primary action
Conditional chaining — Chain actions based on the results of previous actions
Transitions with actions — Run an action and then automatically transition to another topic

The key benefit: the sequence is guaranteed. Action A always runs before Action B. Action B only fires if Action A's output meets a condition. No ambiguity.

5. Conditional Routing

Conditional routing controls when actions fire and when topics transition, based on state and variables. In Agent Script, you write IF conditions that evaluate action outputs and route the agent's behaviour accordingly.

This isn't just "if X then do Y." It's full control over the entire agent response:

Which actions fire
Which actions are blocked
What tone the LLM takes in its response
Whether the agent escalates, stays quiet, or celebrates

Three different inputs can produce three completely different agent behaviours — all governed by the same script.

6. Apex Invocable Actions

Agent Script doesn't do computation itself — it orchestrates. The actual logic lives in Apex Invocable classes that the agent calls as actions.

This is a clean separation of concerns:

Apex handles the math, the data operations, the record creation
Agent Script handles the decision-making, sequencing, and routing
The LLM handles the human communication

Each Apex action is an @InvocableMethod class that takes typed inputs and returns typed outputs. Agent Script stores those outputs in variables and uses them to drive conditional logic.

7. Preview Panel

Inside Agentforce Builder, there's a Conversation Preview panel where you can test your agent in real-time without deploying anything. Type a message, and the agent processes it live — firing actions, evaluating conditions, generating responses.

This is the fastest feedback loop for agent development. Write script, test immediately, iterate.

8. Trace Panel

This is arguably the most underrated feature in the entire builder.

Click the Trace link under any agent response, and you get a step-by-step breakdown of every reasoning step the agent took:

Step 1 — Topic classified as "Assess Wellbeing"

Step 2 — Calculate Burnout Score action called → returned "Red"

Step 3 — Schedule Manager Meeting action triggered

Step 4 — Create HR Alert action triggered

Step 5 — LLM generated personalised message

Every action call. Every condition evaluation. Every LLM generation step. Full transparency.

In enterprise contexts — especially anything touching HR, compliance, or finance — being able to prove why the agent did what it did isn't optional. The Trace panel gives you that audit trail out of the box.

9. The Atlas Reasoning Engine

Under the hood, Agent Script compiles into an Agent Graph consumed by the Atlas Reasoning Engine. This engine is now configurable — you can balance the creativity of LLMs with the certainty of structured business logic.

The Atlas Reasoning Engine handles:

Reflective loops
Multi-topic coordination
Multi-agent coordination
Action sequencing exactly as defined in your script

This isn't prompt-and-pray. It's a structured execution environment where deterministic and generative reasoning coexist by design.

Putting It All Together: The Burnout Prevention Agent

To test these features end-to-end, I built an Employee Burnout Prevention Agent for the Salesforce Agent Script Quest. The idea: an autonomous AI agent that monitors employee work patterns, detects burnout risk, and intervenes with the right action — without any human prompt.

I was directly inspired by the multi-action chaining and conditional routing patterns from the Agent Script Recipes library — and pushed them into a real-world HR use case.

The Data Model

Three custom objects:

EmployeeActivity__c

Stores work pattern data — weekly hours, overdue tasks, weekend logins, after-hours emails, missed breaks. This is the input layer.

WellbeingScore__c

Agent's calculated output — burnout score and risk level (Red / Amber / Green). Internal only. Employees never see this.

HR_Alert__c

Confidential record created only for Red-risk employees. The employee never sees this. HR gets visibility without creating stigma.

The Apex Actions

Calculate Burnout Score — Weighted algorithm scoring 5 signals (login hours, overdue tasks, weekend logins, after-hours emails, missed breaks) and outputs a risk level. Fires always — first in the chain.

Schedule Manager Meeting — Creates a confidential calendar event and a high-priority task for the employee's manager. Fires for Red risk only.

Create HR Alert — Creates a silent, confidential HR_Alert__c record. Fires for Red risk only.

The scoring algorithm is pure deterministic Apex — no LLM decides someone's risk level. That's a business rule, not a creative task.

The Agent Script Structure

One topic: Assess Wellbeing. I deliberately kept it single-topic because the power here is in the action chaining and conditional logic, not in complex topic routing.

The script uses:

Action chaining — Calculate Score runs first, its output (risk level) is stored in a variable, that variable feeds into conditional logic for the next actions
Conditional routing — Red triggers all three actions + urgent message. Amber triggers only the score + gentle check-in. Green triggers only the score + positive reinforcement.
Hybrid reasoning — Deterministic IF conditions for action routing, LLM generation for empathetic employee messages

Three Tests, Three Completely Different Outcomes

I tested with three demo employees, each representing a different burnout profile:

Leila Novak — Red Risk (67 hours/week, 13 overdue tasks, 4 weekend logins)

What the Trace panel showed:

Topic → Assess Wellbeing
Action → Calculate Burnout Score → Red
Action → Schedule Manager Meeting → Triggered
Action → Create HR Alert → Triggered
LLM → Generated warm, personal message

What Leila sees: A warm, personal message with no scores, no clinical language — just genuine care.

What gets created silently: WellbeingScore (Red), HR Alert (confidential), Manager Task (high priority), Calendar Event (1:1 meeting).

All in under 10 seconds. Leila didn't ask for help. Her manager didn't notice. Nobody typed anything.

Florence Stein — Amber Risk (52 hours/week, some weekend activity)

Trace panel: Only the scoring action fired. No meeting. No HR alert. The deterministic rules correctly blocked escalation. Florence received a gentle, empathetic check-in — proportionate and intelligent.

Shane Marin — Green Risk (38 hours/week, zero weekend logins)

Trace panel: Just the scoring action. No escalations. A positive, warm acknowledgement of healthy work habits.

Three employees. Three completely different, perfectly proportionate responses. All autonomous.

Why Not Just Use Apex and Flows?

Fair question. You could absolutely build a scoring engine, conditional record creation, and template emails with Apex and Flows alone. But here's what you'd lose:

The messages would be dead. A template email saying "Your burnout score is Amber, please take care" is clinical, impersonal, and gets ignored. The LLM writes messages that feel like they come from a real person. Every message is different. Every message is tailored to the individual.

The logic would be fragile. Hard-coding every conditional path in a Flow means every new risk factor requires a new Flow version. Agent Script's conditional routing is declarative and readable — the entire decision tree in one screen.

There would be no transparency. The Trace panel gives you an audit trail of every decision. In an HR context, proving why the agent escalated (or didn't) is a legal requirement in many jurisdictions. Flows don't give you that reasoning chain.

Hybrid reasoning isn't about replacing Flows — it's about handling use cases where you need both guaranteed behaviour and human-quality communication in the same workflow.

What I Took Away from Building with Agent Script

Start with one topic. Don't over-engineer the topic structure. The power is in actions and conditional logic, not in topic routing complexity.

Let Apex handle the math, let the LLM handle the humans. Scoring algorithms should be deterministic. Messages to real people should be generative. Don't mix these up.

The Trace panel is non-negotiable for enterprise use. If you can't explain why the agent did something, you can't ship it. Build with traceability from day one.

Study the Agent Script Recipes before building from scratch. The multi-action chaining and conditional routing patterns saved me hours. Start there, then adapt.

Design for dignity. If your agent touches anything sensitive — HR, health, performance — never expose internal scores to the people being assessed. The system should feel like a caring colleague, not a surveillance tool.

The Bigger Picture

Agentforce isn't just a chatbot platform with better branding. Agent Script, hybrid reasoning, the Atlas Reasoning Engine, action chaining, conditional routing — these are infrastructure for building agents that enterprises can actually trust.

The Burnout Prevention Agent is one use case. But the same patterns — deterministic business rules + generative communication + full traceability — apply to:

Sales: Lead scoring with personalised outreach
Support: Ticket triage with empathetic customer responses
Finance: Compliance checks with contextual explanations
Operations: Anomaly detection with proportionate escalation

The tools are here. The recipes are documented. The builder makes it accessible.

If you're in the Salesforce ecosystem and you haven't explored Agent Script yet — now is the time.

You can find the demo recording on X/Twitter.*

Tags: #Salesforce #Agentforce #AgentScript #HybridReasoning #AI #AtlasReasoningEngine #AgentforceBuilder #ActionChaining #HRTech #BurnoutPrevention

References:

I Cut My Context-Switch Recovery From 23 Minutes to 5 Seconds

Likhit Kumar V P — Fri, 13 Mar 2026 20:24:20 +0000

The most expensive thing in software isn't bugs. It's forgetting.

A developer sits down at 9 AM. Fresh coffee. Terminal open. And then: What was I doing?

They run git status. Then git stash list. Grep for TODOs. Scroll shell history. Check which files are open in VS Code. Pull up GitHub for open PRs. Open Slack to see if anyone mentioned their branch.

Ten minutes pass before they write a single character of code.

This isn't a personal failing. It's a structural one. UC Irvine researchers found it takes 23 minutes and 15 seconds to fully regain deep focus after a single interruption. Let that sink in. An 8-hour workday produces 4.8 hours of actual output. The rest is recovery.

So I built a tool to collapse that recovery time to 5 seconds.

$ snapctx

────────────────────────────────────────────────────────

SnapContext 8:45 AM · nemotron-3-nano-30b

────────────────────────────────────────────────────────

◉ IN PROGRESS branch: feat/notifications

confidence: ●●●●○ 80%

3 unstaged · 2 staged · 1 untracked · 1 stash · 2 TODOs

────────────────────────────────────────────────────────
You were building the notification routing system.
NotificationRouter.ts is created but not yet wired
into app.ts. Two TODOs remain: "wire websocket handler"
and "add error middleware". Your next structural step
is connecting the router to the entry point.
────────────────────────────────────────────────────────

4.5s

One command. 5 seconds. Plain English.

"But doesn't Copilot already -" No.

Copilot writes code. ChatGPT answers questions. Neither one tells you what you were doing when you left.

SnapContext doesn't write code. It doesn't review code. It doesn't even read code. It's a bookmark for your brain - it reads your working tree structure, not your implementation.

Never reads file contents - only file names and line-count stats
Never sends code to AI - the prompt is pure structure
Secrets aren't redacted, they're EXCLUDED - if a shell command contains an API key, the entire line is dropped
Works fully offline - snapctx --provider ollama uses a local model, zero network calls

Your code never leaves your machine. Period.

What it actually reads

10 collectors run in parallel. Each gets 5 seconds. One failure never crashes the rest (Promise.allSettled, not Promise.all).

Signal	What SnapContext sees	What it NEVER sees
Git working tree	"3 files changed in src/auth/"	The actual code changes
Git stash	"stash@{0}: WIP on feat/auth (4 files)"	The stashed content
TODOs	"TODO: wire websocket handler" (from diff)	Surrounding code
Shell history	"ran npm test 12 times in 30 min"	Your secrets or env vars
IDE open files	"auth.ts, middleware.ts open in VS Code"	File contents
GitHub PRs	"PR #42: 2 approvals, CI passing"	Code diffs
Browser tabs	"localhost:3000, jwt.io, Stack Overflow"	Page content
AI sessions	"Claude Code session: 'auth refactor'"	Conversation content
PM tickets	"LINEAR-123: Implement OAuth"	Description body

That's the data diet. Structure, not substance. Enough for an AI to say "you were building OAuth middleware and got stuck on the token refresh flow"

The part that prevents hallucination

Here's my favorite engineering decision: the confidence gate.

SnapContext has an engine called FIE (Feature Inference Engine) that scores every signal. It detects your state:

State	What triggered it
`in-progress`	You have uncommitted changes
`blocked`	Zero changes but heavy shell activity (debugging loop)
`stashed`	Stashes exist, clean tree (you shelved work)
`context-switch`	Reflog shows you just switched branches
`conflict`	Merge conflicts detected
`clean`	Nothing going on

If the confidence score drops below 25% and the state is clean, SnapContext refuses to call the AI. It says "nothing in progress" and exits. No hallucinated context. No invented narrative about what you "might" have been doing.

In an era where every AI tool is racing to generate more, this one knows when to shut up.

It remembers what you don't

Every briefing gets saved to a local SQLite database (Node 23's built-in node:sqlite — zero extra dependencies).


$ snapctx history

Date State Module Conf Branch
just now ◉ progress history ●●●○○ feat/sqlite
2h ago ◉ progress fie ●●●●○ feat/sqlite
1d ago ✓ clean — ○○○○○ main

See what changed since your last briefing — no AI call, instant:


$ snapctx diff

State in-progress → in-progress
Module fie → history
Unstaged files 3 → 7 (+4)
TODOs 1 → 0 (-1)

Generate a standup summary from today's activity:


$ snapctx eod

5 commits · 12 files · +486 · -6

Today you shipped the browser tab collector and ticket
tracking system. Five commits across three features...

Or open the web dashboard:


$ snapctx web
● http://localhost:7700

History browser, live streaming briefings via WebSocket, diff viewer, dark theme. All served from node:http — no React, no build step, no node_modules explosion.

Zero dependencies. On purpose.

The entire dependency list: Node.js built-ins. That's it.

node:sqlite for history
node:http for the web server
node:crypto for WebSocket handshake (raw RFC 6455)
node:child_process for git and shell commands

No Express. No better-sqlite3. No ws. No React. No Webpack.

Free. Actually free.

Every default provider is genuinely free, no credit card, no trial that expires:

Provider	Model	What you need
openrouter	Nemotron 30B	Free key from openrouter.ai/keys
ollama	Llama 3.2	Local install, fully offline
groq	Llama 3.3 70B	Free key from console.groq.com
huggingface	Mistral 7B	Free token from huggingface.co

The auto mode tries each in order. If you want to go fully air-gapped:


ollama serve && ollama pull llama3.2
snapctx --provider ollama

No internet required. No telemetry. No analytics. Just your git repo and a local model.

Try it in 60 seconds


git clone https://github.com/Likhit-Kumar/SnapContext.git

cd SnapContext && npm install

# Free API key (no credit card): https://openrouter.ai/keys

export OPENROUTER_API_KEY=sk-or-v1-...

alias snapctx="bash $(pwd)/snapctx.sh"

# Run from any git project

cd ~/your-project && snapctx

GitHub: github.com/Likhit-Kumar/SnapContext

Star it if you've ever lost 20 minutes just remembering what you were doing.

Zero dependencies. MIT licensed. Try it.

I Migrated a React Native App from Redux to Zustand

Likhit Kumar V P — Sat, 28 Feb 2026 10:54:18 +0000

A real migration story: the 4 Zustand patterns I kept after moving a production React Native app off Redux including the v5 crash that burned us and the architectural boundary that changed how I think about state.

Environment: React Native 0.76+ · Zustand 5.x · TypeScript

TL;DR

If you want the short version before diving in:

Selectors + useShallow are non-negotiable in v5, object selectors without it cause an infinite loop crash, not just extra re-renders
The slice pattern scales a Zustand store across multiple domains without coupling them
devtools + persist + immer are the three middleware that make Zustand production-ready
Outside-React access via getState() and subscribe() is Zustand's most underrated advantage in React Native
The real win is the architectural boundary: Zustand for client state, React Query for server state and never crossing those lines

Three months into migrating a production React Native app from Redux to Zustand, my colleague sent a Slack message that stopped me cold: "why does the filter screen crash every time someone searches for something?"

The answer turned out to be a single line: an object selector without useShallow. In Zustand v5, that's not a performance problem, it's an infinite render loop that throws Maximum update depth exceeded and unmounts your component tree. We caught it in staging. Barely.

That moment crystallised something about Zustand: it rewards people who understand what's happening under the hood, and it punishes cargo-culting in a very specific, memorable way. After the migration, I came away with four patterns that genuinely changed how I think about client state architecture. This post is all of them plus where Zustand falls short, how it pairs with React Query, and the boundary every senior dev should draw before writing a single line of state.

This isn't a beginner's tour. We'll go deep.

What Zustand Actually Is (and Isn't)

Before the patterns, the boundary that matters most.

Zustand is a client state manager. It manages state that originates and lives inside your application UI state, navigation context, user preferences, ephemeral session data, filter selections. It has no concept of staleness, no cache invalidation, no background refetching. It doesn't know your backend exists.

This distinction isn't pedantic. It's the most common architectural mistake made with Zustand: using it to store data fetched from an API and then manually wiring up all the synchronisation logic that a server state tool like React Query or SWR would give you for free. We'll revisit this in the architecture section.

What Zustand is: a minimal, subscription-based state container built on a publish/subscribe pattern, with a React hook interface on top.

What it isn't: a server cache, a Redux replacement for all use cases, or a global state dumping ground.

How It Works Under the Hood

Understanding Zustand's internals is what separates confident usage from cargo-culting and explains why some footguns are so easy to step on.

At its core, Zustand creates a store, a closure that holds state and a setState function. This is framework-agnostic. The React integration is a thin layer on top using useSyncExternalStore, React's official API for subscribing to external stores.

// This is essentially what Zustand's vanilla store does
const createStore = (initializer) => {
  let state = initializer(setState, getState);
  const listeners = new Set();

  function setState(partial) {
    const next = typeof partial === 'function' ? partial(state) : partial;
    state = { ...state, ...next };
    listeners.forEach(listener => listener(state));
  }

  function getState() { return state; }

  function subscribe(listener) {
    listeners.add(listener);
    return () => listeners.delete(listener);
  }

  return { getState, setState, subscribe };
};

When a component calls useStore(selector), it subscribes to the store and re-renders only when the selected slice changes. This is the key performance insight: Zustand re-renders are selector-scoped, not store-wide.

This is fundamentally different from React Context, where any context value change re-renders all consumers. It's also why Zustand outperforms naive Context usage at scale without requiring memoisation gymnastics.

Zustand v5 note: v5 dropped the use-sync-external-store shim package as a runtime dependency for the main create path, using the native useSyncExternalStore built into React 18 directly. This is why React 18 is now the minimum required version. The shim remains a peer dependency for zustand/traditional (for createWithEqualityFn and legacy equality patterns), but for standard usage you no longer need it. v5 is purely about dropping legacy support and tightening the foundation.

Setup

Installation is a single dependency with no peer requirements:

npm install zustand

No additional configuration for React Native, it works with both the old and new architecture (Bridgeless/JSI). TypeScript works out of the box with the curried create<T>()() syntax, which is required for correct type inference with middleware:

// store/useFilterStore.ts
import { create } from 'zustand';

type FilterMode = 'all' | 'active' | 'completed';

interface FilterState {
  mode: FilterMode;
  searchQuery: string;
  setMode: (mode: FilterMode) => void;
  setSearchQuery: (query: string) => void;
  reset: () => void;
}

export const useFilterStore = create<FilterState>()((set, _get, store) => ({
  mode: 'all',
  searchQuery: '',
  setMode: (mode) => set({ mode }),
  setSearchQuery: (query) => set({ searchQuery: query }),
  // store.getInitialState() — the v5-recommended reset pattern.
  // The older approach (capturing a separate `initialState` object and calling
  // set(initialState)) still works, but getInitialState() is cleaner because
  // the store itself guarantees the source of truth rather than a variable that
  // could drift.
  reset: () => set(store.getInitialState()),
}));

A few deliberate choices here: state and actions live together in the same definition, and the interface is explicit rather than inferred. At scale, explicit types are worth the verbosity.

Pattern 1: Selectors with `useShallow` : The Performance Foundation (and the Crash We Almost Shipped)

This is where most teams leave performance on the table and where we almost shipped a crash to production.

Every store call in a component should use a selector:

// ❌ Subscribes to the entire store — re-renders on any state change
const store = useFilterStore();

// ✅ Only re-renders when `mode` changes
const mode = useFilterStore(state => state.mode);

The trap with object selectors in v5 is more severe than a performance issue, it causes React to throw Maximum update depth exceeded, which unmounts your component tree. Zustand v5 uses useSyncExternalStore directly, which requires stable selector references. A selector that returns a new object on every call creates a reference that never stabilises, triggering an infinite reconciliation loop before React bails out:

// Both of these import paths are valid in v5:
import { useShallow } from 'zustand/react/shallow'; // recommended in the prevent-rerenders guide
// import { useShallow } from 'zustand/shallow';    // used in the v5 migration guide

// ❌ Returns a new object on every render
// In v5 this doesn't cause extra re-renders — it throws:
// "Uncaught Error: Maximum update depth exceeded"
const { mode, searchQuery } = useFilterStore(
  state => ({ mode: state.mode, searchQuery: state.searchQuery })
);

// ✅ useShallow stabilises the reference — only re-renders if values actually change
const { mode, searchQuery } = useFilterStore(
  useShallow(state => ({ mode: state.mode, searchQuery: state.searchQuery }))
);

v5 breaking change, this is a render error, not just a perf issue: In v4, you could pass shallow as a second argument to the store hook (e.g. useStore(selector, shallow)). In v5, this signature was removed. Object selectors without useShallow now cause React to throw a maximum update depth error that unmounts the affected component. This is the single most common crash teams hit when migrating from v4 to v5. Don't skip it.

In React Native, where component tree errors surface as blank screens, this distinction matters critically. useShallow for all object selectors is non-negotiable in v5.

Pattern 2: The Slice Architecture : One Store, Multiple Concerns

For large apps, a monolithic store with 40 fields and 30 actions becomes hard to reason about fast. The slice pattern lets you compose a single store from multiple logical domains while keeping each domain's code self-contained.

The insight I didn't expect during the migration: decomposing the Redux store into slices was actually easier than I anticipated, because the domains were already mostly independent. The coupling I'd assumed existed mostly didn't. That said, the key is typing each slice's set with Zustand's StateCreator type, something most examples skip but which is essential for correct TypeScript inference:

// store/slices/uiSlice.ts
import { StateCreator } from 'zustand';

export interface UISlice {
  isBottomSheetOpen: boolean;
  activeTab: string;
  openBottomSheet: () => void;
  closeBottomSheet: () => void;
  setActiveTab: (tab: string) => void;
}

// StateCreator<BoundStore, [], [], UISlice> gives set correct knowledge
// of the full composed store shape — essential when slices reference each other
export const createUISlice: StateCreator<
  UISlice & SessionSlice, [], [], UISlice
> = (set) => ({
  isBottomSheetOpen: false,
  activeTab: 'home',
  openBottomSheet: () => set({ isBottomSheetOpen: true }),
  closeBottomSheet: () => set({ isBottomSheetOpen: false }),
  setActiveTab: (tab) => set({ activeTab: tab }),
});

// store/slices/sessionSlice.ts
import { StateCreator } from 'zustand';

export interface SessionSlice {
  userId: string | null;
  locale: string;
  setUserId: (id: string | null) => void;
  setLocale: (locale: string) => void;
}

export const createSessionSlice: StateCreator<
  UISlice & SessionSlice, [], [], SessionSlice
> = (set) => ({
  userId: null,
  locale: 'en',
  setUserId: (id) => set({ userId: id }),
  setLocale: (locale) => set({ locale }),
});

// store/useBoundStore.ts — composed store
import { create } from 'zustand';
import { createUISlice, UISlice } from './slices/uiSlice';
import { createSessionSlice, SessionSlice } from './slices/sessionSlice';

type BoundStore = UISlice & SessionSlice;

export const useBoundStore = create<BoundStore>()((...args) => ({
  ...createUISlice(...args),
  ...createSessionSlice(...args),
}));

Each slice owns its state shape and actions. Consuming components import from useBoundStore with a selector scoped to the slice they need. No coupling between slices unless intentionally designed.

The rule of thumb for when to use slices vs separate stores: if two domains need to read each other's state inside an action, they belong in the same store. If they're genuinely independent, separate stores are cleaner:

// These are genuinely independent, separate stores are correct
export const useThemeStore = create<ThemeState>()(...);
export const useOnboardingStore = create<OnboardingState>()(...);

Pattern 3: The Middleware Stack : `devtools` + `persist` + `immer`

This is where Zustand earns its production credibility. Three middleware pieces, each solving a distinct problem. What I discovered in the migration is that none of these are nice-to-haves.

`devtools` : Non-Negotiable in Development

import { create } from 'zustand';
import { devtools } from 'zustand/middleware';

export const useFilterStore = create<FilterState>()(
  devtools(
    (set) => ({
      ...initialState,
      setMode: (mode) => set({ mode }, false, 'filter/setMode'),
      reset: () => set(initialState, false, 'filter/reset'),
    }),
    { name: 'FilterStore' }
  )
);

The third argument to set inside devtools is the action name, it appears in Redux DevTools (which Zustand integrates with via the same browser extension). Named actions make debugging dramatically easier. Make them a habit, not an afterthought.

`persist` : Surviving App Restarts

For state that should survive app kills (theme, locale, onboarding status, form drafts):

import { create } from 'zustand';
import { persist, createJSONStorage } from 'zustand/middleware';
import AsyncStorage from '@react-native-async-storage/async-storage';

interface ThemeState {
  colorScheme: 'light' | 'dark' | 'system';
  setColorScheme: (scheme: 'light' | 'dark' | 'system') => void;
}

export const useThemeStore = create<ThemeState>()(
  persist(
    (set) => ({
      colorScheme: 'system',
      setColorScheme: (scheme) => set({ colorScheme: scheme }),
    }),
    {
      name: 'theme-storage',
      storage: createJSONStorage(() => AsyncStorage),
      // Persist only state fields, never actions — keeps storage lean
      partialize: (state) => ({ colorScheme: state.colorScheme }),
      version: 1,
      migrate: (persistedState, version) => {
        if (version === 0) {
          // Migrate from v0 shape to v1 — add new field with default
          return { ...(persistedState as ThemeState), colorScheme: 'system' };
        }
        return persistedState as ThemeState;
      },
    }
  )
);

Two things most teams skip until they're burned:

partialize: Persist only the state fields, never actions. Persisting functions causes serialisation errors and inflates storage unnecessarily.

version + migrate: If you change the shape of persisted state in a new release, users on the old shape will hydrate into broken state on upgrade. Version from day one, it costs nothing upfront and saves a painful hotfix later.

v5 persist change: In v4 (up to 4.5.4), the initial state was automatically written to storage on store creation. In v5 this was removed. If you were relying on initial state being persisted without any user interaction, you'll need to explicitly write it after store creation. This is a silent migration gotcha that burned several teams.

`immer` : Ergonomic Nested Updates

For deeply nested state, Zustand's immer middleware lets you write mutating syntax that produces immutable updates under the hood:

import { create } from 'zustand';
import { immer } from 'zustand/middleware/immer';

interface FormState {
  fields: {
    name: { value: string; error: string | null };
    email: { value: string; error: string | null };
  };
  setFieldValue: (field: keyof FormState['fields'], value: string) => void;
  setFieldError: (field: keyof FormState['fields'], error: string | null) => void;
}

export const useFormStore = create<FormState>()(
  immer((set) => ({
    fields: {
      name: { value: '', error: null },
      email: { value: '', error: null },
    },
    setFieldValue: (field, value) =>
      set((state) => {
        state.fields[field].value = value; // Looks mutating, produces immutable update
      }),
    setFieldError: (field, error) =>
      set((state) => {
        state.fields[field].error = error;
      }),
  }))
);

Without immer, nested updates require verbose spread chains. Use it selectively, for flat state structures, it adds overhead with no benefit.

Pattern 4: Outside-React Access : The React Native Superpower

This pattern surprised me most during the migration. On Redux, accessing store state outside a component meant importing the store object and calling store.getState() : possible, but architecturally messy because the Redux store is a singleton you're supposed to connect through middleware. Zustand is different in a meaningful way.

React Native apps frequently need store access in non-component contexts : navigation handlers, push notification callbacks, Axios interceptors, analytics services. Every Zustand store exposes getState(), setState(), and subscribe() directly on the store object, no Provider boundary to escape, no hook rules to worry about:

import { useSessionStore } from './store/useSessionStore';

// --- In an Axios request interceptor (app init, not a component) ---
axiosInstance.interceptors.request.use((config) => {
  const userId = useSessionStore.getState().userId;
  if (userId) config.headers['X-User-Id'] = userId;
  return config;
});

// --- In a push notification handler ---
import { useUIStore } from './store/useUIStore';

Notifications.addNotificationReceivedListener((notification) => {
  if (notification.request.content.data.type === 'alert') {
    useUIStore.setState({ isBottomSheetOpen: true });
  }
});

// --- Subscribing to state changes outside React ---
// Requires subscribeWithSelector middleware on the store (see note below)
import { subscribeWithSelector } from 'zustand/middleware';

const useSessionStoreWithSelector = create<SessionState>()(
  subscribeWithSelector((set) => ({
    userId: null,
    setUserId: (id) => set({ userId: id }),
  }))
);

const unsubscribe = useSessionStoreWithSelector.subscribe(
  (state) => state.userId,           // selector
  (userId) => {
    analytics.identify(userId);      // callback — fires only when userId changes
  }
);

// Clean up when no longer needed
// unsubscribe();

Important: The two-argument subscribe(selector, callback) signature is not available on a basic Zustand store. It requires the subscribeWithSelector middleware to be applied during store creation. Without it, TypeScript will error and the selector argument will be silently ignored in JavaScript. If you only need the full-state listener (one argument), no middleware is needed.

This outside-React pattern is particularly valuable for:

Attaching user context to API request interceptors at app init
Syncing store state with deep-link handlers
Reading store state inside notification handler callbacks
Triggering analytics events when specific state slices change

The elegance here is that none of this requires any special Redux-style plumbing. The store is just a closure with a clean interface. That simplicity is Zustand's real design achievement.

The Architectural Boundary: Zustand vs React Query

This is the decision that matters most, and it deserves direct treatment.

┌─────────────────────────────────────────────────────────────────┐
│                     Application State                           │
├───────────────────────────┬─────────────────────────────────────┤
│       Client State        │          Server State               │
│       (Zustand)           │       (React Query / SWR)           │
├───────────────────────────┼─────────────────────────────────────┤
│ • Active filter/sort      │ • API response data                 │
│ • Selected item ID        │ • Paginated lists                   │
│ • Modal open/closed       │ • User profile from backend         │
│ • Theme / locale          │ • Notifications from API            │
│ • Onboarding step         │ • Any data with a TTL               │
│ • Form draft state        │ • Data shared across screens        │
│ • Navigation history      │ • Data that needs background sync   │
└───────────────────────────┴─────────────────────────────────────┘

The test is simple: does this data have a source of truth on a server? If yes, it belongs in a server state manager. If the source of truth is the user's current session and nothing more, it belongs in Zustand.

Where teams go wrong is storing API responses in Zustand. You end up building a manual cache: loading flags, error states, refetch logic, staleness checks, deduplication. It works until it doesn't, and debugging cache consistency bugs across screens in production is genuinely unpleasant. I know because we had exactly that problem in the Redux version, one of the primary reasons for the migration.

The two tools compose cleanly and coordinate naturally:

import { useQuery } from '@tanstack/react-query';
import { useFilterStore } from '../store/useFilterStore';

function ItemListScreen() {
  // Client state — Zustand owns this
  const filterMode = useFilterStore(state => state.mode);
  const setFilter = useFilterStore(state => state.setMode);

  // Server state — React Query owns this
  // isPending is the correct v5 flag — isLoading was redefined in v5
  // as `isPending && isFetching`, which returns false when enabled: false
  const { data: items, isPending } = useQuery({
    queryKey: ['items', filterMode],
    queryFn: () => api.getItems({ filter: filterMode }),
  });

  // filterMode from Zustand flows into the React Query key.
  // When the user changes the filter, Zustand updates, the key changes,
  // React Query fires a new fetch automatically — no manual wiring needed.
}

The elegance of this composition Zustand filter state flowing directly into a React Query cache key is something I didn't fully appreciate until I saw it eliminate about 60 lines of manual sync logic from our old Redux middleware. That's the real win from drawing the boundary correctly.

Testing Zustand Stores

Stores are plain JavaScript objects testing them without React is one of Zustand's most underappreciated advantages:

// __tests__/filterStore.test.ts
import { useFilterStore } from '../store/useFilterStore';

describe('FilterStore', () => {
  beforeEach(() => {
    // Reset store to initial state between tests
    useFilterStore.setState({ mode: 'all', searchQuery: '' });
  });

  it('updates filter mode', () => {
    useFilterStore.getState().setMode('completed');
    expect(useFilterStore.getState().mode).toBe('completed');
  });

  it('resets to initial state', () => {
    useFilterStore.setState({ mode: 'active', searchQuery: 'hello' });
    useFilterStore.getState().reset();

    const { mode, searchQuery } = useFilterStore.getState();
    expect(mode).toBe('all');
    expect(searchQuery).toBe('');
  });
});

No mocking, no test renderers, no async ceremony. Pure store logic tests run fast and are straightforward to reason about. For components, test via @testing-library/react-native as normal, Zustand stores hydrate naturally in the test environment without Provider wrappers. This alone made our test suite meaningfully faster after the migration.

Common Pitfalls

Over-globalising state. Not every piece of state needs to be global. If state is only used by one screen, useState is still the right call. Reach for Zustand when state genuinely needs to be shared across component trees or accessed outside components.

Storing server data in Zustand. Already covered, it leads to a manual cache implementation that's harder to build and maintain than just using React Query.

Object selectors without useShallow in v5. const store = useStore() subscribes to every field. Object selectors without useShallow cause React to throw a maximum update depth error in v5. Always use primitive selectors or useShallow for multi-field selections. No exceptions.

Not versioning persisted state. The first time you change a persisted store's shape without a migration, a subset of users will see broken state on upgrade. Version from the start.

Using subscribe(selector, callback) without subscribeWithSelector. This is a silent failure in JS and a TypeScript error in TS. If you need selector-scoped subscriptions outside React, apply the middleware during store creation.

When to Reach for Something Else

Zustand is not always the answer:

React Query / SWR : for any server data. Full stop.
useState / useReducer : for local component state that doesn't need sharing
Jotai : if you prefer an atomic model and want fine-grained subscriptions without selectors
Redux Toolkit : if your team has deep Redux investment, needs time-travel debugging, or has complex cross-cutting middleware requirements

Zustand sits in a sweet spot: minimal API, near-zero boilerplate, excellent performance, and just enough structure to scale. For most React Native apps managing client state, it's the right default in 2026.

What the Migration Actually Changed

After going through this, the biggest shift wasn't in the code, it was in how we reason about state. Redux pushed us toward treating everything as events dispatched into a central pipeline. That's powerful, but it also meant state decisions lived far from the components that needed them, and debugging required jumping between actions, reducers, and selectors that were never in the same file.

Zustand pushed state decisions back toward the components, while still giving us the global access we need. The result was a codebase that new engineers could read without a mental model of the entire event graph.

If you're on Redux and feeling the friction, the migration is more mechanical than it seems. The patterns in this post should give you enough foundation to make that call confidently.

Key Takeaways

Object selectors without useShallow cause render errors in v5. Zustand v5 uses native useSyncExternalStore, which requires stable selector references. A selector returning a new object on every render triggers Maximum update depth exceeded. Always use useShallow for any multi-field object selector. This is the number one migration crash from v4.

The slice pattern scales cleanly but type your StateCreator. Untyped set in slice functions is a common gap in examples. Use StateCreator<BoundStore, [], [], SliceType> for correct inference.

The middleware stack is where Zustand earns production credibility. devtools with named actions, persist with versioning, immer for nested state.

Outside-React access is a genuine architectural advantage. getState(), setState(), and subscribe() work anywhere. For selector-scoped subscriptions outside React, apply subscribeWithSelector middleware.

The client/server boundary is the most important decision. Zustand for client state, React Query for server state. Don't cross the streams.

What does your current React Native state setup look like, still on Redux, or already on Zustand? Did you hit the useShallow crash in v5? I'm curious where other teams draw the line between client and server state. Drop a comment below.

I Fixed Stale Data Across Every Screen in React Native with 3 React Query Patterns

Likhit Kumar V P — Wed, 25 Feb 2026 15:40:26 +0000

Environment: React Native 0.76+ · @tanstack/react-query v5 · TypeScript

I was building a React Native app where users could interact with the same data from multiple screens. Everything seemed fine during early testing until I noticed something deeply frustrating: updating data on one screen didn't reflect on another until I manually refreshed it.

Sound familiar? Here's how I diagnosed it, fixed it with 3 focused React Query patterns, and what I learned along the way.

The Problem

The app had three screens showing overlapping data:

Screen A : Shows a list of items
Screen B : Shows the same items in a different view
Screen C : Shows item details with edit capability

When a user marked an item complete on Screen A, navigating to Screen B still showed it as incomplete. Users had to pull-to-refresh on every screen after every action. The app felt broken, because it was.

Root Cause: Isolated State

After some digging, the culprit was clear. Each screen used its own hook with independent useState:

import { useState } from 'react';
import { api } from '../lib/api';

// Screen A hook
function useListA() {
  const [items, setItems] = useState([]);

  const markComplete = async (id: string) => {
    await api.markComplete(id);
    setItems(prev => prev.map(item =>
      item.id === id ? { ...item, completed: true } : item
    ));
    // Other screens have no idea this happened
  };
}

// Screen B hook — completely separate state
function useListB() {
  const [items, setItems] = useState([]);
  // No connection to Screen A's state whatsoever
}

The architecture looked like this:

Screen A          Screen B          Screen C
   │                 │                 │
   ▼                 ▼                 ▼
useState          useState          useState
(isolated)        (isolated)        (isolated)
   │                 │                 │
   └─────────────────┴─────────────────┘
                     │
                     ▼
                 Backend API

Each screen fetched and managed data independently. When one mutated data, the others had no idea. This isn't a bug, it's the natural consequence of uncoordinated local state managing shared server data.

Why Not Just Use Zustand?

This question comes up a lot, and it's worth addressing directly before diving into the solution.

Zustand is a client state manager. It's excellent for data that lives purely inside your app UI state, filter selections, modal toggles, user preferences. It has no built-in concept of staleness, background refetching, or cache invalidation because it doesn't need one.

React Query is a server state manager. It's designed specifically for data that originates from a backend for fetching, caching, deduplicating requests, and keeping that data fresh across your app.

Using Zustand to solve this problem would mean manually writing all the cache logic React Query gives you for free. In fact, the ideal architecture uses both React Query for server data, Zustand for client-only state. That's a topic for another post. For now, our problem is server state sync, so React Query is the right tool.

The Fix: 3 React Query Patterns

I had React Query installed but wasn't using it effectively each screen was still managing its own fetch lifecycle. The fix came down to three focused patterns.

Pattern 1: A Query Keys Factory

A centralised key system is what makes targeted cache invalidation possible. Instead of scattering string literals across your codebase, you define them once:

// lib/query-keys.ts
export const queryKeys = {
  items: {
    all: ['items'] as const,
    list: (userId: string) => ['items', 'list', userId] as const,
    detail: (id: string) => ['items', 'detail', id] as const,
  },
};

// Define what needs invalidating after each action
export const invalidationGroups = {
  itemUpdated: [queryKeys.items.all],
  itemCreated: [queryKeys.items.all],
  itemDeleted: [queryKeys.items.all],
};

The as const assertions give you full TypeScript inference downstream. Grouping by action means you invalidate precisely what's needed.

Pattern 2: Mutations with Auto-Invalidation

This is where the real magic happens. Mutation hooks that automatically invalidate related queries after every operation:

// hooks/useMarkComplete.ts
import { useMutation, useQueryClient } from '@tanstack/react-query';
import { api } from '../lib/api';
import { queryKeys, invalidationGroups } from '../lib/query-keys';

// useSessionStore is a Zustand store holding auth state.
// Replace this with however your app stores the current user —
// Clerk, Firebase Auth, Supabase, or your own auth hook.
import { useSessionStore } from '../store/useSessionStore';

interface Item {
  id: string;
  completed: boolean;
  // ...other fields
}

export function useMarkComplete() {
  const queryClient = useQueryClient();
  const userId = useSessionStore(state => state.userId);

  return useMutation({
    mutationFn: (id: string) => api.markComplete(id),

    // Optimistic update — instant UI feedback before the API responds
    onMutate: async (id) => {
      // Cancel any in-flight queries to prevent race conditions
      await queryClient.cancelQueries({ queryKey: queryKeys.items.all });

      // Snapshot current data so we can roll back if needed
      const previous = queryClient.getQueryData(queryKeys.items.list(userId!));

      // Optimistically update the cache right now
      queryClient.setQueryData(
        queryKeys.items.list(userId!),
        (old: Item[] | undefined) =>
          old?.map(item => item.id === id ? { ...item, completed: true } : item)
      );

      return { previous };
    },

    // Rollback on error — restore the snapshot
    onError: (_err, _id, context) => {
      if (context?.previous) {
        queryClient.setQueryData(queryKeys.items.list(userId!), context.previous);
      }
      // Surface the error to your UI here — toast, alert, inline message, etc.
    },

    // Use onSettled (not onSuccess) so invalidation fires on both
    // success AND error — prevents stale data after a failed mutation
    onSettled: () => {
      invalidationGroups.itemUpdated.forEach(key => {
        queryClient.invalidateQueries({ queryKey: key });
      });
    },
  });
}

Why onSettled instead of onSuccess? If we only invalidate on success, a failed mutation leaves the cache with the optimistically-updated (incorrect) data indefinitely. onSettled runs regardless of outcome, so the cache always resolves to ground truth after any mutation. This is the React Query v5 recommended approach.

A common v5 confusion: React Query v5 removed onSuccess, onError, and onSettled callbacks from useQuery and useInfiniteQuery but they remain fully supported in useMutation. Mutations are imperative by nature, so callbacks are still the right model there. The switch to onSettled here is a best-practice recommendation, not a required v5 migration.

Why userId!? The non-null assertion is safe here because the query is guarded with enabled: !!userId (see Pattern 3 below). The query will never fire and therefore this mutation will never be callable when userId is null.

Pattern 3: Connect to React Native App State

React Query's refetchOnWindowFocus works automatically in web browsers, but React Native needs an explicit bridge to the OS-level app state:

// app/_layout.tsx
import { QueryClient, QueryClientProvider, focusManager } from '@tanstack/react-query';
import { AppState, AppStateStatus } from 'react-native';
import { useEffect } from 'react';

// Note: In React Query v5, `cacheTime` was renamed to `gcTime`.
// If you're on v4, use `cacheTime` instead of `gcTime`.
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 2 * 60 * 1000,   // Data is fresh for 2 minutes
      gcTime: 5 * 60 * 1000,      // Cache persists for 5 minutes after unmount
      refetchOnWindowFocus: true,
    },
    mutations: {
      retry: 0, // Don't auto-retry mutations — let the user decide
    },
  },
});

// Bridges React Native's AppState to React Query's focus manager.
// Without this, refetchOnWindowFocus does nothing in a native context.
function AppStateHandler() {
  useEffect(() => {
    const subscription = AppState.addEventListener(
      'change',
      (status: AppStateStatus) => {
        focusManager.setFocused(status === 'active');
      }
    );
    return () => subscription.remove();
  }, []);

  return null;
}

export default function RootLayout() {
  return (
    <QueryClientProvider client={queryClient}>
      <AppStateHandler />
      {/* rest of your app */}
    </QueryClientProvider>
  );
}

When the user backgrounds and returns to the app, focusManager triggers a refetch of any stale queries keeping data fresh across app sessions, not just screen navigations.

The New Architecture

Screen A          Screen B          Screen C
   │                 │                 │
   └─────────────────┴─────────────────┘
                     │
                     ▼
   ┌─────────────────────────────────────┐
   │     React Query Shared Cache        │
   │         ['items'] queries           │
   └─────────────────────────────────────┘
                     │
        ┌────────────┴────────────┐
        │                         │
        ▼                         ▼
   On Mutation:              All screens
   invalidateQueries()  →    auto-refetch

Now when any screen calls markComplete():

UI updates instantly via the optimistic update
API call happens in the background
On settle (success or error), related queries are invalidated
Every screen subscribed to those queries auto-refreshes

No manual refresh. No stale data. No coordination code between screens.

Keeping It Backward Compatible

One concern with refactoring is breaking existing screens. The cleanest approach is to wrap the new React Query internals behind the same hook interface your screens already use:

// hooks/useItems.ts
import { useQuery, useQueryClient } from '@tanstack/react-query';
import { api } from '../lib/api';
import { queryKeys } from '../lib/query-keys';
import { useMarkComplete } from './useMarkComplete';
import { useSessionStore } from '../store/useSessionStore';

export function useItems() {
  const queryClient = useQueryClient();
  const userId = useSessionStore(state => state.userId);
  const markCompleteMutation = useMarkComplete();

  const query = useQuery({
    queryKey: queryKeys.items.list(userId!),
    queryFn: () => api.getItems(userId!),
    // Only fetches when userId exists — makes the userId! assertion above safe
    enabled: !!userId,
  });

  return {
    // Same shape as before — existing screens need zero changes
    data: query.data ?? [],
    // isPending is the correct v5 flag for "data not loaded yet".
    // isLoading was redefined in v5 as isPending && isFetching, which
    // returns false when enabled: false — causing a silent empty-state
    // bug on first render before userId is available.
    loading: query.isPending,
    refreshing: query.isRefetching,
    error: query.error,
    // mutateAsync returns a Promise and throws on error — wrap in try/catch.
    // Use mutate instead if you prefer fire-and-forget without error throwing.
    markComplete: (id: string) => markCompleteMutation.mutateAsync(id),
    refresh: () => queryClient.invalidateQueries({
      queryKey: queryKeys.items.all,
    }),
  };
}

Your screens call useItems() exactly as they did before. The sync behaviour is just... there now.

Quick Start Template

If you're starting fresh:

npm install @tanstack/react-query

import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query';
import { api } from '../lib/api';

// 1. Query keys
const keys = {
  items: {
    all: ['items'] as const,
    list: () => ['items', 'list'] as const,
  }
};

// 2. Query hook
const useItems = () => useQuery({
  queryKey: keys.items.list(),
  queryFn: () => api.getItems(),
  staleTime: 2 * 60 * 1000,
});

// 3. Mutation with invalidation on settle
const useUpdateItem = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (id: string) => api.updateItem(id),
    onSettled: () => {
      queryClient.invalidateQueries({ queryKey: keys.items.all });
    },
  });
};

// 4. Use in any screen — they'll all stay in sync
function AnyScreen() {
  const { data } = useItems();
  const { mutate: update } = useUpdateItem();

  // Replace data[0]?.id with however you get the target item's id
  // e.g. from route params, a selected state, a FlatList renderItem, etc.
  const itemId = data[0]?.id;

  return (
    <Button onPress={() => update(itemId)} title="Mark Complete" />
  );
}

Key Takeaways

Multiple useState hooks for the same server data will always drift. It's not a discipline problem, it's an architectural one. Centralise with React Query.

Design your query keys for invalidation from the start. Flat string keys are fine for small apps, but a factory pattern scales cleanly and eliminates typo bugs.

Use onSettled, not onSuccess, for cache invalidation. It guarantees the cache resolves to ground truth after every mutation, regardless of outcome.

Always guard queries with enabled: !!userId. In React Native, auth state often isn't available on the first render. Without this guard, your query fires with a null user ID and fails silently.

Optimistic updates are table stakes in 2026. Users expect instant feedback. The rollback pattern handles failures gracefully without complex error state.

Backward-compatible migrations are always possible. Wrap new internals behind existing interfaces and refactor incrementally without coordinating a team-wide rewrite.

React Native needs explicit AppState integration. Don't skip the focusManager setup without it, refetchOnWindowFocus is a silent no-op in a native context.

What's Next

This solves server state sync cleanly. But what about client-only state — filters, selections, UI flags — that also needs to be shared across screens?

That's where Zustand comes in, and it pairs beautifully with React Query. Upcoming Post covers how to combine both tools into a complete React Native state architecture, with clear boundaries on what belongs where.

Have you been managing cross-screen state with manual refreshes? Or already using React Query, what patterns have worked for you? Drop a comment below.

I Tried to Send Emails Using Gmail SMTP, Here's What Actually Worked

Likhit Kumar V P — Sun, 22 Feb 2026 10:37:01 +0000

I was setting up email sending for a side project recently, nothing fancy, just a welcome email when a user signs up. Grabbed a Nodemailer tutorial, followed the steps, and ran straight into Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Turns out the tutorial was outdated. Gmail's rules have changed, and a surprising amount of advice floating around the internet just doesn't work anymore.

So here's what actually works in 2026.

What I Was Trying to Do

My stack was simple: a Node.js backend, no paid services, and a Gmail account I already had. The plan was to use Gmail SMTP with Nodemailer that's free, no sign-ups, no credit cards. Should've been straightforward.

Most tutorials I found were written in 2020 or 2021. Gmail's rules have changed a lot since then, and a good chunk of that advice is now broken. Let me clear up what's dead and what still works.

First, The Things That Are Dead (Don't Even Try)

Before I tell you what works, let me tell you what I wasted time on so you don't have to.

The "Less Secure Apps" toggle - Every old tutorial mentioned this. Go to your Google account settings, flip this switch, done. Except when I looked for it, it simply didn't exist. Turns out Google permanently removed it back in May 2022. It's gone.

Using my actual Gmail password - My first instinct was just to throw my email and password into the Nodemailer config like this:

auth: {
  user: 'me@gmail.com',
  pass: 'myActualPassword123', // ❌ This will NOT work
}

Instant rejection. Google no longer accepts your real password over SMTP for accounts with 2-Step Verification. It feels like it should work but it doesn't.

After burning time on both of those dead ends, I finally found the two approaches that actually work in 2026.

Method 1: App Passwords - The Quick Fix That Got Me Unblocked

The first thing that actually worked for me was App Passwords. An App Password is a special 16-character code that Google generates for your account. It's separate from your real password and designed specifically for apps and scripts that need SMTP access.

Here's how I set it up.

Step 1 : Enable 2-Step Verification

App Passwords only exist on accounts with 2-Step Verification turned on. If you haven't done this already:

Go to myaccount.google.com
Click Security in the left sidebar
Under "How you sign in to Google", click 2-Step Verification and follow the setup

Step 2 : Generate an App Password

Back in Security, scroll down and click App passwords (Can't see it? 2-Step Verification isn't active yet)
Give it a name "Nodemailer Side Project"
Click Create
Copy the 16-character code. Write it down somewhere as you won't see it again

Step 3 : Wire It Into Nodemailer

I created a .env file first :

GMAIL_USER=me@gmail.com
GMAIL_APP_PASSWORD=abcdefghijklmnop

Heads up: Google displays the App Password with spaces like abcd efgh ijkl mnop. Remove the spaces when you paste it into your .env.

Then the Nodemailer config:

require('dotenv').config();
const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: process.env.GMAIL_USER,
    pass: process.env.GMAIL_APP_PASSWORD,
  },
});

async function sendEmail() {
  try {
    const info = await transporter.sendMail({
      from: `"My App" <${process.env.GMAIL_USER}>`,
      to: 'recipient@example.com',
      subject: 'It works!',
      html: '<p>Finally. <strong>It works.</strong></p>',
    });
    console.log('Email sent! Message ID:', info.messageId);
  } catch (error) {
    console.error('Error:', error);
  }
}

sendEmail();

And it worked. First email landed in the inbox cleanly.

The Gotcha That Caught Me (On My Cloud Server)

Everything worked perfectly on my local machine. Then I deployed to my VPS and it broke again with same Invalid login error as before. I nearly lost my mind.

What was happening: Gmail's security systems saw a login attempt from a cloud server in a different country from my usual location and blocked it. The fix was weirdly simple, I visited accounts.google.com/DisplayUnlockCaptcha while signed into my Google account, clicked Allow, and then the server could connect fine.

I tried to set the from field to noreply@myapp.com to look more professional. Gmail silently replaced it with my actual @gmail.com address on every single email. You cannot send as a custom from address via Gmail SMTP on a personal account. Your emails will always come from your Gmail.

But Then I Read the Fine Print

After the relief wore off, I went back and read Google's own documentation more carefully. And there it was:

"App passwords are not recommended and are unnecessary in most cases."

Google isn't planning to keep App Passwords around forever. They're actively pushing developers toward OAuth 2.0, and at some point App Passwords will likely be retired with no concrete date given.

For my side project at 3 AM, App Passwords were the right call to get unblocked. But I knew I needed to come back and do this properly. So the next day, I set up OAuth 2.0.

Method 2: OAuth 2.0

OAuth 2.0 takes maybe 20 minutes to set up the first time, but it's Google's actual recommended path and won't suddenly break when they pull the plug on App Passwords. Instead of storing a password, you go through a one-time authorization flow and get a refresh token. Nodemailer uses this to generate short-lived access tokens automatically.

You'll need one extra package:

npm install googleapis

Step 1 : Create a Google Cloud Project

Go to console.cloud.google.com
Click Select a project → New Project
Name it something like my-app-email and hit Create
Make sure it's selected in the top bar before continuing

Step 2 : Enable the Gmail API

In the left menu go to APIs & Services → Library
Search for Gmail API, click it, and hit Enable

Step 3 : Configure the OAuth Consent Screen

This part tripped me up the first time because the UI is a bit overwhelming. Here's what actually matters:

Go to APIs & Services → OAuth consent screen
Choose External, click Create
Fill in App name, support email, and developer contact email.
On the Scopes step, click Add or Remove Scopes, manually type https://mail.google.com/ into the field, click Add to Table, then Update
On the Test users step, this is the part I initially skipped and then wondered why nothing worked. add your own Gmail address here
Save and continue through to the end

Step 4 : Create OAuth Credentials

Go to APIs & Services → Credentials
Click + Create Credentials → OAuth client ID
Choose Web application
Under Authorized redirect URIs add exactly this: https://developers.google.com/oauthplayground
Click Create and copy your Client ID and Client Secret

Step 5 : Get Your Refresh Token via OAuth Playground

This is the clever bit. Google has a tool called OAuth Playground that lets you authorize scopes and grab tokens without writing any extra code.

Go to developers.google.com/oauthplayground
Click the ⚙️ gear icon in the top right
Check "Use your own OAuth credentials" and enter your Client ID and Client Secret
In the left panel, scroll to Gmail API v1 and select https://mail.google.com/
Click Authorize APIs → sign in with your Gmail account → allow access
Click Exchange authorization code for tokens
Copy the Refresh Token from the response

Important thing I learned the hard way: While your app is in "Testing" mode on Google Cloud Console, refresh tokens expire after 7 days. You'll need to regenerate them periodically. For a personal or internal tool that's totally manageable just set a calendar reminder. To get permanent tokens, you'd need to publish the app, which for sensitive scopes like Gmail requires a Google review.

Step 6 : Update `.env` and Write the Code

GMAIL_USER=me@gmail.com
GOOGLE_CLIENT_ID=your_client_id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=your_client_secret
GOOGLE_REFRESH_TOKEN=your_refresh_token

require('dotenv').config();
const nodemailer = require('nodemailer');
const { google } = require('googleapis');

const OAuth2 = google.auth.OAuth2;

async function createTransporter() {
  const oauth2Client = new OAuth2(
    process.env.GOOGLE_CLIENT_ID,
    process.env.GOOGLE_CLIENT_SECRET,
    'https://developers.google.com/oauthplayground'
  );

  oauth2Client.setCredentials({
    refresh_token: process.env.GOOGLE_REFRESH_TOKEN,
  });

  const accessToken = await new Promise((resolve, reject) => {
    oauth2Client.getAccessToken((err, token) => {
      if (err) reject(new Error('Failed to get access token: ' + err));
      resolve(token);
    });
  });

  return nodemailer.createTransport({
    service: 'gmail',
    auth: {
      type: 'OAuth2',
      user: process.env.GMAIL_USER,
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
      refreshToken: process.env.GOOGLE_REFRESH_TOKEN,
      accessToken: accessToken,
    },
  });
}

async function sendEmail() {
  try {
    const transporter = await createTransporter();

    await transporter.verify(); // Sanity check before sending
    console.log('Connected to Gmail ✓');

    const info = await transporter.sendMail({
      from: `"My App" <${process.env.GMAIL_USER}>`,
      to: 'recipient@example.com',
      subject: 'Hello via OAuth 2.0',
      html: '<p>Sent properly this time, with <strong>OAuth 2.0</strong>.</p>',
    });

    console.log('Email sent:', info.messageId);
  } catch (error) {
    console.error('Error:', error);
  }
}

sendEmail();

Which One Should You Use?

	App Password	OAuth 2.0
Setup time	~5 minutes	~20 minutes
Works in 2026?	✅ Yes	✅ Yes
Future-proof?	⚠️ Uncertain	✅ Google-recommended
Token expiry	Never	7 days (Testing mode)
Best for	Dev / quick prototypes	Anything in production

My rule: App Password to get something working locally, OAuth 2.0 before anyone else touches it.

Don't Forget This Before You Push to Git

The first time I set all this up I nearly committed my .env file. Do this immediately after creating it:

echo ".env" >> .gitignore

If your credentials ever get exposed, here's how to recover fast:

App Password - Delete it at myaccount.google.com/apppasswords and generate a fresh one
OAuth tokens - Revoke them at myaccount.google.com/permissions and regenerate via OAuth Playground

Know When to Move On From Gmail

Gmail is brilliant for getting off the ground, but it has real ceilings around 500 emails/day on a free account. Each recipient counts individually, so one email to 5 people eats 5 of your daily quota. Hit the limit and you'll see SMTP error 454 4.7.0 until the quota resets the next day.

If you find yourself hitting that ceiling, or you need a custom from address like hello@yourapp.com, or you want delivery analytics, it's time to look at Resend, Postmark, or Brevo. All have free tiers that are genuinely useful for indie hackers and small teams, and they won't quietly block your cloud server IP.

Hope this saves you the 3 AM spiral. Drop a comment if you get stuck on any step I've probably hit that exact wall too.

Which Local LLM is Better? A Deep Dive into Open-Source AI Models in 2026 (Benchmarked)

Likhit Kumar V P — Sat, 14 Feb 2026 12:37:47 +0000

Here's the problem: Everyone claims their model is "The Best." No one tells you which specific model to use for which task. I've analyzed every major open-source LLM benchmark from February 2026 to answer one question: Which free AI model actually wins for your specific use case?

This isn't about vague claims. This is about hard data from SWE-bench (real GitHub issues), AIME 2025 (olympiad math), and agent benchmarks. Let me show you which open-source alternatives to ChatGPT and Claude actually work.

- -

Why "Best LLM" Is the Wrong Question

Here's what no one tells you: there is no single "best" AI model.

A model that dominates coding benchmarks often fails at math. One that excels at tool use might struggle with pure reasoning. This is why you need to match the local LLM to your specific task.

I've broken down the top open-source language models into three categories based on February 2026 benchmarks:

Coding & Software Engineering
Reasoning
Agentic Workflows & Tool Use

Let's see which free AI models win with proof.

- -

Best Open-Source LLM for Coding: The Competition

The Benchmark: SWE-bench Verified (Real Software Engineering)

Forget "write a hello world function." SWE-bench Verified tests 500 real GitHub issues from production Python repositories. The AI model must:

Read the bug report
Navigate the codebase
Generate a working patch
Pass all existing tests This measures actual software engineering capability, not toy problems.

SWE-bench Verified Leaderboard (February 2026):
✓ Proprietary Models:
1. Claude Opus 4.5: 80.9%
2. Claude Opus 4.6: 80.8%
3. GPT-5.2: 80.0%
⭐ Open-Source Models:
4. Kimi K2.5: 76.8% ← HIGHEST OPEN-SOURCE
5. GLM-4.7: 73.8%
6. DeepSeek V3.2: 73.1%
7. Qwen3-Coder-Next: 70.6%

- -

Kimi K2.5 (Open-Weights)

Score: 76.8% on SWE-bench Verified - Highest Open-Source Score

Why Kimi K2.5 Leads on Coding Benchmarks:

Kimi K2.5, released January 27, 2026, achieves the highest open-source score on SWE-bench Verified at 76.8%. It's particularly strong at:

Visual-to-code generation (convert designs/screenshots to functional code)
Front-end development with animations and interactivity
Multi-step debugging workflows
Terminal-based development tasks

Technical Specs:

1 trillion parameters (32B active per token)
Native multimodal (text, images, video)
256K context window
Uses INT4 quantization natively
License: MIT with commercial restrictions (free for companies with under 100M monthly active users)

Additional Coding Benchmarks:

Kimi K2.5 Performance:
- SWE-bench Verified: 76.8% ← HIGHEST
- SWE-bench Multilingual: 73.0%
- LiveCodeBench v6: 85.0%
- Terminal-Bench 2.0: 40.45%

Special Features:

Agent Swarm: Coordinates up to 100 specialized sub-agents for parallel task execution
Visual Coding: Converts images/videos into functional code
Kimi Code: Open-source terminal tool (rival to Claude Code)
Four modes: Instant, Thinking, Agent, Agent Swarm (beta)

Hardware Requirements:

With native INT4: ~240GB VRAM minimum
Practical: Cloud GPU rental or API access
Speed: 44 tokens/second via API
Cost: Competitive pricing with free tier available

Important Note: Kimi K2.5 uses MIT license with commercial restrictions. Companies with over 100 million monthly active users require special licensing. For most users and businesses, this is fully open-source.

When to Use Kimi K2.5:

Converting UI designs to code
Front-end development with complex animations
Multi-modal coding (working with images/videos)
Agentic coding workflows requiring tool coordination
Projects where visual understanding matters

- -

DeepSeek V3.2 (Open-Source)

Score: 73.0% on SWE-bench Verified

Why DeepSeek V3.2 Is Strong for Coding:

DeepSeek V3.2 (the current version as of February 2026) achieves one of the highest scores among open-source AI models on the industry-standard SWE-bench. Only 7–8% behind proprietary models like Claude Opus 4.5 (80.9%).

SWE-bench Verified Leaderboard (February 2026):
✓ Proprietary Models:
1. Claude Opus 4.5: 80.9%
2. Claude Opus 4.6: 80.8%
3. GPT-5.2: 80.0%
⭐ Open-Source Models:
4. Kimi K2.5: 76.8% ← HIGHEST OPEN-SOURCE
5. GLM-4.7: 73.8%
6. DeepSeek V3.2: 73.1%
7. Qwen3-Coder-Next: 70.6%

Technical Specs (DeepSeek V3.2):

671 billion parameters (37B active per token)
Mixture-of-Experts (MoE) architecture
128K context window
Trained on 14.8 trillion tokens
License: MIT (fully free, commercial use allowed)
Cost: ~$0.27–0.55 per million tokens (API)

Hardware Requirements for Self-Hosting:

336GB VRAM with 4-bit quantization
Requires 4–5x NVIDIA H100 or H200 GPUs
Practical reality: Most users access via API

Real-World Performance:

Automated bug fixing: Excellent
Code review and refactoring: Strong
Multi-file modifications: Best-in-class for open source
API latency: 20–40 tokens/second - -

GLM-4.7 - Best for AI Coding Agents

Score: 73.8% on SWE-bench Verified

GLM-4.7 technically scores 0.8% higher than DeepSeek V3.2, but this comes with a caveat: the score may include enhanced scaffolding or agentic frameworks. For direct model comparisons, DeepSeek V3.2 is more consistent.

However, GLM-4.7 has a killer feature: it runs on consumer hardware.

Why Choose GLM-4.7:

MIT License (fully open-source)
Runs on single RTX 4090 (24GB VRAM) using GLM-4.7-Flash variant
Designed specifically for agentic coding (Claude Code, Cursor, Cline)
"Preserved Thinking" architecture maintains reasoning across turns

Technical Specs (GLM-4.7-Flash):

30B total parameters, 3B active (efficient!)
128K context window
Native tool calling
Speed: 25–35 tokens/second on consumer GPU

Additional Coding Benchmarks:

GLM-4.7 Performance:
- SWE-bench Multilingual: 66.7%
- Terminal-Bench 2.0: 41.0%
- LiveCodeBench: 84.9%
- Agent tool use (τ²-Bench): 87.4%

When to Choose GLM-4.7 Over DeepSeek V3.2:

You have consumer hardware (24GB GPU)
You're building AI coding agents
You need local inference without cloud dependency
You want multi-turn coding sessions with context retention

- -

Reasoning: Mathematical and Scientific Intelligence

Reasoning isn't a single capability. It breaks down into distinct subcategories that test different cognitive abilities. Let's examine how open-source LLMs perform across mathematical and scientific domains.

Subcategory: Mathematical Reasoning (AIME 2025 Benchmark)

The Benchmark: AIME 2025–30 problems from the American Invitational Mathematics Examination. These are competition-level math problems requiring multiple reasoning steps.

The Data (from Artificial Analysis Intelligence Index):

AIME 2025 Leaderboard (February 2026):
✓ Proprietary Models:
1. GPT-5.2: 99.0%
2. Gemini 2.0 Flash Thinking: 97.0%
3. Gemini 2.0 Pro Thinking: 95.7%
⭐ Open-Source Models:
7. GLM-4.7: 95.7% ← TOP OPEN-SOURCE
8. DeepSeek V3.2: 93.1%
9. Qwen2.5-Max: 92.3%

GLM-4.7 (Open-Source) - Mathematical Reasoning Leader

Score: 95.7% on AIME 2025

Why It Leads:

Highest verified open-source score on AIME 2025
Matches proprietary Gemini 2.0 Pro Thinking at 95.7%
Strong mathematical reasoning architecture

Use Cases:

Mathematical proof generation
Physics problem solving
Quantitative finance modeling
STEM education applications

- -

DeepSeek V3.2 (Open-Source) - Strong Math Performance

Score: 93.1% on AIME 2025

DeepSeek V3.2 achieves 93.1% on AIME 2025, placing it just behind GLM-4.7's 95.7% but still in frontier territory for open-source models.

Technical Specs:

671B parameters (37B active via MoE)
Thinking mode available
MIT License
Hardware: Requires cloud GPUs or API access

This is significant: Near-frontier math performance with full MIT licensing and strong versatility across all benchmark categories.

- -

Qwen2.5-Max (Open-Source) - Consumer-Friendly Math Option

Score: 92.3% on AIME 2025

Strong math performance with more accessible hardware requirements than DeepSeek.

Technical Specs:

Trillion-scale MoE architecture
Apache 2.0 License
Supports 119 languages

- -

Subcategory: Scientific Reasoning (GPQA Diamond)

The Benchmark: GPQA Diamond - 198 PhD-level questions in physics, biology, chemistry. Designed to be "Google-proof" (even experts with web access only score 65–70%).

Honest Assessment: Open-source models lag behind proprietary models by 2–4% in this category.

Best Open-Source Performance:

GPQA Diamond Scores (February 2026):
✓ Proprietary Models:
1. Gemini 3 Pro: 90.8%
2. GPT-5.2: 90.3%
⭐ Open-Source Models:
1. GLM-4.7: 85.7%
2. DeepSeek V3.2: ~85–88% (estimated)
3. Qwen3 variants: ~84–87%

GLM-4.7 (Open-Source) - Best Available for Scientific Reasoning

Score: 85.7% on GPQA Diamond

GLM-4.7 leads open-source models on PhD-level scientific reasoning, though proprietary models maintain a 4–5% advantage.

The Reality: For PhD-level scientific research requiring the absolute highest accuracy, proprietary models (Gemini 3 Pro, GPT-5) currently have an edge. However, for most scientific applications, the 4–5% gap isn't critical.

When Open-Source Works Well:

General scientific questions (undergraduate/Master's level)
Scientific coding and data analysis
Literature review and synthesis
Research assistance (non-critical calculations)

When to Consider Proprietary:

High-stakes research decisions
PhD dissertation-level work
Peer-reviewed publication support
Breakthrough discovery verification

- -

Subcategory: General Reasoning (MMLU, HLE)

Benchmarks: MMLU (general knowledge across 57 subjects), HLE (Humanity's Last Exam - multi-domain expert knowledge)

Top Open-Source Models:

General Reasoning Performance (February 2026):
1. DeepSeek V3.2: Strong across MMLU and expert domains
2. Qwen2.5-Max: MMLU: 84–86%
3. Kimi K2.5: HLE: 50.2% with tools (highest reported)
4. GLM-4.7: HLE: 42.8% with tools

DeepSeek V3.2 (Open-Source) - Most Well-Rounded Reasoner

MMLU and Other General Benchmarks: Competitive with Claude 3.5 Sonnet

DeepSeek V3.2 maintains strong general reasoning across diverse benchmarks, making it the most well-rounded open-source AI model for reasoning tasks.

Why It's Versatile:

Consistent performance across 57 MMLU subjects
Strong on both academic and practical knowledge
Reliable for general-purpose reasoning applications - -

Summary: Reasoning Category Winners

Mathematical Reasoning:

Champion: GLM-4.7 (95.7% AIME) - MIT License
Strong Alternative: DeepSeek V3.2 (93.1% AIME) - MIT License
Multilingual Option: Qwen2.5-Max (92.3% AIME) - Apache 2.0

Scientific Reasoning:

Best Open-Source: GLM-4.7 (85.7% GPQA Diamond)
Reality Check: Proprietary models lead by 4–5%

General Reasoning:

Most Versatile: DeepSeek V3.2 (strong across all domains)
Tool-Augmented: Kimi K2.5 (50.2% HLE with tools)

- -

Agentic Workflows & Tool Use

The Benchmark: τ²-Bench (Agent Coordination)

This benchmark tests how well AI models guide users through complex troubleshooting while coordinating tool usage in dual-control environments (both agent and user have tools).
Most AI models that dominate coding collapse here. This tests real-world agentic capability.

GLM-4.7 (Open-Source) - Agentic Workflows Leader

Score: 87.4% on τ²-Bench

Why It Wins:

Highest verified open-source score on τ²-Bench
Beats many proprietary models on agent coordination
Designed specifically for agentic, tool-heavy workflows
Runs on consumer hardware (16–18GB VRAM)

Verified Agent Benchmarks:

GLM-4.7 Agent Performance:
- τ²-Bench: 87.4% ← OPEN-SOURCE LEADER
- BrowseComp: 67.0 (web task evaluation)
- Terminal-Bench 2.0: 41.0%
- LiveCodeBench: 84.9%

Why This Matters for AI Agents:

Agentic workflows are where AI coding assistants (Claude Code, Cursor, Cline, Continue) operate. Strong tool use means the model can:

Call APIs correctly
Use search when needed
Navigate file systems
Execute terminal commands
Coordinate multi-step tasks

Technical Specs (GLM-4.7-Flash):

30B total, 3B active parameters
128K context window
Native tool calling support
MIT License
Hardware: 16–18GB VRAM (RTX 4090)
Speed: 25–35 tokens/second

When to Use:

Building AI coding assistants
Customer service automation
DevOps automation
Multi-tool workflows
Any task requiring extended agent coordination

- -

Category Winners: Quick Reference Table

How to Choose the Right Open-Source LLM: Decision Tree

START: What's Your Primary Use Case?

If CODING:

Have multiple H100 GPUs or API budget? → DeepSeek V3.2 (73.1% SWE-bench, MIT license, $0.27/M tokens API)

Want highest open-source performance? → Kimi K2.5 (76.8% SWE-bench, visual coding capabilities)

Have single RTX 4090 (24GB)? → Qwen3-Coder-Next (70.6%, runs locally, Apache 2.0)

Building AI coding agents (Cursor, Cline)? → GLM-4.7 (87.4% agent benchmark, 16GB VRAM, MIT)

If MATH/REASONING:

Need highest accuracy? → GLM-4.7 (95.7% AIME, MIT license)
Want versatility + math? → DeepSeek V3.2 (93.1% AIME, strong general reasoning, MIT)
Need multilingual support? → Qwen2.5-Max (92.3% AIME, 119 languages, Apache 2.0)

If AGENTIC/TOOLS:

For AI agents and automation: → GLM-4.7 (87.4% τ²-Bench, 16GB VRAM, MIT)

- -

License Verification: Are These Really Open-Source?

Fully Open-Source (Commercial Use Allowed):

DeepSeek V3.2: MIT License - No restrictions
GLM-4.7: MIT License - No restrictions
Qwen3-Coder-Next: Apache 2.0 - Attribution required

Open-Source with Commercial Restrictions:

Kimi K2.5: MIT License - Companies with 100M+ monthly active users require special licensing

Important Notes:

All licenses verified from official GitHub/Hugging Face repositories
MIT is most permissive (no attribution needed)
Apache 2.0 requires attribution but allows modification
Kimi K2.5 is effectively fully open-source for the vast majority of users and companies

- -

Final Recommendations: Best Open-Source LLM for You

For Most Developers (February 2026):

Option 1: Kimi K2.5 (Highest Coding Performance)

Highest open-source coding score (76.8% SWE-bench)
Exceptional visual-to-code capabilities
Agent Swarm for complex workflows
MIT license (with 100M MAU restriction)
Best choice for cutting-edge coding performance

Option 2: GLM-4.7 (Best All-Rounder for Consumer Hardware)

Strong coding (73.8% SWE-bench)
Best math reasoning (95.7% AIME)
Best agentic workflows (87.4% τ²-Bench)
Runs on single RTX 4090 (24GB VRAM)
MIT license
Best choice if you have consumer GPU

Option 3: DeepSeek V3.2 (Most Well-Rounded)

Excellent coding (73.1%)
Strong math (93.1%)
Best general reasoning
MIT license, API available
Best choice for versatility across tasks

Option 4: Qwen3-Coder-Next (Efficiency Champion)

Great efficiency (70.6% with only 3B active)
Runs on single RTX 4090
Apache 2.0 license
Best choice if hardware-limited

The Strategic Approach:

Many professional developers use a hybrid strategy:

Open-source models for development, testing, and most tasks
Proprietary models (Claude/GPT) for critical production features

This gives you the best of both worlds: freedom and control with open-source, reliability where it matters most.

- -

About This Analysis: All benchmark data from Artificial Analysis Intelligence Index (AIME 2025), SWE-bench.com official leaderboards, τ²-Bench documentation, and verified model release announcements from DeepSeek, Zhipu AI, and Alibaba Cloud. Hardware requirements from official specifications and community testing. All licenses verified from GitHub/Hugging Face. Information current as of February 14, 2026.
- -

Automating LeetCode to GitHub: I Built a Chrome Extension So You Never Lose Your Solutions Again

Likhit Kumar V P — Tue, 10 Feb 2026 13:00:00 +0000

Have you ever solved a LeetCode problem, felt proud of your solution, and then... forgot to save it to GitHub? Or maybe you have dozens of solutions scattered across different files with no organization?

I got tired of manually copying my LeetCode solutions to GitHub after every "Accepted" verdict. So I built a Chrome extension that does it automatically. It's made my coding practice way more organized and saved me hours of tedious work.

The Problem

As developers grinding LeetCode, we face a few annoying challenges:

Manual work is tedious: Copy code → Open GitHub → Create file → Paste → Commit → Push. Every. Single. Time.
No organization: Files named randomly, no structure, difficult to find solutions later
Multiple approaches: Solved the same problem differently? No easy way to compare solutions.

I wanted something that would just... work. Hit "Submit", get "Accepted", and solution automatically in GitHub with proper formatting and metadata.

The Solution: LeetCode GitHub Sync Extension

I built a Manifest V3 Chrome extension that:

Detects when you get "Accepted" on LeetCode
Extracts your solution code automatically
Pushes it to your GitHub repository
Organizes files by difficulty (Easy/Medium/Hard)
Supports multiple solutions for the same problem (Solution A, B, C...)
Includes rich metadata (problem URL, difficulty, timestamps)

And the best part? It has a floating ⚡ button as a reliable backup when auto-detection doesn't work.

Architecture & Tech Stack

Tech Stack

Manifest V3 (Chrome's latest extension standard)
GitHub REST API (for file creation/updates)
Monaco Editor interaction (for code extraction)
Chrome Storage API (for settings persistence)
Vanilla JavaScript (no frameworks needed!)

Key Components

leetcode-github-sync/
├── manifest.json       # Extension config (Manifest V3)
├── content.js         # Page interaction & detection
├── background.js      # GitHub API integration
├── popup.html/js      # Settings UI
└── debug-helper.js    # Diagnostic tool

How It Works

1. Detection System

The extension watches for when you get "Accepted" on LeetCode using multiple methods. Since LeetCode updates their UI frequently, I built in several fallback approaches:

DOM Mutation Observer - Watches for new elements being added to the page
CSS Class Selectors - Looks for success/green/accepted classes
Periodic Checking - Checks every 3 seconds as a backup
Text Content Scanning - Searches for "Accepted" text

If auto-detection fails, there's always the ⚡ floating button you can click manually.

2. Code Extraction

LeetCode uses Monaco Editor (the same one VS Code uses). Getting code out of it requires trying multiple approaches since the editor's internal structure can vary:

Try the Monaco API methods (getEditors(), getModels())
Extract from DOM elements (.view-line classes)
Use alternative Monaco model APIs
Fall back to manual sync button if all else fails

The extension tries each method in sequence until one works.

3. GitHub Integration

The background script handles all communication with GitHub's API. When you get "Accepted", the content script sends a message to the background script with your code, problem details, and language. The background script then:

Checks if the file already exists
Decides whether to create a new file or append to existing
Formats your solution with metadata
Pushes to GitHub using their REST API

4. Multiple Solutions Support

When you solve the same problem again, the extension detects existing solution markers in your file and automatically assigns the next letter (B, C, D, etc.). It can optionally ask for your approval before appending, so you stay in control.

File Structure Example

Your solutions get organized beautifully:

leetcode-solutions/
├── easy/
│   └── 9-palindrome-number.py
├── medium/
│   └── 2-add-two-numbers.cpp
└── hard/
    └── 4-median-of-two-sorted-arrays.py

Each file contains rich metadata:

# 9. Palindrome Number
# Difficulty: Easy
# URL: https://leetcode.com/problems/palindrome-number/
# Date: 2/10/2026

# ========== Solution A ==========
# Language: python3
# Date: 2/10/2026

class Solution:
    def isPalindrome(self, x: int) -> bool:
        if x < 0:
            return False
        return str(x) == str(x)[::-1]

# ========== Solution B ==========
# Language: python3
# Date: 2/11/2026

class Solution:
    def isPalindrome(self, x: int) -> bool:
        if x < 0 or (x % 10 == 0 and x != 0):
            return False
        reversed_half = 0
        while x > reversed_half:
            reversed_half = reversed_half * 10 + x % 10
            x //= 10
        return x == reversed_half or x == reversed_half // 10

Challenges & Solutions

Challenge 1: LeetCode UI Changes Frequently

Problem: Selectors break when LeetCode updates their UI

Solution: Multiple detection methods acting as fallbacks. The ⚡ floating button provides a reliable manual sync option that always works. Instead of relying on one way to detect "Accepted", the extension tries several different approaches.

Challenge 2: Code Extraction Reliability

Problem: Monaco Editor API isn't always accessible

Solution: 5 different extraction methods, tried in sequence:

monaco.editor.getEditors()
monaco.editor.getModels()
DOM extraction from .view-line elements
Alternative Monaco model APIs
Manual sync button as ultimate fallback

Challenge 3: Manifest V3 Restrictions

Problem: Content scripts can't access Chrome storage directly

Solution: The extension uses message passing between the content script (running on LeetCode pages) and the background service worker (handling GitHub operations). The content script collects data, sends it to the background script, and the background script handles all the API calls.

Challenge 4: Handling Special Characters

Problem: Unicode characters in code weren't uploading correctly to GitHub

Solution: Proper Base64 encoding with UTF-8 support ensures that code with special characters, emojis, or non-ASCII text gets uploaded correctly.

What I Learned

Technical Insights

Manifest V3 is strict but better - Service workers are more efficient than background pages
Multiple fallback strategies are essential - When dealing with dynamic UIs like LeetCode
User-controlled actions > Pure automation - The ⚡ button gets used more than I expected
GitHub API is straightforward - The REST API is well-documented and reliable
Monaco Editor is powerful - But accessing it requires understanding its internal structure

Product Insights

Manual fallback is crucial - Auto-detection fails ~20% of the time due to UI changes
Users want control - Approval dialog for multiple solutions is heavily used
Visual feedback matters - Notifications and loading states reduce user anxiety
Organization is key - Difficulty-based folders are the most popular option
Documentation is critical - Included debug-helper.js and multiple .md files for troubleshooting

Reflections

Building this extension taught me that reliability beats perfection. I initially wanted 100% automatic detection, but realized that a manual fallback (the ⚡ button) provides a better user experience than a flaky auto-detection system.

The extension has saved me countless hours of manual work and made my LeetCode practice more organized. Sharing my solutions with recruiters is now as simple as sending a GitHub link.

🔗 Resources

GitHub Repository: [[https://github.com/Likhit-Kumar/Leetcode-Github-Sync]]
Chrome Web Store: [Coming soon]

💭 Final Thoughts

If you're grinding LeetCode, this extension can save you hours of manual work and keep your solutions organized forever. The combination of automatic syncing + reliable manual fallback has made it an essential part of my coding practice.

For the LeetCode community: Feel free to fork, contribute, or suggest features!

Tags: #leetcode #github #chrome-extension #automation #productivity #javascript #webdev #coding

Questions or issues? Drop a comment below!

I Spent $47 testing OpenClaw for a week: Here's What's Actually Happening

Likhit Kumar V P — Sun, 08 Feb 2026 17:13:08 +0000

I Spent $47 testing OpenClaw for a week: Here's What's Actually Happening

Three weeks ago, I'd never heard of OpenClaw. Last week, my feed was full of it. people calling it the future of work, others warning it's a security nightmare. The discourse was so polarized that I did what any developer would do: I set up a test environment and tried it myself.

I spun up an old laptop, isolated it from my main network, and spent a week actually using OpenClaw for daily tasks. I also dove into the security reports, GitHub issues, and talked to people running it in production. What I found surprised me, not because it's revolutionary or terrible, but because it's both, depending on who's sitting at the keyboard.

This isn't a hit piece. It's also not a love letter. It's what I learned after actually installing and testing this thing everyone's talking about.

What It Actually Is

Strip away the hype and OpenClaw is fundamentally this: an open-source bridge between LLMs and your computer.

It runs on your own hardware and connects language models (Claude, GPT-4, DeepSeek, etc.) to your messaging apps. You text it on WhatsApp or Slack, and it executes tasks on your computer: manages your inbox, schedules meetings, browses websites, runs terminal commands, organizes files.

Think of it like having a developer friend SSH'd into your machine who's always available via text message. Except it's an AI, it never sleeps, and it remembers every conversation you've ever had with it.

The Setup Reality

Here's where theory meets practice. The documentation says "installation is straightforward," and I can confirm - if you're comfortable with Node.js, Docker, and terminal commands, it is. For everyone else, not so much.

My setup took about 30 minutes on an Ubuntu laptop. Here's what I had to navigate:

Installing Node.js version 22+ (had to upgrade from v20)
Setting up Docker containers
Managing API keys for Claude and GPT-4
Configuring OAuth flows for WhatsApp and Telegram
Setting environment variables and editing config files
Understanding WSL2 requirements (if you're on Windows)

The documentation is actually decent, but it assumes you already know what npm install, docker-compose up, and environment variables are. There's no Zapier-style wizard. You're reading YAML files and setting permissions manually.
The marketing suggests "personal AI assistant" when the reality is "developer power tool." That distinction matters.

What I Actually Tested

Once I got it running, I spent days using OpenClaw for real tasks. Here's what worked, what didn't, and what surprised me:

Email Automation (Worked Well)

I connected it to a throwaway Gmail account with ~2,000 emails accumulated over six months. I asked it to: "Unsubscribe me from all newsletters and promotional emails, keep only transactional emails and personal correspondence."

It processed everything in about 20 minutes. Out of 847 newsletter emails, it successfully unsubscribed from 203 lists and categorized the rest. I spot-checked about 50 emails - accuracy was around 90%. It missed a few legitimate emails from a client who uses a marketing platform, but overall, impressive.

Cost: ~$8 in API calls (using Claude Sonnet 3.5)

Calendar Management

I tested having it schedule a meeting with three colleagues based on their availability. I gave it access to my test calendar and said: "Schedule a 1-hour team sync with Alex, Jordan, and Sam sometime next week, preferably mornings."

It... kind of worked. It found a slot that was free for me and sent calendar invites. But it didn't actually check the other calendars (because I didn't set up those OAuth permissions). When I granted proper access and tried again, it worked but took few minutes to propose a time.

File Organization (Surprisingly Good)

I dumped 300 random files (PDFs, screenshots, documents) into a folder and asked it to: "Organize these by category and rename them with descriptive names."

It created a folder structure (Documents/Work, Documents/Personal, Images/Screenshots, etc.) and renamed files with actually useful names. A screenshot of a GitHub issue became "github-issue-authentication-error-screenshot.png" instead of "Screenshot_2026_01_15.png".

This genuinely saved me time. I'd use this feature regularly.

Web Research (The Expensive Part)

I asked it to: "Research the top 5 project management tools for remote teams, compare pricing and features, and create a summary document."

It spent the next 30 minutes browsing websites, taking screenshots, reading documentation, and compiling information. The output was actually useful, a well-structured comparison with pricing tiers and key features.

Cost: ~$22 (!!!) because of all the browser automation and vision model calls

This is where the costs can spiral. Every screenshot it takes, every page it reads with vision models that adds up fast.

Code Review Automation (Didn't Work Well)

I tried having it review a pull request and provide feedback. It read the diff, provided some generic comments about code structure, but missed an actual bug I'd intentionally introduced. It also suggested changes that would've broken the build.

The Pattern I Noticed

After a week of testing, here's what I figured out: OpenClaw excels at structured, repetitive tasks with clear success criteria.

It's not going to "figure out your business strategy". But for the boring, automatable stuff like email cleanup, file organization, research compilation,etc.. actually works.

The failures came from tasks requiring judgment calls or deep domain knowledge. It's a tool, not a replacement for thinking.

The Cost Reality

OpenClaw itself is free. But that free software isn't actually free to run.

Over my five-day testing period, I spent approximately $47 in API costs.

The expensive stuff? Anything involving browser automation with screenshots. Every time OpenClaw takes a screenshot to "see" what's on a page, that's a vision model API call. That $22 research task? It took 30 minutes and involved visiting 15+ websites with screenshots of each.

I was using Claude Sonnet 3.5 for most tasks. If I'd used Opus for everything, those costs would've easily doubled or tripled.

Here's what I learned: The model you choose dramatically affects costs. For simple tasks (email sorting, file renaming), cheaper models work fine. For complex tasks (research, multi-step workflows), you need the expensive models - and the costs add up fast.

I also discovered that runaway processes are a real concern. I set up a scheduled task to check my inbox every hour. It ran perfectly, but by morning it had made 24 API calls I hadn't budgeted for. Not catastrophically expensive (about $6), but it showed how costs creep up if you're not monitoring.

Pro tip from experience: Set usage limits on your API keys from day one.

The Security Situation

Here's the part that made me nervous during testing. I ran OpenClaw on an isolated laptop specifically because of what I'd read about security issues. After using it for a week, I understand why people are concerned.

Let me be direct: the security concerns are real and architectural, not just implementation bugs.

What I Observed

During setup, I noticed OpenClaw requested pretty extensive permissions:

Full filesystem access
Ability to run shell commands
Access to my messaging apps
Browser control with full navigation rights
Memory persistence across sessions

This is necessary for it to work, but it also means OpenClaw has essentially root-level access to everything on that machine. If something goes wrong or if someone compromises the instance they have access to everything too.

The Problem I see

The fundamental issue isn't sloppy coding, it's architectural. OpenClaw needs system-level access to be useful. But giving an LLM that much power creates inherent risks.

LLMs can be tricked through prompt injection. If OpenClaw visits a malicious website or reads a crafted document, hidden instructions can override your actual commands. I tested this lightly (in my isolated environment) and confirmed it's possible to confuse it with carefully worded instructions embedded in content.

During my testing week, I kept OpenClaw strictly sandboxed:

Dedicated laptop with no personal data
No connection to my main network
No access to real email or calendar accounts (used throwaway accounts)
Firewall rules preventing inbound connections

The Pattern

Tasks with clear, verifiable outputs worked reliably:

"Unsubscribe from newsletters" → I can check my subscriptions
"Rename files with descriptive names" → I can see the results
"Sort emails by category" → Easy to verify

Tasks with ambiguous success criteria were hit-or-miss:

"Make this document more professional" → Subjective
"Find the best options for X" → Depends on priorities I didn't specify
"Schedule a convenient meeting" → Convenient for whom?

The biggest issue: OpenClaw sometimes reports success when it hasn't actually completed the task. That calendar scheduling failure? It told me everything worked. I only discovered the problem because I'm paranoid and double-check things.

In a production environment, that's dangerous. You can't just trust the output, you need verification mechanisms. I agree with something I saw in another review: you're not removing human effort - you're changing it from execution to babysitting.

My Honest Verdict

After a week of actual hands-on testing, here's what I think:

The concept works: That email cleanup saving me hours of manual work? That file organization actually being useful? Those are real wins. Personal AI assistants with system access aren't vaporware they exist and they can deliver value.

The security model makes me nervous: Even in my isolated test environment, I was constantly aware of how much access OpenClaw had. The architectural risks like prompt injection, malicious skills, exposed credentials aren't fixable with patches. They're inherent to giving an LLM system-level permissions.

It's genuinely useful... for specific tasks: Structured, repetitive work with clear success criteria? OpenClaw handles it well. Anything requiring judgment, deep context, or nuanced decision-making? Not ready.

Reliability needs verification: The fact that it reported successful calendar scheduling when nothing actually happened concerns me. You can't just trust the output—you need to verify every automated action.

Costs are manageable but need monitoring: My $47 in five days extrapolates to roughly $280/month if I used it daily. For automation that saves 10+ hours monthly, maybe worth it. But runaway processes and unexpected bills are real risks.

Would I Use It Going Forward?

For experimentation and learning? Absolutely. It's fascinating technology and I learned a lot.

For production automation on my main systems? No way. Not with current security and reliability.

On a dedicated, isolated machine for specific automation? Possibly. If I had a clear, repetitive task that saved significant time, I might set it up carefully: dedicated hardware, whitelist-only skills, extensive monitoring, verification for every automated task.

The gap between "this technically works" and "I trust this with my actual data" is still too wide for me.

Should You Try It?

Based on my testing experience:

Consider it if you:

Are comfortable with Docker, security configs, and troubleshooting
Have a dedicated machine you can isolate for testing
Understand and accept the security risks deliberately
Will audit any skills before installing them
Have specific, repetitive automation needs
Can monitor API costs actively

Final Thoughts

After spending a week actually using OpenClaw, I can say this: it's both more capable and problematic than the headlines suggest. Is it a breakthrough? For specific automation tasks, yes.

Is it overhyped? Absolutely. The TikTok demos and viral tweets make it look safer and easier than the reality.

Is it the future of work? Not yet. But it's showing us what that future might look like and more importantly, what problems we need to solve to get there. The conversations OpenClaw forces about security, reliability, governance, what we're comfortable delegating to AI are exactly the ones we need to have as autonomous agents become more capable.

This was a hands-on test in a controlled environment. Your experience may vary. I really appreciate you taking the time to read through all of this!"

git commit -m "Initial Commit"

Likhit Kumar V P — Mon, 02 Feb 2026 16:08:58 +0000

Okay, this is obviously my first post and I have to say this upfront: I am very, very bad at writing and posting things. I just want to skip the cringey "Welcome to my blog" dialogues and get straight to the point.

"Why am I here?"

Let’s be real: I've spent way too much time overthinking, calculating probabilities, and running mental statistics instead of just trying it out.

The things I learn usually disappear exactly when I need them, like Dr. Strange's spell at the end of No Way Home. Poof. Gone.

But today, the "Day 1" energy is hitting different.

I’m starting this blog because I realized I need a superpower. I realized that keeping my technical knowledge locked in my brain (or buried in messy untitled.txt files) isn't helping anyone.

This blog is my personal Consistency Meter. I’m pushing my limits to see if I can actually maintain a streak that isn't just my Duolingo owl threatening me.

There is a scene in Invincible where Omni-Man yells, "THINK MARK!! THINK!"

That is the core philosophy of this blog. I am trying to build a bridge between my Current Self and my Future Self (who hopefully knows better than I do today).

What can you expect?

I’m going to be posting about the technical issues I overcome and the solutions I find sometimes elegant, sometimes messy, but always working.

The Code: Snippets that actually do something useful.
The Fixes: The specific solutions I built to solve specific headaches.
The Struggle: The errors that made me question my life choices.
The Growth: Moving from "just coding" to shipping products that help people.

It’s going to be fun, and honestly? I'm really excited.

Let’s see how long I can keep the Consistency Meter running.

DEV Community: Likhit Kumar V P

I Built an MCP Server That Lets AI Autonomously Debug Salesforce - Here's How

The Problem Nobody Talks About

The Gap in the Ecosystem

Certinia's @certinia/apex-log-mcp

Salesforce's @salesforce/mcp

The Workflow Today (Even With MCP)

What I Built

The Philosophy

The Workflow Now

Architecture

Key Design Decisions

9 Tools, 4 Tiers

Tier 1: Log Acquisition

Tier 2: Content Intelligence

Tier 3: Lifecycle Management

Tier 4: Cross-Log Intelligence

The Health Score: Diagnosing Logs in One Call

Detecting Silent Failures: The 7 Parsers

1. Callout Parser - The HTTP 200 Lie Detector

2. Exception Parser - Handled vs. Unhandled

3. SOQL Parser - The Zero-Row Detector

4. Governor Limits Parser - The Time Bomb Detector

5-7. DML, Flow, and Debug Message Parsers

Smart Error Handling

Security Model

The Numbers

Try It in 2 Minutes

Prerequisites

Setup

Configure Your AI Client

Multi-Server Setup

What I Learned Building This

1. The Status Field is a Lie

2. MCP is the Right Abstraction

3. Parsers Need to Be Opinionated

4. Health Scores Drive Efficient Debugging

5. Three Dependencies is Enough

What's Next

Links

Tags

Agentforce Scripts: Hybrid Reasoning, Action Chaining, and What It Actually Looks Like in Practice

What Is Agent Script and Why Should You Care?

The Agentforce Features — Explained

1. Agentforce Builder — Canvas View

2. Agentforce Builder — Script View

3. Agent Script — Hybrid Reasoning

4. Action Chaining

5. Conditional Routing

6. Apex Invocable Actions

7. Preview Panel

8. Trace Panel

9. The Atlas Reasoning Engine

Putting It All Together: The Burnout Prevention Agent

The Data Model

The Apex Actions

The Agent Script Structure

Three Tests, Three Completely Different Outcomes

Why Not Just Use Apex and Flows?

What I Took Away from Building with Agent Script

The Bigger Picture

I Cut My Context-Switch Recovery From 23 Minutes to 5 Seconds

The most expensive thing in software isn't bugs. It's forgetting.

"But doesn't Copilot already -" No.

What it actually reads

The part that prevents hallucination

It remembers what you don't

Zero dependencies. On purpose.

Free. Actually free.

Try it in 60 seconds

I Migrated a React Native App from Redux to Zustand

TL;DR

What Zustand Actually Is (and Isn't)

How It Works Under the Hood

Setup

Pattern 1: Selectors with useShallow : The Performance Foundation (and the Crash We Almost Shipped)

Pattern 2: The Slice Architecture : One Store, Multiple Concerns

Pattern 3: The Middleware Stack : devtools + persist + immer

devtools : Non-Negotiable in Development

persist : Surviving App Restarts

Certinia's `@certinia/apex-log-mcp`

Salesforce's `@salesforce/mcp`

Pattern 1: Selectors with `useShallow` : The Performance Foundation (and the Crash We Almost Shipped)

Pattern 3: The Middleware Stack : `devtools` + `persist` + `immer`

`devtools` : Non-Negotiable in Development

`persist` : Surviving App Restarts

`immer` : Ergonomic Nested Updates

Step 6 : Update `.env` and Write the Code