DEV Community: Muhammad Hamid Raza

How to Use Claude Code with Ollama for Free (+ 5 Powerful Cloud Models You Need to Try)

Muhammad Hamid Raza — Tue, 19 May 2026 12:22:23 +0000

You love Claude Code. You hate the API bill. 😅

If you've used Claude Code even moderately, you've probably watched your Anthropic credits disappear faster than a coffee on a Monday morning. Heavy agentic sessions — reading files, editing code, running commands — can rack up $50 to $200+ a month on flagship models. That's a real cost for indie developers and learners.

Here's the good news: you don't need to pay a single dollar to use Claude Code anymore.

Thanks to Ollama's native support for the Anthropic Messages API (added in v0.14.0), you can point Claude Code at free open-source models running either locally on your machine or on Ollama's free cloud tier. Same CLI. Same workflow. Zero Anthropic tokens.

Want to know exactly how to set it all up — step by step, command by command — and which free cloud models are worth your time? Let's go. 🚀

What Is This Setup All About?

Claude Code is Anthropic's terminal-based AI coding agent. It reads your codebase, edits files across multiple locations, runs shell commands, calls tools, and handles multi-step tasks — all from your terminal, driven by natural language.

By default, it talks to Anthropic's API. But there's one small environment variable — ANTHROPIC_BASE_URL — that lets you redirect all those requests to a completely different backend.

Ollama is an open-source tool that lets you run AI models on your own machine. Since v0.14.0 (January 2026), Ollama also exposes an Anthropic-compatible Messages API on localhost:11434. That means Claude Code and Ollama now speak the same language natively — no adapters, no hacks.

The result: Claude Code's full feature set (file editing, tool calls, multi-step reasoning, git integration) running against powerful open-source models at zero cost.

Why This Matters

For most developers, Claude Code was exciting in theory but expensive in practice. A typical heavy session — analyzing a codebase, refactoring multiple files, generating tests — could burn through dollars fast.

This setup changes the math completely:

Local models: completely free, private, works offline, no data leaves your machine
Ollama cloud models (free tier): runs on Ollama's servers, no GPU required, free daily usage with session limits
Same CLI experience: you still type claude in your terminal. Nothing feels different

For learning, building demos, exploring Claude Code's features, and handling everyday coding tasks, these free alternatives are more than capable.

Part 1: Installing Ollama

macOS / Linux

Open your terminal and run:

curl -fsSL https://ollama.com/install.sh | sh

Windows

Download the installer directly from ollama.com/download and run it. Ollama installs as a background service automatically.

Verify Installation

ollama --version

You should see version 0.14.0 or later (0.6.x is current as of mid-2026). This version is required for Anthropic API compatibility.

Start Ollama Server (if not auto-started)

ollama serve

This starts the local Ollama daemon on http://localhost:11434. On macOS, it usually starts automatically as a menu bar app.

Part 2: Essential Ollama Commands

These are the commands you'll use regularly. Learn them once and you'll never forget them.

Pull (Download) a Model

ollama pull <model-name>

Example:

ollama pull qwen3-coder:480b-cloud

For cloud models (with the :cloud suffix), this registers the model reference — no actual weights are downloaded to your disk. Inference runs on Ollama's servers.

Run a Model Interactively

ollama run <model-name>

Example:

ollama run nemotron-3-super:cloud

This opens an interactive chat session in your terminal. Type your message and press Enter.

List All Downloaded / Registered Models

ollama ls

Remove a Model

ollama rm <model-name>

Check Running Models

ollama ps

Show Model Info

ollama show <model-name>

Stop a Running Model

ollama stop <model-name>

Connect Your Ollama Account (Required for Cloud Models)

ollama auth login

This opens a browser tab to ollama.com/connect. Sign in and your credentials are stored locally. All cloud model requests use this automatically.

Launch Claude Code Directly from Ollama

ollama launch claude

This is the magic command. ⚡ It starts Claude Code with Ollama as the backend, auto-sets all required environment variables, and prompts you to pick a model interactively.

You can also specify the model directly:

ollama launch claude --model nemotron-3-super:cloud

Part 3: Installing Claude Code

Claude Code requires Node.js 18+. Check your version first:

node --version

If you don't have Node.js, download it from nodejs.org.

Install Claude Code via npm

npm install -g @anthropic-ai/claude-code

Verify Installation

claude --version

Update Claude Code

npm update -g @anthropic-ai/claude-code

Part 4: Connecting Claude Code to Ollama

This is the three-step configuration. You set three environment variables to redirect Claude Code away from Anthropic's servers and toward your local Ollama instance.

Option A: Set Variables for the Current Session (Quick Test)

macOS / Linux:

export ANTHROPIC_AUTH_TOKEN="ollama"
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL="http://localhost:11434"

Windows (PowerShell):

$env:ANTHROPIC_AUTH_TOKEN = "ollama"
$env:ANTHROPIC_API_KEY = ""
$env:ANTHROPIC_BASE_URL = "http://localhost:11434"

Option B: Permanent Setup (Recommended)

Add these lines to your ~/.bashrc, ~/.zshrc, or ~/.bash_profile:

export ANTHROPIC_AUTH_TOKEN="ollama"
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL="http://localhost:11434"

Then reload:

source ~/.zshrc
# or
source ~/.bashrc

Verify the Variables Are Set

printenv | grep ANTHROPIC

You should see all three variables.

Part 5: Running Claude Code with Ollama Models

Once your environment variables are set, start Claude Code like this:

Method 1: Using the `claude` Command Directly

claude --model nemotron-3-super:cloud --allow-dangerously-skip-permissions

Replace the model name with any Ollama-supported model. The --allow-dangerously-skip-permissions flag skips the interactive trust prompt (useful for faster startup during development).

Method 2: Using `ollama launch claude` (The Clean Way)

ollama launch claude

This method is recommended for most users. It:

Auto-sets all environment variables
Lets you pick the model from a list
Handles all Anthropic API routing automatically

With a specific model:

ollama launch claude --model gpt-oss:120b-cloud

With auto-confirm and auto-pull:

ollama launch claude --model qwen3-coder:480b-cloud --yes

The --yes flag automatically pulls the model (if not already registered) and skips all confirmation prompts.

Method 3: Test Your Project Setup

# Create a test project
mkdir my-test-project
cd my-test-project
git init
echo "# My Project" > README.md
git add README.md
git commit -m "initial commit"

# Start Claude Code with Ollama
ollama launch claude --model gemma4:31b-cloud

You'll see the familiar Claude Code interface — but it's now powered by a free open-source model. 🎉

The 5 Free Ollama Cloud Models You Should Know

These are all available on Ollama's platform. Cloud models run on Ollama's servers, and all users get a free tier with daily/session usage limits. No GPU required on your machine.

✅ Verification note: All five models below are confirmed available on Ollama's official model library (ollama.com/library) as :cloud variants. Ollama's free tier provides limited daily cloud usage — heavier models (higher usage levels) consume your quota faster. For unlimited access, a Pro plan ($20/month) is available, but the free tier is genuinely useful for learning and everyday development.

1. `nemotron-3-super:cloud`

NVIDIA's Nemotron 3 Super is a 120B Mixture-of-Experts model that activates only 12B parameters at a time — so you get strong reasoning quality with surprisingly efficient compute. It supports English, French, German, Italian, Japanese, Spanish, and Chinese, making it great for multilingual work and complex multi-agent tasks.

ollama run nemotron-3-super:cloud

2. `gpt-oss:120b-cloud`

OpenAI's open-weight model designed for reasoning, agentic tasks, and developer use cases. The 120B variant has strong tool-use support and thinking capabilities — making it a natural fit for Claude Code's multi-step file editing and shell command workflows.

ollama run gpt-oss:120b-cloud

3. `gemma4:31b-cloud`

Google's Gemma 4 in the 31B size brings vision capabilities alongside solid general reasoning. It's a good all-rounder for chat, code review, and general development tasks. If you want a model that handles both text and images, this is your pick.

ollama run gemma4:31b-cloud

4. `qwen3-vl:235b-cloud`

Alibaba's most powerful vision-language model to date. With 235B parameters, it handles complex vision tasks alongside text, including image understanding, document parsing, and code from screenshots. If you're working on projects involving both visuals and code, this is a compelling option.

ollama run qwen3-vl:235b-cloud

5. `qwen3-coder:480b-cloud`

This is the one developers talk about most. Qwen3-Coder at 480B is specifically optimized for long-context coding and agentic tasks — exactly the kind of work Claude Code does. It supports a 128K context window and is built for multi-file edits and code generation workflows. Heavy model (higher usage level), so pace yourself on the free tier.

ollama run qwen3-coder:480b-cloud

Model Comparison Table

Here's a clear side-by-side comparison of all five models to help you pick the right one for your task:

Model	Parameters	Context Window	Vision	Tool Use	Thinking	Best For	Usage Level
`nemotron-3-super:cloud`	120B MoE (12B active)	128K	❌	✅	❌	Reasoning, multi-agent, multilingual	Level 2
`gpt-oss:120b-cloud`	120B	128K	❌	✅	✅	Agentic tasks, coding, reasoning	Level 2
`gemma4:31b-cloud`	31B	128K	✅	✅	❌	General chat, multimodal, code review	Level 2
`qwen3-vl:235b-cloud`	235B	128K	✅	✅	❌	Vision + code, document parsing	Level 3
`qwen3-coder:480b-cloud`	480B	128K	❌	✅	❌	Code generation, agentic coding	Level 3–4

💡 Quick tip: On the free tier, start with nemotron-3-super:cloud or gemma4:31b-cloud (Level 2) to stretch your free usage further. Use qwen3-coder:480b-cloud when you need serious coding power and have quota available.

Claude Code Commands You Should Know

Once inside a Claude Code session, here are the most useful commands:

Command	What it does
`/help`	Shows all available commands
`/exit`	Exits Claude Code
`/clear`	Clears the conversation history
`/compact`	Compresses conversation to save context
`/model`	Shows the current model in use
`Ctrl+C`	Cancel the current response
`Tab`	Switch between planning and build mode
`Ctrl+P`	Opens options panel

Best Tips for This Setup ✅

Do these:

Always verify your environment variables are set before starting Claude Code — run printenv | grep ANTHROPIC to confirm
Start with ollama launch claude instead of the manual claude command. It's simpler and handles everything automatically
Use qwen3-coder:480b-cloud for serious coding sessions when you have quota. It's optimized for exactly this kind of work
Create a test project first before running Claude Code on real code, so you can verify everything works
Sign into your Ollama account before using any :cloud model — run ollama auth login once and you're done

Avoid these:

Don't skip the ollama auth login step for cloud models — they won't run without it
Don't set ANTHROPIC_API_KEY to a real Anthropic key when using Ollama — leave it empty or set to a dummy value
Don't expect local inference speed to match cloud — on a 16GB RAM machine, local models can be slow. Cloud models are faster for heavy tasks
Don't use cloud models on the free tier for large batch jobs — you'll hit session limits fast. Stick to focused coding sessions

Common Mistakes People Make

1. Forgetting to start the Ollama server

If you see a connection error when Claude Code starts, Ollama's daemon probably isn't running. Fix it:

ollama serve

2. Missing the `ollama auth login` step for cloud models

Cloud models (*:cloud) require you to be signed into your Ollama account. Without this, requests fail. Run ollama auth login once and your credentials are saved automatically.

3. Setting the wrong `ANTHROPIC_BASE_URL`

Some older guides suggest http://localhost:11434/v1. The correct URL for Ollama's Anthropic-compatible endpoint is:

http://localhost:11434

Without the /v1 suffix, unless you're specifically testing the OpenAI-compatible endpoint.

4. Expecting identical Claude behavior

Open-source models follow Claude Code's expected output format well for most tasks, but complex multi-step reasoning chains may behave differently than Anthropic's flagship models. For simple to mid-complexity tasks, they perform great. For highly complex architectural decisions, results may vary.

5. Running out of free cloud quota on heavy models

The Ollama free tier has session and weekly limits. Models like qwen3-coder:480b-cloud are large (Level 3–4 usage), so they consume your quota faster. Be intentional with your requests on the free tier, and use gemma4:31b-cloud for lighter tasks to preserve quota.

Putting It All Together: Full Setup Walkthrough

Here's the complete setup from scratch in one place:

# Step 1: Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Step 2: Verify Ollama version (needs 0.14+)
ollama --version

# Step 3: Sign in for cloud model access
ollama auth login

# Step 4: Install Claude Code
npm install -g @anthropic-ai/claude-code

# Step 5: Set environment variables (add to ~/.zshrc for permanent setup)
export ANTHROPIC_AUTH_TOKEN="ollama"
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL="http://localhost:11434"

# Step 6: Launch Claude Code with Ollama (the easy way)
ollama launch claude

# OR with a specific model
ollama launch claude --model nemotron-3-super:cloud

# OR the manual way
claude --model qwen3-coder:480b-cloud --allow-dangerously-skip-permissions

That's it. You're now running Claude Code on free, powerful open-source models. 🎉

Conclusion

The combination of Claude Code and Ollama is genuinely exciting. What used to be an expensive tool reserved for developers with budget for API credits is now accessible to everyone — students, indie developers, learners, and anyone curious about agentic AI coding.

The five cloud models covered here — nemotron-3-super:cloud, gpt-oss:120b-cloud, gemma4:31b-cloud, qwen3-vl:235b-cloud, and qwen3-coder:480b-cloud — are all available on Ollama's free tier and cover a strong range of use cases from coding to vision to multilingual reasoning.

The ollama launch claude command is genuinely the simplest way to start. One command, pick your model, and you're in. No manual environment variable juggling required.

Start free. Learn the workflow. When your usage outgrows the free tier, Ollama's Pro plan at $20/month is still a fraction of what Anthropic's API costs for heavy use.

Happy coding — and may your context windows always be long enough. 🚀

For more dev guides like this, visit hamidrazadev.com — if this post saved you money or time, share it with a developer friend who could use it too. 🙌

VS Code 1.120 Is Here: Agents Window, BYOK Token Tracking, and More

Muhammad Hamid Raza — Sat, 16 May 2026 06:26:16 +0000

You open VS Code, start a task with an AI agent, then realize you need to jump to a completely different project — and suddenly your whole workflow falls apart. Sound familiar? 😅

VS Code 1.120, released on May 13, 2026, tackles exactly that kind of friction head-on. This release is packed with genuinely useful upgrades — not just checkbox features, but things that will actually change how you work day to day.

From a dedicated Agents window built for multi-project agentic workflows, to accurate token tracking for your BYOK models, to smarter Markdown tooling and terminal command risk badges — there's a lot to unpack. So let's get into it.

What Is VS Code 1.120?

VS Code 1.120 is the latest stable release of Visual Studio Code — Microsoft's free, open-source code editor used by millions of developers worldwide.

Every month or so, the VS Code team ships a new version with new features, fixes, and improvements. Version 1.120 is a particularly noteworthy release because it graduates the Agents window from Insiders-only to Stable — which means it's now available to everyone.

Think of this release as VS Code leveling up its AI game, sharpening its Markdown tools, and adding a few safety nets you didn't know you needed.

Why This Release Matters

Here's the honest reality: agentic coding is not a future thing anymore. Developers are actively using AI agents to write code, run commands, make changes across files, and even manage projects. But VS Code was originally designed around one editor, one workspace, one task at a time.

VS Code 1.120 starts to fix that. It introduces a purpose-built environment for working with multiple agents across multiple projects simultaneously. At the same time, it addresses real pain points around cost visibility, terminal safety, and Markdown review quality. These aren't flashy gimmicks — they solve problems developers are running into right now.

Key Features in VS Code 1.120

🪟 Agents Window — Now in Stable

The biggest headline of this release is the Agents window moving from VS Code Insiders to Stable. This is a whole new type of window designed specifically for agent-driven development.

Instead of forcing your agent workflows into the same editor layout built for writing code manually, the Agents window gives you a dedicated space to:

Explore and iterate on tasks across multiple projects
Switch between active agent sessions without losing context
Review agent-generated changes in one place
Choose your agent harness and run agents on remote machines

It shares all your existing VS Code settings (themes, keybindings, extensions) but lets you override specific settings just for the Agents window.

What's improved since Insiders?

Your dropdown preferences (agent harness, isolation mode) now persist between sessions — no more re-selecting every time.
You can discard edits directly from the Changes panel without hunting for a menu.
A sync button on the Files panel lets you pull upstream changes from the base branch before the agent begins.
Completed sessions now automatically show the agent's full set of changes when you open them.
Arrow buttons in the top-left title bar let you jump between recent sessions quickly.

You can open it from the "Open in Agents" button in the VS Code title bar. The Agents window documentation has everything you need to get started.

💰 BYOK Token Usage — Finally Accurate

If you use Bring Your Own Key (BYOK) with providers like Anthropic, OpenAI, or others, you've probably noticed that the context window control in Chat always showed 0% and zero tokens. That was a bug — token accounting simply wasn't working for BYOK models.

VS Code 1.120 fixes that. The context window control now shows accurate token usage and percentage for all BYOK models. No more guessing whether you're burning through your context window.

This matters for two reasons: performance and cost. When your model runs out of context window space, it starts forgetting earlier parts of your conversation. And if you're paying per token, keeping an eye on usage is just good hygiene.

🧠 Thinking Effort for BYOK Reasoning Models

Reasoning models — the kind that "think before they answer" — let you control how hard they work on a problem. More thinking effort means better answers but higher cost and slower responses. Less effort is faster and cheaper but may produce shallower results.

VS Code 1.120 lets you configure thinking effort for BYOK reasoning models directly from the model picker in the Chat view. This works across OpenAI-compatible endpoints including OpenAI, xAI (Grok), OpenRouter, and custom Azure OpenAI deployments. (Anthropic models already had this; the control is now consistent everywhere.)

📦 Model Picker Organized by Provider

If you work with models from multiple providers, the old model picker could feel like one giant unsorted list. Now, models are grouped by provider, making it much easier to find what you need. You can also search by model name.

Bonus: recently used models now show the provider name in grey text next to the model name, so you can instantly tell apart similarly named models from different services.

💡 Quick tip: Type /models in the chat input to jump straight to the model list.

⚡ Terminal Output Compression (Preview)

Here's a real scenario: you run npm install or git diff inside an agent session, and the output is hundreds of lines long. That output gets sent to the model and eats a huge chunk of your context window — leaving less space for your actual code and the agent's reasoning.

Enable chat.tools.compressOutput.enabled and VS Code will post-process terminal output before sending it to the model:

Large unchanged hunks in diffs are collapsed
Lockfile and snapshot diffs are dropped entirely
ls -l output is reduced to just entry names
npm install progress bars and deprecation warnings are stripped

A short banner is added to any compressed output so the model knows what was filtered — and can request the raw version if it needs it.

🚦 Risk Assessment for Terminal Commands (Experimental)

This one is genuinely useful if you let agents run terminal commands. Enable chat.tools.riskAssessment.enabled and every terminal command confirmation now shows a colored risk badge with an AI-generated one-sentence explanation.

Three levels:

Safe (green): reads files or prints output without making changes
Caution (orange): modifies the workspace, installs packages, or sends data over the network
Review carefully (red): may be difficult or impossible to undo — think force-pushing to a remote or deleting files outside the workspace

It's a small thing, but it gives you a moment to breathe before saying yes to something destructive.

📝 Markdown Preview for Diffs (Preview)

If you've ever opened a Markdown file in Source Control's diff view and had to mentally parse raw syntax to understand what changed — this feature is for you.

VS Code 1.120 lets you view Markdown diffs as rendered previews instead of raw source. You can see both side-by-side and inline views. Spotting a changed heading or a restructured list is now as easy as reading the document — no mental decoding required.

To try it, open a Markdown diff and use Reopen Editor With... to switch to the Markdown preview diff view.

You can also make it the default:

"workbench.diffEditorAssociations": {
  "*.md": "vscode.markdown.preview.editor"
}

This is especially handy when reviewing documentation changes from agents or pull requests.

🔗 HTML `id` Support in Markdown

VS Code now recognizes id attributes from HTML elements inside Markdown files for both path completions and link validation.

So if you write:

<div id="install-guide">...</div>

And then link to it:

See the [installation steps](#install-guide) for details.

VS Code will suggest #install-guide in completions and flag it as an error if the id doesn't exist. No more broken anchor links that look fine until someone clicks them.

📊 Smart Select for Markdown Tables

A small but welcome addition: Markdown tables now support smart selection. Use Shift+Alt+RightArrow to expand the selection from a cell → row → full table. Use Shift+Alt+LeftArrow to shrink it back. If you edit tables regularly, you'll appreciate this.

🗂️ Plan Mode Improvements for Claude and Copilot CLI

If you use plan mode with the Claude agent or Copilot CLI, the plan editor got better:

Inline editing: You can now edit the plan directly inside the control instead of opening a separate editor tab.
Clearer feedback mode: When you're giving feedback on a plan, the UI now clearly shows you're in feedback mode and displays your added feedback.
You can opt out of the inline editor and fall back to a regular editor tab if you prefer with chat.planWidget.inlineEditor.enabled.

Comparison: Before and After 1.120

Feature	Before 1.120	After 1.120
BYOK token display	Always showed 0%	Accurate usage and %
Thinking effort for BYOK	Anthropic only	All OpenAI-compatible providers
Model picker	One unsorted list	Grouped by provider, searchable
Markdown diff view	Raw syntax only	Rendered preview available
Terminal command confirmation	Just the command	Command + risk badge + explanation
Agents window	Insiders only	Available in Stable

Best Tips for Getting the Most Out of 1.120

✅ Try the Agents window for your next multi-project task. Even if you're not doing heavy agentic work, it's worth exploring. The session history and change review features alone are useful.

✅ Enable terminal output compression if you run long commands in agent sessions. It directly preserves your context window and can save you from unexpected token overages.

✅ Turn on risk assessment for terminal commands. It takes two seconds to enable and could save you from a painful git push --force accident.

✅ Set the Markdown preview as your default diff view for .md files. If you review docs regularly, this change alone is worth the update.

✅ Use /models in the chat input to quickly switch between models without clicking through menus.

Common Mistakes to Avoid

❌ Ignoring the risk badge on terminal commands. The experimental risk assessment feature is there for a reason. A red badge means stop and read before hitting confirm.

❌ Skipping terminal output compression. If you're paying for tokens with BYOK, or working on complex agent sessions, not compressing output is quietly expensive. It's opt-in, so you have to actually turn it on.

❌ Not setting the Agents window preferences early. Your harness and isolation mode choices are now saved between sessions — but only after you set them the first time. Take a minute to configure things the way you want.

❌ Assuming BYOK token tracking was always accurate. If you were making decisions based on that 0% display, now's a good time to re-evaluate your context window habits.

Wrapping Up

VS Code 1.120 is one of those releases that makes daily developer work noticeably smoother. The Agents window landing in Stable is the headline, but the token tracking fix, risk badges, Markdown preview for diffs, and terminal compression are the features you'll actually feel every day.

It's not a revolutionary release — it's a thoughtful, practical one. And those are often the best kind. 🚀

If you found this useful, check out more developer content on hamidrazadev.com — there's a lot more where this came from. And if this post saved you some time, share it with a teammate who's still on VS Code 1.119. They'll thank you later. 😊

I Wrote 101 Developer Blogs. Here's What I Learned — And What I Was Really Trying to Teach You

Muhammad Hamid Raza — Mon, 11 May 2026 07:48:28 +0000

You open a blank page. The cursor blinks. You have no idea where to start.

That was me on my very first blog post. I was nervous. I thought, "Who is going to read this? I'm not an expert. I'm just a student."

But I hit publish anyway.

Then I did it again. And again. And again.

101 times later, here I am — looking back at what writing all those posts actually taught me, not just about code, but about people, learning, and what it really means to share knowledge online. 🚀

So if you've been following along, thank you. This one's for you.

The Journey: From 1 Blog to 101

My first post was short. The formatting was rough. The writing was stiff.

But it was honest. And it was mine.

Over time, I started covering topics I genuinely cared about — VS Code updates, CSS history, DNS, React patterns, AI tools, Next.js SEO, and a lot more. I wasn't picking topics to go viral. I was writing about things I was learning, experimenting with, or genuinely curious about.

That turned out to be the best strategy I never planned.

What I Learned From Writing 101 Blogs

1. Consistency Beats Perfection Every Single Time

My early posts weren't perfect. Some of them still aren't. But I kept going.

The moment I stopped waiting to be "ready enough" to write, the writing got better on its own. Showing up regularly — even when the draft feels messy — teaches you more than any writing course ever could.

Lesson: Publish imperfect work. Improve over time. Don't wait.

2. Simple Writing Is Harder Than Technical Writing

Anyone can write a complicated explanation. Writing something a beginner can actually understand? That takes real skill.

I spent more time simplifying my explanations than I spent researching the topic. And every time I found a simpler way to say something, I actually understood the topic better myself.

Lesson: If you can't explain it simply, you don't fully understand it yet. Writing forces that clarity.

3. Developers Are Hungry for Relatable Content

The posts that got the most attention weren't always the most technical.

They were the ones that started with a real situation — a frustrating bug, a confusing concept, a "wait, how does this actually work?" moment. Readers don't just want information. They want to feel like the writer gets them.

Lesson: Start with the human moment. The technical detail comes after.

4. Writing About Something Teaches You More Than Reading About It

Every time I wrote about a topic — whether it was DNS, CSS Flexbox, MCP, or pagination — I understood it at a deeper level than before.

Writing forces you to fill the gaps. You can't fake your way through an explanation. If you don't understand something, it shows. So you go back, research harder, test things, and come back with clarity.

Lesson: Want to truly learn something? Write about it.

5. Your Audience Is More Diverse Than You Think

I assumed my readers were mostly experienced developers.

I was wrong.

Students, career-switchers, beginners, self-taught developers from countries all over the world — they all showed up. That changed how I write. I stopped assuming prior knowledge. I started explaining from the ground up, without being condescending.

Lesson: Write for the beginner in the room. Advanced readers can skim. Beginners can't.

6. The Title Is Half the Battle

I spent maybe 10 minutes on the title of my first blog. I now spend more time on the title than any other single line.

A great title answers: "Why should I click this?" The answer has to be fast, clear, and honest. Clickbait burns trust. Good titles build it.

Lesson: Spend real time on your title. It's a promise to your reader — keep it.

7. Burnout Is Real, and Breaks Are Necessary

Around post 60-something, I hit a wall. Writing felt like a chore. Topics felt recycled. Everything felt dry.

I took a short break. Came back. The energy returned.

Sustainable content creation isn't about writing every single day without rest. It's about protecting your curiosity so it stays alive long enough to keep going.

Lesson: Rest is part of the process. Protect your enthusiasm like it's a resource — because it is.

What I Was Actually Trying to Teach You

Every blog I wrote had the same hidden goal underneath all the headings and code snippets:

Make developers feel less stuck and more capable.

That's it. That's the whole mission.

Whether I was explaining how DNS works or why pnpm is faster, I was always asking myself: Will the person reading this feel smarter and more confident after finishing?

Here's what I hoped you took away from the different posts:

From the CSS and frontend posts → That styling doesn't have to be a fight. When you understand the model, it clicks.
From the VS Code update posts → That tools evolve fast, and staying updated doesn't have to be overwhelming if someone breaks it down for you.
From the AI posts → That AI is a tool, not a threat. Understanding it makes you more useful, not replaceable.
From the networking and DNS posts → That the internet makes a lot more sense when someone traces through it with you step by step.
From the personal posts → That every developer — no matter where they are — deals with doubt, confusion, and imposter syndrome. You're not alone.

What I'm Still Learning

I'll be honest: I don't have everything figured out.

I'm still learning how to make my code explanations clearer. I'm still figuring out the right balance between beginner-friendly and technically rigorous. I'm still working on writing introductions that grab attention in the first two sentences.

But that's kind of the point.

101 blogs in, and I'm still learning. That should tell you something — writing is never really "done." It just gets better if you keep going.

Why You Should Start Writing Too

If you've been thinking about starting a blog, here's my honest pitch:

You don't need to be an expert. You need to be one step ahead of someone who's stuck.

That gap — between where you are and where a beginner is — is your entire value as a writer. Use it.

Write about what confused you last week. Explain the thing that took you three hours to figure out in five minutes. That's the blog post someone needs right now.

Conclusion

101 posts. Hundreds of topics. Thousands of words.

But if I had to distill everything into one sentence, it would be this:

The best thing I ever did for my learning was starting to write in public.

It made me a clearer thinker, a better communicator, and a more empathetic developer.

Thank you for reading. Thank you for the reactions, the follows, and the quiet encouragement of just showing up.

Here's to the next 101. 💡

If you want to read more posts like this, head over to hamidrazadev.com — everything is there. If this post helped you or made you smile, share it. And if you're thinking about starting your own blog, drop a comment. I'd genuinely love to hear from you.

Top 5 Chrome Extensions Every Developer Should Be Using Right Now 🚀

Muhammad Hamid Raza — Sun, 10 May 2026 07:28:51 +0000

You open Chrome, start debugging a bug, inspect a layout, check an API response, and test a color — all within the first ten minutes of your day. Sound familiar?

Developers live inside their browser. It is basically a second IDE at this point. But most people are still using Chrome without any extensions, which is like coding without autocomplete. You can do it, but why would you?

The right Chrome extensions can save you real time, reduce the mental load, and make your workflow noticeably smoother. So here are the top 5 Chrome extensions every developer should know — tried, practical, and genuinely useful.

What Are Chrome Extensions (and Why Should Developers Care)?

Chrome extensions are small programs that plug into your browser and add features that are not there by default. They can change how pages look, add new tools, or help you inspect and analyze things on any website.

For developers specifically, a good extension can help you:

Debug faster
Understand how websites are built
Test your own UI without switching tools
Manage your colors, fonts, and assets on the fly

Think of them as power-ups for your browser. And the best part? Most of them are free.

Why This Actually Matters

Here is the honest truth: most developers underestimate how much time they waste switching between tools, searching for hex codes, copying API responses into Notepad, or squinting at font sizes in DevTools.

The right extensions eliminate these micro-frustrations. And when you add up all those small savings across a full day of work, it is a meaningful difference. That is not an exaggeration — it is just good tooling.

The Top 5 Chrome Extensions for Developers

1. 🔧 React Developer Tools

Best for: React developers who want real insight into their components.

If you build React applications, this one is non-negotiable. React Developer Tools adds a dedicated Components and Profiler tab to Chrome DevTools. From there, you can inspect your entire component tree, see live props and state, and track what is re-rendering and why.

Real-life example: You notice your page is lagging after a state update. Instead of adding console.log everywhere, you open the Profiler, run a trace, and see exactly which component is re-rendering unnecessarily. Three minutes later, you have fixed it.

Without this extension, debugging React apps is a lot of guesswork. With it, everything becomes visible.

Install: React Developer Tools — available on the Chrome Web Store.

2. 👀 WhatFont

Best for: Developers and designers who want to identify fonts instantly.

You are browsing a website and the typography looks really clean. You want to know what font it is using. Normally you would open DevTools, find the element, inspect the font-family property, and dig through the CSS. That takes a while.

With WhatFont, you just hover over any text on the page and it instantly tells you the font name, size, weight, color, and even the source it is loaded from.

Real-life example: You are building a landing page and the client sends you a competitor's site as a reference. You hover over the heading and immediately see: "Inter, 48px, 700 weight." Done. No digging needed.

It is incredibly simple and surprisingly useful. Every frontend developer should have this installed.

Install: WhatFont — available on the Chrome Web Store.

3. ⚡ JSON Viewer

Best for: Anyone working with APIs or JSON data in the browser.

If you have ever opened a raw API response in Chrome and been greeted by one giant unformatted wall of text, you know the pain. It is unreadable. It is stressful. And it slows you down.

JSON Viewer automatically formats any JSON response in your browser into a clean, collapsible, color-coded tree. You can expand and collapse nodes, search through the data, and actually understand what the API is returning.

Real-life example: You are debugging a third-party API. The response has deeply nested objects. With JSON Viewer, you collapse the parts you do not need and focus on exactly the field you are looking for. What could take five minutes of scrolling through raw text takes about ten seconds.

There are a few variants of this extension on the Web Store. Any well-rated one with formatting and collapsible nodes will do the job.

Install: Search "JSON Viewer" on the Chrome Web Store and pick the highest-rated option.

4. 💡 ColorZilla

Best for: Developers and designers who work with colors daily.

Color picking sounds like a small thing. But if you are building UI, you grab colors constantly — from designs, from websites, from mockups. ColorZilla gives you a pixel-level color picker that works anywhere on your screen.

You click the eyedropper, hover over any element, and it instantly gives you the exact HEX, RGB, or HSL value. It also keeps a history of recently picked colors and includes a gradient generator.

Real-life example: Your designer sends you a Figma screenshot over chat (not the actual file, because of course not 😅). You need the exact hex code for that button color. You open ColorZilla, click the eyedropper, hover over the button, and there it is: #fd6e4e. Perfect.

It is small, fast, and one of those tools you use without even thinking about it after a while.

Install: ColorZilla — available on the Chrome Web Store.

5. ✅ Lighthouse (Built-in, But Worth Knowing)

Best for: Developers who want to audit performance, accessibility, and SEO.

Technically, Lighthouse is already built into Chrome DevTools — but many developers never open it or do not realize how powerful it is. It deserves a spot on this list because it is genuinely one of the best developer tools available, and it is completely free.

Lighthouse runs an automated audit on any web page and gives you a detailed score for Performance, Accessibility, Best Practices, and SEO. It also gives you specific, actionable suggestions to fix each issue it finds.

Real-life example: You finish building a page and feel good about it. You run Lighthouse and find out the images are not compressed, there are no ARIA labels on your buttons, and the render-blocking scripts are slowing things down. It tells you exactly what to fix and why. Your client's page goes from a 54 to an 89 performance score after one session.

To use it: Open DevTools → Click the Lighthouse tab → Click Analyze page load. That's it.

If you are building anything for real users, run Lighthouse before you ship. Every time.

Quick Comparison: With vs Without These Extensions

Task	Without Extensions	With Extensions
Identify a font on a site	Dig through DevTools CSS	Hover and read instantly
Read an API response	Stare at raw JSON text	Collapsible, color-coded view
Pick a color from a screenshot	Guess and test	Exact HEX in one click
Debug React state	Add `console.log` everywhere	Inspect live in Components tab
Audit page performance	Manual checks, guessing	Full report in one click

The difference is real.

Best Tips for Using Chrome Extensions as a Developer

Only install what you use. Too many extensions slow Chrome down and create security risks. Keep it lean.
Check permissions before installing. A color picker does not need access to your clipboard history. Be mindful.
Use the Extensions shortcut bar. Pin the ones you use daily so they are one click away.
Update your extensions regularly. Outdated extensions can break or become vulnerable.
Test with extensions disabled sometimes. When debugging, turn off extensions temporarily. They can interfere with your page behavior or DevTools.

Common Mistakes Developers Make with Extensions

Installing too many at once. It feels like setting up a great toolkit, but ten extensions running simultaneously is a real performance hit. Install one, use it for a week, then add another.

Ignoring extension permissions. Many developers click "Add to Chrome" without reading what access the extension is requesting. Always check. A suspicious extension with broad permissions is a real security concern.

Forgetting to use Lighthouse. This one is already in DevTools and most developers never touch it. If you are building for production, use it. The accessibility and performance insights alone are worth it.

Relying on extensions instead of learning DevTools. Extensions are helpers, not replacements. Knowing Chrome DevTools deeply is a core developer skill. Extensions just make certain parts of that faster.

Conclusion

Your browser is one of your most important work environments. A few well-chosen extensions can turn it from a basic tool into a genuinely powerful developer workspace.

To recap the five worth installing:

React Developer Tools — for debugging React apps properly
WhatFont — for identifying any font instantly
JSON Viewer — for reading API responses without pain
ColorZilla — for picking exact colors from anywhere
Lighthouse — for auditing performance and accessibility before you ship

None of these are flashy. They are just practical, reliable, and time-saving. That is exactly the kind of tool that stays in your browser for years.

If this was useful, share it with a developer friend who is still wrestling with raw JSON in their browser tab 😄. And for more practical developer content like this, check out hamidrazadev.com — there is plenty more where this came from.

Why Most Developers Love Dark Mode (And It's Not Just a Vibe)

Muhammad Hamid Raza — Sat, 09 May 2026 10:45:22 +0000

You open your laptop at 11 PM to fix "just one bug." The screen blasts you with a wall of white light. Your eyes feel like they're being interrogated. Sound familiar? 😅

Dark mode has quietly become the unofficial uniform of the developer world. Open any code editor, terminal, browser dev tool, or GitHub repo — chances are it's dressed in dark. But why exactly? Is it just aesthetic? Is it a productivity thing? Or are developers just wired to love the night?

Let's dig into the real reasons why most developers swear by dark mode, and whether it actually deserves all the love it gets.

What Is Dark Mode?

Dark mode is a display setting that flips the default color scheme of an interface. Instead of dark text on a white background, you get light text on a dark (usually near-black or deep gray) background.

It's available in almost every modern OS, browser, app, and code editor today — from VS Code and JetBrains IDEs to GitHub, Twitter, Discord, and even Google Docs.

Think of it like switching from a fluorescent office room to a cozy desk lamp setup. Same work. Very different vibe — and for many, very different comfort.

Why Dark Mode Matters for Developers

Developers don't just stare at screens occasionally. They stare at screens all day. Sometimes all night too.

When your job involves reading thousands of lines of code, debugging complex logic, and switching between dozens of tabs — how your screen looks isn't a minor detail. It directly affects how long you can work comfortably, how quickly your eyes tire, and even how focused you feel.

That's exactly why dark mode isn't just a trend for developers. For many, it's a genuine quality-of-life upgrade.

Real Reasons Developers Love Dark Mode

1. 🔧 It Reduces Eye Strain During Long Sessions

This is the big one. Staring at a bright white screen for 8+ hours is genuinely tiring. Dark mode reduces the overall amount of light your screen emits, which can reduce the strain on your eyes — especially in dim or nighttime environments.

It's not a magic cure, but many developers notice real relief after switching. Fewer headaches. Less of that burning sensation by 6 PM.

2. 💡 Code Just Looks Better on Dark Backgrounds

Syntax highlighting — the colorful way editors display different parts of your code — pops brilliantly against dark backgrounds. Keywords in blue, strings in green, comments in gray — they stand out clearly and make code much easier to scan.

On a white background, those same colors feel flatter and harder to distinguish at a glance. If you want your code to feel alive, dark mode is where syntax highlighting truly shines.

3. 🌙 It Matches the Developer's Natural Habitat

Developers often work late. Deadlines don't care about time zones. When everyone else is asleep and you're still pushing commits, a pitch-black terminal on a black background feels less aggressive on your environment — and on your mood.

Dark mode also reduces how much light your screen throws into the room, which is genuinely considerate if you're sharing a space with someone sleeping nearby.

4. ⚡ It Saves Battery on OLED and AMOLED Screens

On OLED and AMOLED displays — which are common on modern laptops and phones — true black pixels are literally turned off. Dark mode means fewer lit pixels, which means less power consumption.

For developers who code on their laptops without a charger, dark mode can genuinely squeeze extra time out of a battery. Practical and stylish.

5. 👀 It Creates a Focused, Distraction-Free Atmosphere

There's a psychological side too. A dark interface naturally draws your attention toward the content — the code, the text, the task at hand — rather than the white space around it.

Many developers describe dark mode as creating a sort of "tunnel vision" that helps them stay focused. It's the coding equivalent of noise-canceling headphones.

6. 🚀 It Looks Professional and Clean

Let's be honest — dark mode just looks good. There's a reason tech companies, dev tools, and portfolio sites often default to dark themes. It signals sophistication, technical seriousness, and modern design taste.

If you're screensharing your code in a presentation or live streaming your workflow, a dark IDE immediately looks polished. First impressions matter, even in code.

Dark Mode vs Light Mode: A Balanced Look

This is one of those debates where both sides have real points. Here's an honest breakdown:

Situation	Better Choice
Long coding sessions at night	Dark Mode ✅
Reading long documentation	Light Mode ✅
Working in a bright room or sunlight	Light Mode ✅
Working in a dim room or late hours	Dark Mode ✅
OLED laptop on battery	Dark Mode ✅
Users with certain visual impairments	Light Mode ✅
Screensharing code in presentations	Dark Mode ✅
Proofreading written content	Light Mode ✅

The honest truth? Neither is universally superior. Dark mode wins in low-light coding environments. Light mode often wins for reading heavy text in bright conditions. Many experienced developers actually toggle between the two depending on context.

Best Tips for Dark Mode Users

Choose your dark theme carefully. Pure pitch black (#000000) can actually create too much contrast with white text. Deep dark grays like #1a1a2e or #121212 are often easier on the eyes.
Match your terminal, editor, and browser to the same dark theme family for a consistent, less jarring experience.
Use a good font. On dark backgrounds, fonts like JetBrains Mono, Fira Code, or Cascadia Code are legible and look clean.
Enable OS-level dark mode so your apps and system UI stay consistent, not just your IDE.
Don't go full dark mode everywhere without thinking. Some apps just aren't optimized for it and end up looking weird or broken.
Adjust your screen brightness. Dark mode doesn't mean you need max brightness. Tone it down — your eyes will thank you.

Common Mistakes Developers Make With Dark Mode

Picking a theme that's all contrast, no comfort.
Maximum black with maximum white text looks sharp for screenshots but is brutal for 4-hour sessions. Find a theme that balances contrast with warmth. Popular ones like One Dark Pro, Dracula, and Tokyo Night are popular for a reason — they've been tuned over time.

Ignoring external lighting.
Dark mode helps most in low-light rooms. If you're working in a bright office, dark mode can actually make the screen harder to read because the ambient light creates glare on a dark surface.

Assuming dark mode fixes all eye strain.
Dark mode helps, but it doesn't replace proper habits. Take screen breaks. Follow the 20-20-20 rule (every 20 minutes, look at something 20 feet away for 20 seconds). Blink. Adjust your monitor height. No color scheme fixes poor ergonomics.

Forcing dark mode on every site using browser extensions.
Some websites are genuinely not built for dark mode. Forcing it can invert images, make colors muddy, or break layouts. Use it where it works natively when possible.

Never trying light mode again.
If you've been on dark mode for years and always feel like reading documentation is painful — try switching to a clean light theme for a week. Sometimes the brain just needs a different kind of contrast for reading-heavy work.

Conclusion

Dark mode isn't just aesthetic rebellion or developer fashion. For many developers, it's a genuine comfort upgrade that reduces eye strain, extends battery life, improves focus, and makes code easier to read — especially during those long late-night sessions that are basically a rite of passage in this profession.

That said, it's not a one-size-fits-all solution. Knowing when to use dark mode and when to switch is the real skill. The best developers stay flexible and optimize their environment for actual comfort, not just looks.

If you're not on dark mode yet, give it a serious two-week trial with a well-designed theme like Dracula or One Dark Pro. If you are on dark mode — welcome to the club. You're in good company. 🌙

Want to read more practical developer content like this? Head over to hamidrazadev.com for more articles, tips, and tutorials built for real developers.

If this post helped you or made you think differently about your setup, share it with a dev friend who's still squinting at a white screen. 😊

What Is a CMS? A Friendly Guide for Beginners and Developers 🚀

Muhammad Hamid Raza — Wed, 06 May 2026 10:52:03 +0000

Ever tried updating a small typo on a website by editing raw HTML, and ended up breaking the entire layout? 😅 If yes, welcome to the club. That tiny moment of panic is exactly why CMS platforms exist.

Today, websites are everywhere — blogs, online stores, school portals, news sites, portfolios. But not everyone wants to write code every time they need to add a blog post or update a banner. That's where a CMS quietly saves the day.

So let's break it down in plain English: what is a CMS, why do developers and non-developers love it, and when should you actually use one?

What Is a CMS?

CMS stands for Content Management System.

In simple words, a CMS is a software tool that helps you create, edit, organize, and publish content on a website — without needing to write code for every single change.

Think of it like Google Docs, but for your website. You log in, type your content, click publish, and it appears online. The CMS handles the boring technical parts behind the scenes — storing your text, managing images, organizing pages, and showing them to visitors.

A quick analogy for younger readers: imagine a school notice board. The principal doesn't rebuild the board every time there's a new notice. They just pin a new paper on it. A CMS is that notice board for your website. 📌

Popular examples you may have heard of include WordPress, Drupal, Joomla, Ghost, Strapi, Contentful, and Sanity.

Why a CMS Matters

Here's the honest truth: most website owners are not developers. They are writers, teachers, shop owners, marketers, and small business folks who just want their content online.

A CMS matters because it:

Lets non-technical people manage a website on their own.
Saves developers from updating content manually every week.
Speeds up website building since common features (login, comments, media library) come built-in.
Keeps content organized in one place so nothing gets lost.

If you're a developer, a CMS frees you to focus on the fun parts — design, performance, custom features — instead of pushing tiny content updates for clients at midnight.

And if you're a beginner learning web development, understanding CMS concepts is a huge career booster. A massive part of the web runs on CMS platforms, especially WordPress.

Benefits of Using a CMS (with Real Examples)

Here are the real, practical benefits — not just buzzwords:

No coding for everyday updates 💡

Example: A bakery owner can add a new cake to the menu without calling a developer. They just log in, upload a photo, type the price, and click publish.
Built-in user roles

Example: On a news website, editors can write articles, but only the admin can publish them. A CMS handles these permissions out of the box.
Media management made easy 🖼️

Example: Uploading 50 product images becomes a drag-and-drop task instead of an FTP nightmare.
Templates and themes

Example: A student building a portfolio can pick a clean theme in WordPress and have a working site in an afternoon.
Plugins and extensions 🔧

Example: Want a contact form, SEO tools, or an online shop? Install a plugin instead of building it from scratch.
SEO-friendly structure

Example: Most CMS platforms generate clean URLs, sitemaps, and meta tags automatically, which helps your content show up on Google.
Scales with your needs

Example: A personal blog can grow into a full magazine or e-commerce store without rebuilding the whole site.

Traditional CMS vs Headless CMS (Quick Comparison)

This is one comparison that genuinely helps, especially for developers.

Traditional CMS (like WordPress)

Frontend and backend are tightly connected.
Easier to set up for non-developers.
Great for blogs, small business sites, and portfolios.
Less flexible if you want to use modern frameworks like React or Next.js directly.

Headless CMS (like Strapi, Sanity, Contentful)

Only handles the backend (the content).
You build the frontend with any framework you like.
Perfect for apps, multi-platform projects (web + mobile), and modern stacks.
Requires more developer involvement to set up.

Easy rule of thumb:

If your client just wants a website, a traditional CMS is usually enough. If you're building a custom app or delivering content to multiple platforms, go headless. ⚡

Best Tips: Do's and Don'ts

Do's ✅

Pick a CMS that matches your project's size. Don't use a hammer for a thumbtack.
Keep your CMS and plugins updated to avoid security issues.
Take regular backups. Future-you will thank present-you.
Use strong passwords and two-factor authentication for admin accounts.
Learn the basics of how the CMS stores data — it helps when something breaks.

Don'ts ❌

Don't install dozens of plugins "just in case." Each one adds weight and risk.
Don't edit core CMS files directly. Updates will overwrite your changes.
Don't ignore performance. A slow CMS site loses visitors fast.
Don't pick a CMS just because it's trendy. Pick one that fits the project.

Common Mistakes People Make

Even experienced developers slip up here. A few mistakes I see often:

Choosing the wrong CMS. People grab WordPress for everything, even when a static site generator or headless CMS would be simpler and faster.
Skipping security basics. Default admin usernames, weak passwords, and outdated plugins are an open invitation for attackers.
Overloading the site with plugins. Each plugin is extra code running on your site. Too many plugins = slow site + more bugs.
Forgetting backups. One bad update can wipe out months of work. Backups are not optional.
Ignoring the editor experience. If your client struggles to add a blog post, the CMS setup failed — no matter how clean your code is.

These mistakes happen because CMS platforms feel "easy" at first, so people skip the planning step. A few minutes of thinking ahead saves days of fixing later.

Final Thoughts

A CMS is simply a tool that makes managing website content easier for everyone — from a teenager starting their first blog to a full development team running a global news platform.

If you're a beginner, start with something like WordPress to feel the magic of publishing without coding. If you're a developer, explore headless CMS options to combine clean backends with modern frontends. Either way, you're learning a skill the web genuinely runs on. 🌍

If this guide helped clear things up, share it with a friend who's still scared of editing their website. And if you enjoyed the writing style, you'll find more friendly developer guides on hamidrazadev.com.

Drop a comment with the CMS you use — I'm always curious to hear what works for other devs. 😊

Happy building!

Why DNS Was Introduced and How It Replaced Raw IP Addresses

Muhammad Hamid Raza — Tue, 05 May 2026 08:57:35 +0000

Have you ever wondered what actually happens when you type google.com into your browser and press Enter? 🤔

Behind the scenes, a quiet but brilliant system kicks into action — one that most people use thousands of times a day without ever thinking about it. That system is DNS, the Domain Name System.

Before DNS existed, accessing a website meant memorizing long strings of numbers. We're talking things like 192.168.1.1 but for every single website on the internet. Sounds exhausting, right?

This post explains why DNS was introduced, how it replaced raw IP addresses, and why understanding it makes you a sharper developer, a better debugger, and honestly just a more informed person on the internet.

What Is an IP Address?

Before we can appreciate DNS, we need to understand what it replaced.

Every device connected to the internet — your laptop, your phone, the server hosting your favorite website — has an IP address. Think of it like a home address. If you want to send a letter, you need to know where the house is. If your browser wants to load a website, it needs to know the server's address.

An IPv4 address looks like this: 142.250.190.78
An IPv6 address looks like this: 2607:f8b0:4004:c09::64

These numbers are how machines identify and talk to each other. Accurate? Yes. Human-friendly? Absolutely not.

What Is DNS?

DNS stands for Domain Name System.

It is essentially the internet's phonebook. Instead of memorizing a number, you remember a name — like google.com or github.com — and DNS quietly translates that name into the correct IP address behind the scenes.

Here is a simple analogy. Imagine you want to call your friend Ayesha. You don't memorize her phone number. You just search "Ayesha" in your contacts and your phone finds the number for you. DNS does exactly that — but for websites.

You type a human-friendly name → DNS finds the IP address → your browser connects to the right server.

Simple. Elegant. And completely invisible when it works correctly.

Why Was DNS Introduced? The Real Story

DNS did not appear out of nowhere. It was born out of a very real and growing problem.

The Early Internet and the HOSTS.TXT File

In the early days of the internet (the ARPANET era, late 1960s to early 1980s), the network was tiny. There were only a few hundred computers connected to it — mostly at universities and research labs.

Back then, every computer had a file called HOSTS.TXT. This plain text file listed every hostname and its matching IP address on the entire network.

It looked something like this:

192.0.0.1    stanford
192.0.0.2    mit
192.0.0.3    ucla

When you wanted to connect to another machine, your computer looked up the name in this file and got the IP. Simple enough — when the internet was small.

There was one central copy of HOSTS.TXT maintained by Stanford Research Institute. Every network connected to ARPANET would download this file periodically to stay updated.

The Problem That Made HOSTS.TXT Impossible to Scale

As the internet grew through the late 1970s and early 1980s, this system started to break down fast. Here is why:

The file grew too large. With hundreds and then thousands of machines, HOSTS.TXT became huge and slow to process.
Updates were too slow. It took days for changes to spread across the network. New hostnames would not appear immediately everywhere.
Name conflicts were a nightmare. Two organizations might register the same hostname because there was no central authority to prevent it.
Bandwidth was being wasted. Every machine had to download the full file constantly to stay current.
Human memory still had limits. Even with the file doing the lookup, administrators had to manage it manually.

The internet was growing, and HOSTS.TXT simply could not keep up.

Enter Paul Mockapetris

In 1983, computer scientist Paul Mockapetris designed and published the DNS specification in RFC 882 and RFC 883. His solution was both smart and scalable.

Instead of one giant file maintained in one place, DNS would be a distributed, hierarchical database spread across thousands of servers around the world. No single server would know everything. But together, they would be able to answer any hostname query on the planet.

This was the turning point. DNS replaced HOSTS.TXT, and it has been running the internet ever since.

Why This Matters for Developers

You might be thinking, "Okay, interesting history — but why should I care as a developer?"

Fair question. Here is why DNS knowledge is actually useful day-to-day:

1. Debugging Network Issues

When your app cannot connect to an external API or your domain is not loading, DNS is often the first thing to check. Understanding how DNS works helps you debug faster instead of staring blankly at a timeout error.

2. Deploying Apps and Configuring Domains

When you deploy a Next.js app to Vercel or a server on DigitalOcean, you always have to update DNS records — A records, CNAME records, TXT records. Knowing what these mean saves you hours of confusion.

3. Setting Up Email

Configuring a custom email domain requires DNS records like MX and SPF. Without understanding DNS basics, this feels like dark magic.

4. Performance and Caching

DNS responses are cached for a period defined by TTL (Time to Live). If you update a DNS record and it does not take effect immediately, that is TTL doing its job. Knowing this prevents unnecessary panic.

5. Security

DNS-based attacks like DNS spoofing and DNS hijacking are real threats. Developers and sysadmins who understand DNS are better equipped to protect their infrastructure.

How DNS Actually Works: A Step-by-Step Breakdown

Let's trace what happens when you type hamidrazadev.com into your browser.

Step 1 — Check the local cache
Your browser first checks if it has recently resolved this domain. If yes, it uses the cached IP and skips the rest.

Step 2 — Ask the Recursive Resolver
If not cached, your device contacts a recursive resolver — usually provided by your ISP or a public DNS service like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).

Step 3 — Ask the Root Name Server
The resolver asks a Root Name Server where to find information about .com domains. There are 13 root server clusters around the world (operated by organizations like ICANN, NASA, and Verisign).

Step 4 — Ask the TLD Name Server
The root server points the resolver to the TLD (Top-Level Domain) Name Server responsible for .com.

Step 5 — Ask the Authoritative Name Server
The TLD server points to the Authoritative Name Server for hamidrazadev.com specifically — this is the server that actually knows the IP address.

Step 6 — Get the IP address
The authoritative server returns the IP address. The resolver caches it and sends it to your browser.

Step 7 — Your browser connects
Your browser now has the IP address and makes a request to the server. The website loads. 🚀

This entire process typically completes in milliseconds.

DNS vs. Raw IP Addresses: A Quick Comparison

Feature	Raw IP Address	DNS
Human-readable	❌ No	✅ Yes
Easy to remember	❌ Very hard	✅ Simple names
Scales with internet growth	❌ No	✅ Distributed system
Supports changes	❌ Hard to update	✅ Update DNS records anytime
Required for email/SSL setup	❌ Insufficient	✅ Essential

Using raw IPs still works in certain scenarios — like internal networks or hardcoded server calls. But for public-facing services, DNS is non-negotiable.

Common DNS Record Types You Should Know

Here is a quick reference for the records developers deal with most often:

A Record — Maps a domain to an IPv4 address. This is the most common record.
AAAA Record — Maps a domain to an IPv6 address.
CNAME Record — Points one domain to another domain (alias). Used a lot in Vercel and Netlify deployments.
MX Record — Specifies the mail server for a domain. Needed for email.
TXT Record — Stores arbitrary text. Used for domain verification and SPF/DKIM email authentication.
NS Record — Identifies which name servers are authoritative for a domain.

Best Tips for Working with DNS

✅ Do's

Lower your TTL before making changes. Before you update a DNS record, lower the TTL to something like 300 seconds (5 minutes). This makes changes propagate faster. Once stable, you can raise it back.
Use a reliable DNS provider. Cloudflare DNS (1.1.1.1) and Google DNS (8.8.8.8) are fast and trustworthy for resolvers.
Use nslookup or dig to debug. These command-line tools let you query DNS directly and are invaluable for troubleshooting.
Document your DNS records. Keep a simple spreadsheet or note of what each record does. Future-you will thank present-you.

❌ Don'ts

Don't expect instant propagation. DNS changes take time to spread globally — sometimes minutes, sometimes up to 48 hours depending on TTL values.
Don't delete records without checking dependencies. Removing an MX record will break your email. Removing a CNAME might break your subdomain.
Don't rely on IP addresses directly in production configs. If the server IP changes (which happens), you will have to update every hardcoded reference. Use domain names instead.

Common Mistakes People Make with DNS

Mistake 1: Panicking when changes don't apply immediately

DNS propagation is not instant. When you update a record and it doesn't work right away, that's normal. Wait for the TTL to expire. Use tools like whatsmydns.net to track propagation globally.

Mistake 2: Forgetting to renew a domain

Your domain is registered, not owned forever. When it expires, your DNS stops working and someone else can register it. Set auto-renewal and use a real email for domain alerts.

Mistake 3: Confusing CNAME and A records

A CNAME points to another domain name. An A record points to an IP address. Using a CNAME where an A record is needed (or vice versa) is a classic setup mistake that causes hours of confusion.

Mistake 4: Setting TTL too high during migration

If you are moving a website to a new server and your TTL is set to 86400 (24 hours), visitors may keep hitting the old server for an entire day. Always lower TTL in advance before migrations.

Mistake 5: Not testing locally before going live

Use dig or nslookup to confirm your DNS is pointing where you think it is before announcing a new deployment to the world.

Conclusion

DNS is one of those technologies that works so silently and reliably that most people forget it exists — until it breaks. 😄

What started as a simple text file on a handful of computers in the early internet became a distributed, global system that handles billions of queries every single day. It replaced raw IP addresses not by eliminating them, but by making them invisible to humans — and that invisibility is the point.

For developers, understanding DNS is not just academic knowledge. It is a practical skill that shows up in deployments, debugging sessions, email setups, domain migrations, and security decisions. The more comfortable you are with it, the less mysterious the internet becomes.

The big takeaway: IP addresses are how machines talk. DNS is how humans stay sane while that's happening.

If you found this post helpful, feel free to share it with a fellow developer or student who is just starting to explore how the internet works. 😊

For more developer content, tutorials, and deep dives like this one, visit hamidrazadev.com — new posts go up regularly and cover topics from frontend development to networking concepts like this one.

Drop a comment if you have questions, or share this post if it cleared something up for you. Happy coding! 🚀

VS Code 1.118 Is Here — And It's All About Smarter Agents, Faster Code, and Less Token Waste

Muhammad Hamid Raza — Mon, 04 May 2026 13:42:55 +0000

You updated VS Code, glanced at the changelog, and thought, "Cool, more Copilot stuff." Then you closed it and moved on.

But wait — this release is actually worth a proper look. 👀

VS Code 1.118 (released April 29, 2026) is packed with features that genuinely change how you work with AI agents, search your codebase, manage chat history, and even keep your token usage from quietly draining your budget. Whether you're using Copilot daily or just exploring AI-assisted coding, there's something real here for you.

So let's break it down in plain English — no corporate fluff, just the stuff that matters.

What Is VS Code 1.118?

VS Code 1.118 is the latest monthly release of Visual Studio Code — Microsoft's free, open-source code editor that millions of developers use every day.

Each release ships new features, bug fixes, and improvements. This one focuses heavily on the agent experience, which basically means making Copilot smarter, faster, and cheaper to run.

If you're not familiar with agents: think of them as AI that doesn't just answer questions — they act. They write code, run terminal commands, search your files, and loop through tasks until the job is done. This release makes all of that smoother and more efficient.

Why This Release Matters

Here's the honest truth: AI-assisted coding is no longer a gimmick. It's becoming part of the daily workflow for a lot of developers.

But more AI usage means more tokens. More tokens means higher costs — especially now that GitHub announced Copilot is moving to usage-based billing on June 1, 2026.

VS Code 1.118 directly addresses this. The team made serious engineering improvements to reduce how many tokens each request uses, without making Copilot worse. That's a meaningful change for anyone who relies on it.

Beyond cost, this release also:

Makes it easier to search across massive codebases
Lets you control Copilot sessions remotely, from your phone
Helps you revisit your chat history like a dev journal
Brings TypeScript 7 one step closer to everyone

That's not a small update. That's a solid month of real improvements.

Key Features with Real-Life Examples

🚀 Remote Control for Copilot CLI Sessions

Imagine you kick off a long agent task before lunch. While you're away, it hits a decision point and stops. Previously, you'd have to be back at your machine to continue.

With remote control, you can approve, steer, or check progress from your phone using the GitHub mobile app — while the session keeps running on your machine in the background.

Enable it with the github.copilot.chat.cli.remote.enabled setting and type /remote on in a Copilot CLI chat to get started.

🔍 Semantic Indexing for All Workspaces

Before 1.118, semantic search (which lets Copilot find code by meaning, not just exact words) only worked with GitHub or Azure DevOps repos.

Now it works for any workspace. So if you ask Copilot "where do we handle user authentication?", it can find code with terms like signIn, verifyCredentials, or OAuth token exchange — even if the word "authentication" never appears.

For local projects, it might take a few minutes to build the index initially. But once it's ready, Copilot understands your codebase much better.

💡 GitHub Text Search Across Repos and Orgs

Semantic search is great for fuzzy intent. But sometimes you need an exact match — like finding a specific error message or API name across your entire organization's codebase.

The new githubTextSearch agent tool does a grep-style search across any GitHub repo or organization, giving Copilot a much sharper way to look things up outside your current workspace.

⚡ Massive Token Efficiency Improvements

This is the one that affects your wallet directly. The team rolled out several changes:

Cache reuse across turns: Over 93% of each request is now served from cache in active agent sessions. For Anthropic models, cached tokens cost roughly 10x less.
Tool search tool: Instead of loading every possible tool schema on every request, VS Code now loads a small core set and fetches the rest only when needed. This alone saves up to 20% in token usage for Claude Sonnet 4.5+ users.
Agentic search and execution tools: Powered by smaller, cheaper models that handle specific tasks like codebase exploration and terminal commands. Early results show up to 20% additional token savings.

None of this changes how Copilot behaves — it just makes it cheaper to run.

📋 Chronicle — Your Chat History as a Dev Journal (Experimental)

Ever tried to write a standup report and completely blanked on what you did yesterday?

Chronicle tracks your Copilot chat sessions in a local SQLite database — recording which files you touched, which PRs you referenced, and what you were working on. Then you can ask it things like:

/chronicle:standup → Generates a standup report from the last 24 hours
/chronicle:tips → Gives you personalized prompting tips based on your usage
/chronicle what files did I edit yesterday? → Free-form natural language queries

Enable it with github.copilot.chat.localIndex.enabled. It's experimental, but genuinely useful.

🛠️ TypeScript 7.0 Beta Support

TypeScript 7 is a full rewrite in native code. The performance difference is wild — VS Code's own build time dropped from 60 seconds to 10 seconds just by switching to TS 7 for type checking.

You can try it today by installing the TypeScript Native preview extension. It's still beta, so it's not for production, but it's worth testing.

🖥️ VS Code Agents App (Insiders)

If you're on VS Code Insiders, the Agents app now integrates more tightly:

Launch it directly from the title bar
Access it from the browser at insiders.vscode.dev/agents (requires a Dev Tunnel)
Use the Claude Agent alongside Copilot and other agents
Tabs persist across sessions, so your browser doesn't refresh when you switch context

It's still in preview, but it's shaping up into a genuinely useful parallel workflow tool.

Before vs. After: How Token Usage Has Changed

Area	Before 1.118	After 1.118
Cache reuse per request	Variable	93%+ in active sessions
Tool schema loading	All tools every turn	Core set + on-demand loading
Terminal command handling	Main model	Smaller, dedicated execution tool
Codebase search	Main model	Smaller, dedicated search tool
Estimated token savings	Baseline	Up to ~20-40% in agent workflows

This doesn't mean Copilot suddenly becomes free — but for heavy users, the cumulative difference will be noticeable.

Best Tips for Getting the Most Out of VS Code 1.118

✅ Do:

Enable github.copilot.chat.localIndex.enabled to try Chronicle — your future self will thank you at standup
Run Build Codebase semantic index manually if Copilot seems off on local projects
Try /remote on in Copilot CLI before leaving your desk for long agent tasks
Install the TypeScript Native preview extension in a non-production project to test TS 7 performance

❌ Don't:

Expect remote control to work without enabling the github.copilot.chat.cli.remote.enabled setting first
Assume TS 7 is production-ready — it's still beta
Ignore the Chronicle feature just because it's experimental; it's genuinely useful for tracking work

Common Mistakes to Avoid

Skipping experimental features entirely. A lot of the best stuff in 1.118 is behind experimental flags. That's not a warning sign — it's a chance to try genuinely useful features before they're stable. Just use them in non-critical projects first.

Forgetting to build the semantic index. If you're on a local workspace (not GitHub/ADO), Copilot won't have semantic search until the index is ready. Run the build command manually if you want it available right away.

Ignoring the token efficiency changes. If you're on a usage-based plan, these improvements aren't just nice to have — they affect your bill. Make sure you're on Claude Sonnet 4.5+ or GPT-5.4/5.5 to benefit from the tool search savings.

Not checking for updates manually. VS Code 1.118 is rolling out gradually. If you haven't seen it yet, go to Help → Check for Updates to get it right away.

Wrapping Up

VS Code 1.118 is a focused, well-executed release. It doesn't add flashy gimmicks — it makes the AI-assisted workflow more reliable, more efficient, and cheaper to run.

Remote control for CLI sessions, semantic search everywhere, Chronicle for tracking your work, and serious token savings across the board — these are practical improvements that affect your daily workflow.

If you're a developer who uses Copilot regularly, this update is worth enabling the experimental features and exploring properly.

Check for the update, enable Chronicle, test the remote control — and enjoy paying a little less in token costs. 🎉

Want more VS Code breakdowns, dev tools, and web development content? Head over to *hamidrazadev.com** for more practical articles written by a developer, for developers.*

If this post saved you time or taught you something new, share it with your team or drop a comment below — it helps more than you know. 🙌

WiFi vs Cellular Data: Why WiFi Often Wins for Daily Internet Use 🌐

Muhammad Hamid Raza — Mon, 04 May 2026 10:26:25 +0000

We've all been there. You're downloading a big update, watching a tutorial, or pushing code to GitHub, and suddenly your mobile data vanishes faster than free pizza at a developer meetup. 🍕

Then you connect to WiFi, and everything just… works. Smoother. Faster. No panic about your data balance.

But why does WiFi usually feel better than cellular data? Is it always the right choice? And when should you actually stick with mobile data instead?

Let's break it down in simple words, without any tech-jargon overload. Ready to finally understand the difference?

What Is WiFi and What Is Cellular Data?

Before we compare them, let's keep things super simple.

WiFi is internet that comes from a nearby router. The router is connected to a wired internet line (fiber, cable, DSL, or similar), and it shares that connection wirelessly with devices around it, usually inside a home, office, café, or airport.

Cellular data is internet that comes from mobile network towers. Your SIM card connects your phone to those towers, and the tower sends data to your device through radio signals. This is what powers 3G, 4G LTE, and 5G.

Think of it like this:

WiFi is like drinking water from a tap at home. 🚰
Cellular data is like buying bottled water on the go. 💧

Both give you water. But one is cheaper at home, and the other is convenient when you're traveling.

Why This Topic Matters

Internet is no longer optional. It's how we learn, work, build apps, attend meetings, watch tutorials, and stay connected with people we care about.

For developers and students, the choice between WiFi and cellular data affects:

How much money you spend each month
How fast you can download tools, packages, and updates
Whether your video calls freeze during a client demo
How safely you connect to the internet

A small choice, but a big impact on your daily routine.

So the question is simple: why do most people prefer WiFi when it's available? Let's get into the real reasons.

Benefits of WiFi Over Cellular Data (with Real-Life Examples)

Here are the practical reasons WiFi often beats cellular data for most everyday tasks.

1. Usually Cheaper for Heavy Use 💰

Most home and office WiFi plans are unlimited or have very high data limits. Cellular plans, especially prepaid ones, often charge more per GB.

Example: Downloading a 5 GB Android Studio update on mobile data could eat your whole weekly package. On WiFi, it's just… a download.

2. Better for Large Downloads and Uploads

Pushing a Docker image, cloning a big repo, or uploading video content? WiFi is usually more comfortable for that kind of work because routers are built to handle long, heavy sessions without throttling.

Example: A YouTuber uploading a 4K video will almost always pick WiFi to avoid burning through their mobile data plan.

3. More Stable for Video Calls and Meetings

WiFi tends to give a steadier connection inside buildings where cellular signals can drop. If your office is on the 7th floor with thick walls, mobile signals might struggle, but the WiFi router right next to you won't.

Example: During a Zoom standup, WiFi often keeps your video sharp while cellular data can get jittery indoors.

4. Multiple Devices, One Connection

A single WiFi router can serve your laptop, phone, tablet, smart TV, and even your smart bulb at the same time. With cellular data, every SIM is a separate plan (unless you use hotspot, which drains your phone battery fast).

Example: A family of four streaming, gaming, and working from home on a single WiFi plan is much cheaper than four separate mobile data plans.

5. No Stress About Daily or Monthly Limits

Many cellular packages have strict caps. Once you cross them, speed drops or extra charges kick in. Most home WiFi plans either don't have limits or have very generous ones.

Example: Binge-watching a coding course on Udemy at night? WiFi handles it without sweat.

6. Often Faster Where Coverage Is Weak

If you live in an area with weak mobile signal, WiFi (powered by a wired connection) can give you better speeds than cellular ever could in that location.

7. Better Battery Life

This one surprises many people. Phones generally use less battery on WiFi than on cellular, especially when the cellular signal is weak and the phone is constantly searching for a tower.

Example: Ever notice your phone heats up and drains fast in low-signal areas? That's your phone working overtime to stay connected.

WiFi vs Cellular Data: A Quick Comparison

Both have their place. Here's an honest, balanced look.

Feature	WiFi	Cellular Data
Cost for heavy use	Usually cheaper	Often more expensive per GB
Mobility	Works in a fixed area	Works almost anywhere with signal
Speed	Depends on the router and plan	Depends on tower, network, and location
Stability indoors	Generally better	Can drop behind walls
Setup needed	Router required	Just a SIM and signal
Security	Safer on private networks, risky on public ones	Generally encrypted by the carrier
Battery use	Lower	Higher, especially on weak signal
Best for	Home, office, study, big downloads	Travel, commute, emergencies, outdoors

So WiFi isn't always better. It's better for the right situation, which is usually most of our day.

Pros and Cons in Plain Words

Pros of WiFi

Cheaper for heavy and long usage
More stable for indoor work
Supports many devices at once
Lower battery drain
Great for big downloads and video calls

Cons of WiFi

Tied to one location (you can't take your home router to the park)
Public WiFi can be unsafe without a VPN
Needs hardware (router, modem) and setup
If the router or internet line fails, the whole network goes down

Pros of Cellular Data

Works almost anywhere with signal
No setup, just insert a SIM
Good for travel, road trips, and outdoor work
Useful as a backup when WiFi fails

Cons of Cellular Data

Usually pricier per GB
Speeds can drop during peak hours or in crowded areas
Drains battery faster
Hits data caps quickly with heavy usage

The honest truth? Most people don't have to pick one. They use WiFi at home and work, and cellular data on the move. That combo wins almost every time.

Best Tips and Practical Do's & Don'ts

A few habits I've personally found useful as a developer:

Do:

Use WiFi for big tasks: OS updates, IDE downloads, package installs, Docker pulls, and Zoom calls.
Keep mobile data on standby for when WiFi fails (which always happens 5 minutes before a deadline 😅).
Use a VPN on public WiFi, especially in airports, cafés, and hotels.
Set "WiFi only" mode for app updates, cloud backups, and large media downloads.
Restart your router every few weeks. It really does help.

Don't:

Don't log into banking or work accounts on open public WiFi without a VPN.
Don't waste mobile data on auto-playing videos. Turn off autoplay in YouTube, Instagram, and similar apps.
Don't stand right next to the microwave while complaining about slow WiFi. (Yes, microwaves can interfere with 2.4 GHz networks.) 🔧
Don't forget to turn off your hotspot. It silently drains your phone for hours.

Common Mistakes People Make

Even tech-savvy folks slip up here. A few I see often:

1. Trusting any "Free WiFi" sign.
Free WiFi is great, but some networks are set up to capture data. If the network has no password and no login page from a known brand, be careful.

2. Forgetting that "Unlimited" isn't always unlimited.
Many cellular "unlimited" plans slow you down after a certain amount of data. Read the fine print before relying on it for work.

3. Using mobile hotspot as a long-term solution.
Hotspot is a lifesaver in emergencies, but using it daily for hours hurts your phone battery, heats up the device, and burns through data fast.

4. Ignoring router placement.
A router stuffed inside a closet behind a TV will give weak signals. Place it in an open area, ideally in the center of your home or workspace.

5. Not securing the home WiFi.
Leaving your home network with the default password is a small but real security risk. Change it once, and forget about it.

6. Blaming the internet for everything.
Sometimes it's not WiFi or cellular at fault. It's the website, the server, or that one Chrome tab eating all your RAM. 👀

Final Thoughts

WiFi and cellular data aren't enemies. They're teammates. WiFi is your reliable home base, great for heavy work, study, and long sessions. Cellular data is your portable backup, ready whenever you step outside.

For most developers, students, and everyday users, WiFi handles 80% of daily internet needs more cheaply and comfortably, while cellular data steps in for the remaining 20% on the go.

The smartest move isn't picking one. It's knowing when to use which. Once you understand that, you stop wasting money, save battery, and avoid those frustrating "buffering" moments during important calls.

If this article helped clear things up, share it with a friend who keeps blowing through their data plan. 🚀

For more easy-to-follow tech blogs, visit hamidrazadev.com, drop a comment if you have a tip I missed, and let me know your own WiFi-vs-data story. I'd genuinely love to read it. 😊

Happy coding, and may your connection always be stable.

How Web Browsers Work — The Phenomenon Behind Every Web Experience

Muhammad Hamid Raza — Sun, 03 May 2026 11:27:31 +0000

Every time you type a URL and hit Enter, a small miracle unfolds in milliseconds. Most people never think twice about it. Developers should.

1. Introduction — More Than a Window

Open Chrome. Type a URL. Press Enter. A page appears.

Simple, right?

Not even close.

Behind that instant result is one of the most complex pieces of software ever written. A modern web browser is simultaneously a network client, a rendering engine, a JavaScript runtime, a security sandbox, and a mini operating system — all working in perfect coordination, every single time you browse.

Google Chrome has over 35 million lines of code. Firefox has been actively developed for more than two decades. These aren't simple apps — they're engineering marvels disguised as everyday tools.

In this post, we're going to pull back the curtain completely. From the moment you hit Enter to the pixel appearing on your screen — this is how browsers actually work.

2. Step One — Finding the Server (DNS Resolution)

Before anything loads, the browser needs to answer one question: Where is this website?

Computers don't understand domain names like hamidrazadev.com. They speak in IP addresses like 104.21.45.78. The system that translates between the two is called DNS — Domain Name System.

Here's the lookup chain:

Browser Cache — Has it visited this domain recently? If yes, use the saved IP.
OS Cache — Ask the operating system's own DNS cache.
Router Cache — Ask the local network router.
ISP DNS Resolver — Ask your internet provider's DNS server.
Root → TLD → Authoritative Nameserver — A recursive query through the global DNS hierarchy until the correct IP is returned.

This entire process often completes in under 20 milliseconds — but it's the invisible foundation of every page load.

Connecting to the Server — TCP Handshake

With the IP address in hand, the browser opens a TCP connection using a three-way handshake:

Client  →  SYN         →  Server   (I want to connect)
Client  ←  SYN-ACK     ←  Server   (Acknowledged, go ahead)
Client  →  ACK         →  Server   (Connection established)

For https:// sites (which is basically everything today), a TLS handshake follows immediately after — exchanging cryptographic certificates, verifying the server's identity, and establishing an encrypted channel. This is what puts the padlock in your address bar.

Only after all of this does the browser send the actual request:

GET / HTTP/1.1
Host: hamidrazadev.com
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate, br

3. Step Two — The Server Responds

The server processes the request and sends back an HTTP response. This includes:

Status Code — 200 OK, 301 Redirect, 404 Not Found, 500 Server Error
Response Headers — Content type, caching rules, security policies, cookies
Response Body — The actual HTML markup

One of the most important things to understand here: the browser does not wait for the full HTML to download before it starts working. It reads the response as a stream, processing bytes as they arrive over the network. This is called streaming parsing — and it's the reason you sometimes see a page begin rendering before it's fully loaded.

Modern browsers also take advantage of HTTP/2 and HTTP/3, which allow multiple resources (HTML, CSS, JS, images) to be fetched over a single connection simultaneously — a massive leap over HTTP/1.1's one-request-at-a-time model.

4. Step Three — Parsing HTML into the DOM

As HTML bytes arrive, the browser's HTML Parser gets to work. Its job is to convert raw markup text into a structured, in-memory data structure called the DOM — Document Object Model.

Think of it as a tree:

Document
└── <html>
    ├── <head>
    │   ├── <title>My Site</title>
    │   └── <link rel="stylesheet" href="styles.css">
    └── <body>
        ├── <header>
        │   └── <nav>...</nav>
        ├── <main>
        │   └── <article>...</article>
        └── <footer>...</footer>

Every HTML element becomes a node. Every node has a parent, zero or more children, and sibling relationships. This tree is what JavaScript manipulates at runtime — adding, removing, and modifying nodes to create dynamic UIs.

Parser Blocking — The Hidden Performance Trap

Parsing is not always a straight line. The HTML parser can get blocked:

<link rel="stylesheet"> — Triggers a CSS file fetch. Rendering is blocked until CSS is downloaded and parsed (to avoid a flash of unstyled content).
<script> (without async/defer) — The parser stops completely to download and execute the JavaScript before continuing.
<img>, <video> — Non-blocking; parallel fetches are fired off but don't halt the parser.

This is exactly why developers are told to put <script> tags at the bottom of the body, or use defer — to avoid stalling the parser mid-document.

5. Step Four — Building the CSSOM

While the HTML parser builds the DOM, a parallel process handles your CSS — constructing the CSSOM (CSS Object Model).

Every style rule, from every source (<style> tags, external stylesheets, inline styles) is parsed and organized into its own tree. The browser then applies the cascade algorithm to determine which styles actually apply to each element, resolving conflicts using:

Origin — Browser defaults vs. developer styles vs. user overrides
Specificity — #id > .class > element selector
Order of appearance — Later rules override earlier ones at equal specificity
Inheritance — Some properties (like font-family) inherit from parent to child automatically

Once both the DOM and CSSOM are complete, the browser merges them into the Render Tree — a new tree containing only the visible elements, each annotated with their final computed styles.

Elements with display: none are excluded entirely. Elements with visibility: hidden remain in the tree (they still occupy space) but are painted transparently.

6. Step Five — The Rendering Pipeline

With the render tree ready, the browser enters the rendering pipeline — the process of turning data into actual pixels. This happens in four distinct stages:

1. Layout (Reflow)

The browser calculates the exact position and dimensions of every element on the page. This involves:

Box model calculations (margin, border, padding, content width/height)
Flexbox and CSS Grid algorithms
Text wrapping and line-breaking
Relative and absolute positioning

Layout is computed from the root of the render tree downward. Changing a single element's size can trigger a reflow of its descendants and siblings — which is why layout-thrashing in JavaScript is a serious performance concern.

2. Paint

The browser walks the render tree and records paint operations — drawing text, colors, borders, box shadows, images — layer by layer. This stage produces a list of draw calls, not actual pixels yet.

Modern browsers split the page into multiple layers (think: transparent sheets stacked together). Elements that animate or change frequently are promoted to their own layer so they can be updated independently without repainting the rest of the page.

3. Rasterization

Paint commands are converted to actual pixels — either on the CPU or, more commonly, the GPU. The page is broken into tiles and rasterized in parallel for speed.

4. Composite

The GPU combines all rasterized layers into the final frame displayed on screen. CSS properties like transform and opacity are handled entirely at this stage — which is why they're the gold standard for performant animations. They skip Layout and Paint entirely.

The full pipeline looks like this:

JavaScript → Style Recalc → Layout → Paint → Composite
     ↑                                              ↓
  DOM/CSSOM Changes                         Frame on Screen

Browsers target 60 frames per second — that's one frame every 16.67ms. Miss that budget, and you get visible jank.

7. Step Six — JavaScript Execution

No browser discussion is complete without the JavaScript engine — arguably the most complex component of all.

Different browsers ship different engines:

V8 — Chrome, Edge, Node.js
SpiderMonkey — Firefox
JavaScriptCore (Nitro) — Safari

They all follow a similar pipeline:

Source Code → AST → Bytecode → JIT Machine Code

Parsing — JS source is parsed into an Abstract Syntax Tree (AST)
Bytecode Compilation — The AST is compiled to bytecode by an interpreter (e.g., V8's Ignition)
JIT Optimization — Frequently-executed ("hot") code paths are recompiled to highly optimized native machine code (e.g., V8's TurboFan)
Deoptimization — If assumptions change (e.g., a variable's type changes), the JIT compiler throws away optimized code and falls back to bytecode
Garbage Collection — Unreachable memory is automatically freed using a generational GC algorithm

The Event Loop — Why JS Doesn't Freeze

JavaScript is single-threaded — one call stack, one execution context at a time. Yet it handles async operations (network requests, timers, events) without blocking. How?

The Event Loop:

Call Stack → empty? → Check Microtask Queue → Check Macrotask Queue → Push callback → Repeat

Long-running browser operations (fetch, setTimeout, DOM events) are handled by Web APIs in C++ — outside the JS thread.
When they complete, their callbacks enter a queue.
The event loop picks callbacks off the queue and pushes them onto the call stack only when it's empty.

This is why async/await and Promises don't block the UI — they defer callbacks until the call stack is free.

8. The Bigger Picture — Security, Caching & Performance

Process Isolation & The Sandbox

Modern browsers run each tab in its own sandboxed OS process. Even if malicious JavaScript runs in one tab, it cannot access:

Another tab's DOM or data
Your file system
OS-level resources

This is enforced at the OS level — not just by browser rules. A crashed tab crashes its process, not the entire browser.

Key security mechanisms include:

Same-Origin Policy (SOP) — JavaScript on site-a.com cannot read data from site-b.com
Content Security Policy (CSP) — Server-defined rules about which scripts and resources are allowed to load
HTTPS + HSTS — Enforces encrypted connections and prevents downgrade attacks
Cross-Origin Resource Sharing (CORS) — Controlled exceptions to SOP for trusted cross-origin requests

Caching — Speed Through Memory

Browsers cache aggressively to eliminate redundant work:

Cache Type	Lifetime	Speed
Memory Cache	Tab session	Instant
Disk Cache	Controlled by HTTP headers	Fast
Service Worker Cache	Programmatic / Persistent	Flexible

The Cache-Control, ETag, and Last-Modified headers give servers fine-grained control over how long resources are cached and when they expire.

Modern Performance Techniques

<link rel="preload"> — Fetch critical resources (fonts, hero images) before the parser discovers them
<link rel="dns-prefetch"> — Resolve third-party domains early
loading="lazy" — Defer off-screen image/iframe loads
async / defer on scripts — Avoid parser blocking
HTTP/3 + QUIC — Faster connection establishment, especially on lossy mobile networks
Brotli Compression — Smaller transfer sizes than gzip for text-based assets

Final Thoughts — Know Your Runtime

Every page load you've ever experienced — every click, every scroll, every animation — was the product of this entire pipeline running in perfect orchestration, usually in under a second.

As a developer, understanding this isn't just trivia. It's leverage.

It's the difference between a 4-second load and a 0.9-second one. Between janky scroll and buttery 60fps. Between an XSS vulnerability and a hardened app. Between a developer who writes code and one who understands the system their code runs in.

The browser is your runtime. Respect it. Understand it. And build for it with intention.

Run Powerful AI Models Offline on Your Phone with Google AI Edge Gallery (Android & iOS)

Muhammad Hamid Raza — Fri, 01 May 2026 10:24:13 +0000

Have you ever wished you could use a powerful AI assistant without burning through your mobile data — or worrying about your private conversations being sent to some server halfway around the world?

That wish just became reality. 🚀

Google's AI Edge Gallery app lets you download and run real open-source large language models (LLMs) directly on your iPhone or Android phone. No internet. No cloud. No data leaving your device. Just raw AI power running straight from your hardware.

But wait — how good can phone AI actually be? Better than you'd expect. Let's dig in.

What Is Google AI Edge Gallery?

AI Edge Gallery is a free, open-source app built by Google's Research team — available on both Android and iPhone.

Instead of sending your questions to a remote server like most AI apps do, it downloads AI models directly onto your device and runs them locally using your phone's CPU and GPU.

Think of it as a mini AI computer in your pocket — one that works even in airplane mode.

The app supports multiple open-source models, including Google's own Gemma 4 family, and gives you tools for chatting, image analysis, voice transcription, and even simple device automation — all completely offline.

Why This Actually Matters

Most AI tools today are cloud-dependent. That means:

Your prompts travel to remote servers
You need a stable internet connection
Slow networks mean slow responses
You have zero control over what happens to your data

AI Edge Gallery flips all of that. Everything runs on-device, which means your data never leaves your phone. For developers, students, journalists, or anyone handling sensitive information, that's a big deal.

There's also the offline angle. If you're traveling, in a low-connectivity area, or just don't want to burn through your data plan, local AI is incredibly useful.

How to Download It

For Android:
Search for "AI Edge Gallery" on the Google Play Store (by Research at Google). Requires Android 12 or higher. App size: ~23 MB.

For iPhone:
Search for "Google AI Edge Gallery" on the Apple App Store, or visit:
apps.apple.com/us/app/google-ai-edge-gallery/id6749645337
App size: ~68 MB. Requires iOS 13+. Rated 4.0 stars with 1,000+ ratings.

Key Features Worth Knowing 💡

🗨️ AI Chat with Thinking Mode

Have multi-turn conversations with the model just like any AI chat app. The really interesting part? You can toggle Thinking Mode to see the model's step-by-step reasoning before it gives you an answer. It's like watching the AI think out loud — incredibly useful for learning or understanding complex responses.

(Thinking Mode currently works with supported models, starting with the Gemma 4 family.)

🖼️ Ask Image (Multimodal AI)

Point your camera at something — a math problem on a whiteboard, a plant in your garden, a broken error message on your screen — and ask the AI about it. It uses your device's camera or photo gallery to give you visual, detailed answers.

🎙️ Audio Scribe

Speak into your phone and the app transcribes your voice to text in real time. It handles translation too. All of it happens on-device with no audio ever being sent to a server.

🧪 Prompt Lab

This is the developer's favorite corner of the app. You get a dedicated workspace to test prompts with full control over model parameters like temperature and top-k. Perfect for experimenting, learning, and fine-tuning your prompting skills.

🤖 Agent Skills

This takes the app beyond simple chatting. You can add tools like Wikipedia lookups, interactive maps, and rich visual summary cards to make the AI more capable and grounded. You can even load custom skills from a URL or browse community contributions on GitHub.

📱 Mobile Actions

On both platforms, the app can control certain device functions and automate simple tasks — powered by a lightweight fine-tuned model called FunctionGemma 270m, running entirely offline. On iOS, features like controlling the flashlight work well, though more advanced actions like creating calendar events are still limited.

🌱 Tiny Garden

A fun little bonus — a mini-game where you use natural language to plant and harvest a virtual garden. It's experimental and powered by FunctionGemma 270m. Quirky, but genuinely impressive as a demo of what small models can do.

📊 Model Management & Benchmarking

Download models from a curated list or load your own custom models. Run benchmark tests to see exactly how fast each model runs on your specific hardware. Results vary a lot between devices, so this is worth doing before you dive in.

Step-by-Step: Getting Started

Step 1 — Install the App

Download from the Google Play Store (Android) or the Apple App Store (iPhone) and open it.

Step 2 — Download a Model

You'll see a list of available models. Tap one and download it. The models are larger files — usually several hundred MB to a few GB — so download on Wi-Fi.

The home screen features the Gemma 4 family prominently. Start with a smaller variant (like Gemma 4 2B) if you have a mid-range device with limited RAM.

Step 3 — Pick a Feature

Once your model is downloaded, choose what you want to do:

AI Chat for conversation and multi-turn dialogue
Prompt Lab for controlled testing and experimentation
Ask Image for visual queries using your camera
Audio Scribe for voice-to-text transcription
Agent Skills for tool-augmented AI responses

Step 4 — Enable Thinking Mode (Optional but Fascinating)

In the AI Chat screen with a Gemma 4 model loaded, tap the Thinking Mode toggle. Ask a complex question — like "How many R's are in strawberry?" — and watch the model break down its reasoning step by step before answering.

Step 5 — Run a Benchmark

Head to Model Management and run a benchmark test. You'll get real performance numbers for your device. It takes under a minute and helps you understand your hardware's actual capabilities before downloading heavier models.

On-Device AI vs Cloud AI: Quick Comparison

	On-Device (AI Edge Gallery)	Cloud AI (ChatGPT, Gemini Web, etc.)
Internet required	❌ No	✅ Yes
Data privacy	✅ Fully local	⚠️ Sent to servers
Speed	Depends on hardware	Depends on connection
Model size	Limited by device RAM	Very large models
Cost	Free	Often subscription-based
Latest models	Open-source only	Proprietary + cutting-edge
Custom model support	✅ Load your own	❌ Limited
Works offline	✅ Always	❌ Never

The honest take: Cloud AI models like GPT-4o or Gemini 1.5 Pro are still more capable for complex tasks. On-device AI is the best choice for privacy-sensitive use cases, offline situations, learning about AI behavior, and low or no connectivity scenarios.

Tips for the Best Experience 🔧

✅ Do this:

Download models over Wi-Fi — they're large files
Start with smaller models (2B–3B parameters) on mid-range phones
Use Prompt Lab to understand how temperature and top-k affect model output
Try Agent Skills to add Wikipedia, maps, and visual tools to your AI
Run a benchmark first before downloading heavier models

❌ Avoid this:

Don't expect cloud-level accuracy from a model running on phone hardware
Don't run very large models on devices with under 6GB RAM — they'll struggle
Don't skip the benchmark — it gives you genuinely useful data about your device
Don't give up after one slow response — performance improves once the model is fully loaded into memory

Common Mistakes People Make

Downloading the biggest model first

Bigger parameters doesn't always mean better performance on your device. A very large model might run slowly or even crash on phones with limited RAM. Start small, benchmark, then scale up.

Expecting the same output quality as GPT-4 or Gemini Ultra

On-device models are improving rapidly, but they're optimized for size and speed, not maximum intelligence. Go in expecting a capable, private, offline assistant — and you'll genuinely be impressed. Go in expecting a match for the largest cloud models — and you'll be let down.

Ignoring which models are optimized for your chip

Android users on Qualcomm Snapdragon devices now have Gemma 3 1B NPU support, meaning the model runs on the neural processing unit for much faster inference. Always check model details before downloading to pick the best-optimized version for your hardware.

Not trying Agent Skills

Many users stick to basic chat and miss the real power of the app. Agent Skills — Wikipedia grounding, interactive maps, visual summaries — make the AI dramatically more useful. Spend five minutes here and you'll see the difference.

Final Thoughts

Google AI Edge Gallery is one of the most exciting things happening in mobile AI right now. It brings real, powerful open-source models to your Android or iPhone — offline, private, and completely free.

Is it going to replace your cloud AI subscription tomorrow? Probably not for complex tasks. But as a developer tool, a privacy-focused assistant, a learning sandbox, and a reliable offline companion, it's genuinely impressive and improving with every update.

The open-source, community-driven nature makes it even more interesting. Developers are already building and sharing custom Agent Skills, contributing models, and constantly pushing what a phone can do.

Download it, try a small Gemma 4 model, toggle Thinking Mode, and see what your phone is actually capable of. You might be surprised. 😊

For more dev tools, AI guides, and practical developer content, visit hamidrazadev.com. If this post was helpful, share it with a developer or tech friend who'd appreciate it!

10 Tips to Use Claude for Best Performance (Stop Wasting Tokens)

Muhammad Hamid Raza — Thu, 30 Apr 2026 10:51:22 +0000

You open Claude, type a quick message, get a mediocre response, tweak it, re-send it, get a slightly better one, tweak it again… and suddenly you have burned through half your daily message limit trying to get one decent paragraph.

Sound familiar? 😅

Most people treat Claude like a search engine — type something vague, hope for the best, then complain when the output misses the mark. But Claude is not a search engine. It is a reasoning model. And the better your input, the better your output. Every time.

So the real question is: are you getting the most out of every single prompt, or are you silently wasting tokens on back-and-forth you could have avoided?

Here are 10 practical tips that will help you get sharp, accurate, useful results from Claude — without burning through your token budget for nothing.

What Are Tokens, and Why Should You Care?

Before we dive into the tips, let us get one thing straight.

A token is roughly a word or part of a word. When you send a message to Claude — and when Claude responds — both sides use tokens. If you are on a usage-limited plan, tokens are essentially your budget. Waste them on unclear prompts and long back-and-forths, and you hit your limit faster without getting the quality you needed.

Even if tokens are not a concern for you right now, efficient prompting saves time, reduces confusion, and gets you better results. That is always worth it.

Why Prompting Style Actually Matters

Claude is powerful, but it is not a mind reader.

It works best when you give it clear context, clear instructions, and a clear goal. When you leave those things out, Claude has to guess — and even a well-trained AI guessing about your intent is still just guessing.

Better prompts mean fewer re-tries. Fewer re-tries mean fewer tokens spent. And better responses mean less frustration. It is a win on every side.

10 Tips to Get the Best Performance from Claude

1. 🎯 Be Specific About What You Want

Vague prompts produce vague answers. If you type "explain JavaScript", you could get anything from a 500-word intro to a full history of the language.

Instead, say: "Explain JavaScript closures in simple terms with one short example. Keep it under 200 words."

Specificity is your best friend. Tell Claude what topic, what depth, what format, and what length. That one habit alone will improve your results dramatically.

2. 🧑‍💼 Give Claude a Role

Claude performs better when it knows what persona to take on.

Start your prompt with something like:

"You are a senior React developer..."
"You are a friendly teacher explaining this to a 12-year-old..."
"You are a technical writer creating documentation..."

This small change shapes the tone, depth, and style of the entire response. It saves you multiple follow-up messages trying to adjust the voice.

3. 📋 Provide Context Upfront

Claude has no memory of what you did in a previous conversation unless you tell it. Jumping straight into a complex question without context forces Claude to make assumptions — and assumptions lead to mismatched answers.

Before asking your main question, give Claude the background it needs:

"I am building a Next.js app with TypeScript. I am using Supabase for authentication. I have this error in my sign-in function: [paste error]. What could be causing it?"

A bit more setup upfront = a much more useful answer on the first try.

4. ✂️ Use Clear, Short Sentences

Long, winding prompts confuse priorities. When a prompt has ten different ideas crammed into one paragraph, Claude has to figure out what you actually want most — and it might pick the wrong priority.

Keep your prompts clean and structured. Break big requests into clear points if needed. Short sentences are easier to follow for both humans and AI.

5. 📐 Specify the Format You Need

Do you want bullet points? A numbered list? A code block? A paragraph? A table?

Claude will pick a default format if you do not say anything. Sometimes that works. Sometimes it does not. Rather than sending a follow-up message asking for a reformat, just include it in your original prompt:

"Give me the answer as a numbered list."
"Respond only in a code block with comments."
"Write this as a short paragraph, not bullet points."

One sentence of format instruction can save you two or three re-prompts.

6. 🔢 Set a Length Expectation

Claude can write two sentences or two thousand words. Without guidance, it picks somewhere in the middle — which is often not what you needed.

If you want a quick summary, say "Keep it under 100 words."
If you want depth, say "Write a detailed explanation with examples."

Controlling length is one of the easiest ways to get cleaner, more useful responses without any wasted words — on either side.

7. ⛔ Tell Claude What NOT to Do

This one is underrated.

Negative instructions are just as useful as positive ones. If you do not want Claude to add a conclusion, say so. If you do not want technical jargon, mention it. If you do not want a list when you specifically need prose, be clear.

Examples:

"Do not add an introduction. Start directly with the steps."
"Do not include any code. Just explain the concept in plain English."
"Do not suggest alternatives. Just fix what I gave you."

These small guardrails stop Claude from going in a direction you did not want — which means no wasted tokens correcting it.

8. 🔁 Use Follow-Up Prompts Smartly

Even with a great first prompt, sometimes you will want a tweak. That is totally normal. But there is a right way to do follow-ups.

Instead of:
"Change it."

Say:
"Make the tone more casual and remove the second paragraph."

Vague follow-ups force Claude to guess again. Specific follow-ups land on the first try. The goal is fewer rounds of back-and-forth, not more.

9. 🗂️ Break Big Tasks into Smaller Steps

Asking Claude to "build me a full e-commerce website" in one prompt is a recipe for a bloated, half-right response that you then spend ages correcting.

For big or complex tasks, break them into steps:

"First, write the product listing component in React."
"Now write the cart logic."
"Now connect the cart to the listing component."

This gives you better control, cleaner output, and easier debugging if something goes wrong. Smaller tasks also use context more efficiently.

10. 💾 Reuse Prompts That Work

When you find a prompt structure that consistently gives you great results, save it. Seriously — keep a small notes file or a Notion doc with your best-performing prompts.

Whether it is a prompt for writing blog outlines, debugging code, summarizing documentation, or generating component ideas — a saved prompt you can reuse is a token-efficient shortcut for every future task.

Good prompts are assets. Treat them like one.

Quick Comparison: Weak Prompt vs Strong Prompt

	Weak Prompt	Strong Prompt
Topic	Vague or missing	Clearly stated
Context	None given	Background provided
Format	Not specified	Requested explicitly
Length	Not mentioned	Defined
Role	Default	Assigned persona
Result	Hit or miss	Consistently useful

The difference between these two columns is not talent. It is just habit.

Common Mistakes People Make with Claude

1. Treating Claude like Google.
Claude is not for searching. It is for reasoning, writing, explaining, and generating. Use it for what it is good at.

2. Sending one giant wall of text.
Unstructured prompts produce unstructured answers. Format your input so Claude can follow it clearly.

3. Not iterating smartly.
Sending the exact same prompt again after a bad response will not help. Change something — the format, the framing, the context — and it will respond differently.

4. Assuming Claude remembers previous chats.
By default, each conversation starts fresh. If your task depends on past context, include a brief summary at the start.

5. Asking for everything at once.
Big prompts with ten different goals rarely produce ten great outputs. Chunk your work. You will thank yourself later.

Best Practices at a Glance ✅

✅ Be specific about topic, format, tone, and length
✅ Assign a role when the task has a clear persona
✅ Give context before jumping into the question
✅ Use negative instructions to set boundaries
✅ Break large tasks into smaller, clean steps
✅ Save prompt templates that work well for you
❌ Do not be vague and expect great results
❌ Do not skip context and hope Claude figures it out
❌ Do not ask Claude to redo something without telling it what to change

Conclusion

Claude is a genuinely powerful tool — but only when you give it what it needs to perform. Most people leave a lot of quality on the table simply because of unclear or incomplete prompts.

You do not need to be a prompt engineering expert. You just need to be clear, specific, and intentional. Follow these 10 tips and you will get faster, sharper, and more accurate responses — with far fewer re-tries.

Less re-prompting. Less wasted tokens. More results. That is the goal.

If this helped you, check out more developer tips and guides on hamidrazadev.com 🚀

Share this with a fellow developer who is still sending one-liner prompts and wondering why the output is not great. They will appreciate you for it. 😊

DEV Community: Muhammad Hamid Raza

How to Use Claude Code with Ollama for Free (+ 5 Powerful Cloud Models You Need to Try)

What Is This Setup All About?

Why This Matters

Part 1: Installing Ollama

macOS / Linux

Windows

Verify Installation

Start Ollama Server (if not auto-started)

Part 2: Essential Ollama Commands

Pull (Download) a Model

Run a Model Interactively

List All Downloaded / Registered Models

Remove a Model

Check Running Models

Show Model Info

Stop a Running Model

Connect Your Ollama Account (Required for Cloud Models)

Launch Claude Code Directly from Ollama

Part 3: Installing Claude Code

Install Claude Code via npm

Verify Installation

Update Claude Code

Part 4: Connecting Claude Code to Ollama

Option A: Set Variables for the Current Session (Quick Test)

Option B: Permanent Setup (Recommended)

Verify the Variables Are Set

Part 5: Running Claude Code with Ollama Models

Method 1: Using the claude Command Directly

Method 2: Using ollama launch claude (The Clean Way)

Method 3: Test Your Project Setup

The 5 Free Ollama Cloud Models You Should Know

1. nemotron-3-super:cloud

2. gpt-oss:120b-cloud

3. gemma4:31b-cloud

4. qwen3-vl:235b-cloud

5. qwen3-coder:480b-cloud

Model Comparison Table

Claude Code Commands You Should Know

Best Tips for This Setup ✅

Common Mistakes People Make

1. Forgetting to start the Ollama server

2. Missing the ollama auth login step for cloud models

3. Setting the wrong ANTHROPIC_BASE_URL

4. Expecting identical Claude behavior

5. Running out of free cloud quota on heavy models

Putting It All Together: Full Setup Walkthrough

Conclusion

VS Code 1.120 Is Here: Agents Window, BYOK Token Tracking, and More

What Is VS Code 1.120?

Why This Release Matters

Key Features in VS Code 1.120

🪟 Agents Window — Now in Stable

💰 BYOK Token Usage — Finally Accurate

🧠 Thinking Effort for BYOK Reasoning Models

📦 Model Picker Organized by Provider

⚡ Terminal Output Compression (Preview)

🚦 Risk Assessment for Terminal Commands (Experimental)

📝 Markdown Preview for Diffs (Preview)

🔗 HTML id Support in Markdown

📊 Smart Select for Markdown Tables

🗂️ Plan Mode Improvements for Claude and Copilot CLI

Comparison: Before and After 1.120

Best Tips for Getting the Most Out of 1.120

Common Mistakes to Avoid

Wrapping Up

I Wrote 101 Developer Blogs. Here's What I Learned — And What I Was Really Trying to Teach You

The Journey: From 1 Blog to 101

What I Learned From Writing 101 Blogs

1. Consistency Beats Perfection Every Single Time

2. Simple Writing Is Harder Than Technical Writing

3. Developers Are Hungry for Relatable Content

4. Writing About Something Teaches You More Than Reading About It

5. Your Audience Is More Diverse Than You Think

6. The Title Is Half the Battle

7. Burnout Is Real, and Breaks Are Necessary

What I Was Actually Trying to Teach You

What I'm Still Learning

Why You Should Start Writing Too

Conclusion

Method 1: Using the `claude` Command Directly

Method 2: Using `ollama launch claude` (The Clean Way)

1. `nemotron-3-super:cloud`

2. `gpt-oss:120b-cloud`

3. `gemma4:31b-cloud`

4. `qwen3-vl:235b-cloud`

5. `qwen3-coder:480b-cloud`

2. Missing the `ollama auth login` step for cloud models

3. Setting the wrong `ANTHROPIC_BASE_URL`

🔗 HTML `id` Support in Markdown