DEV Community: Muhammad Hamid Raza

HTTP Status Codes Explained: The Complete Guide Every Developer Needs 🚀

Muhammad Hamid Raza — Fri, 19 Jun 2026 11:47:44 +0000

You open DevTools. You see a request fail. And there it is: a three-digit number staring back at you like it owes you money.

404. 500. 403. 301.

If you've ever stared at one of these and thought "okay... but what do I actually do now?" — you're not alone. Every developer, from total beginners to people who've shipped production apps for years, has Googled a status code at 2 AM.

Here's the good news: HTTP status codes aren't random. They're a simple, organized language your server uses to tell your browser (or your app, or your API client) exactly what happened. Once you understand the pattern, you'll never feel lost again. 💡

Let's break it down properly.

What Are HTTP Status Codes?

Every time your browser asks a server for something — a webpage, an image, an API response — the server replies with two things: the actual content (if any), and a status code.

Think of it like ordering food at a counter. You ask for a burger. The person behind the counter can say:

"Here you go!" ✅ (your order worked)
"We're out of buns, give us a sec" (something temporary happened)
"That's not on our menu" (you asked for something that doesn't exist)
"Our kitchen caught fire" (it's not your fault — something broke on their end)

HTTP status codes are exactly that, but for the web. They're three-digit numbers, and the first digit tells you the category:

1xx – Informational: "Hold on, I'm working on it"
2xx – Success: "Here's your stuff, all good"
3xx – Redirection: "What you want is actually over here"
4xx – Client Error: "You (the request) did something wrong"
5xx – Server Error: "I (the server) messed up"

That's it. That's the whole system. Everything else is just detail within those five buckets.

Why This Topic Matters

You can't debug what you don't understand. Status codes are usually the first clue you get when something breaks — before you even open a single line of code.

A 404 tells you to check your URL or routing. A 401 tells you it's an auth problem, not a server problem. A 500 tells you to look at your backend logs, not your frontend fetch call.

Knowing status codes well saves you time. Instead of randomly poking at your code, you immediately know where to look. That's the difference between a 5-minute fix and an hour of guessing. ⚡

It also matters for your career. Status codes come up in interviews, code reviews, API design discussions, and daily standups. Saying "the API returns a 422 when validation fails" instantly signals you know what you're talking about.

The Quick Reference Table

Here's a scannable list of the standard codes, grouped by class. Bookmark this section. 👀

1xx — Informational

Code	Name	Meaning
100	Continue	Server received the request headers; client should send the body
101	Switching Protocols	Server is switching protocols as requested (e.g., to WebSocket)
102	Processing	Server is still processing, response isn't ready yet
103	Early Hints	Server sends some headers early, before the final response

2xx — Success

Code	Name	Meaning
200	OK	The request succeeded
201	Created	A new resource was successfully created
202	Accepted	Request accepted, but processing isn't finished yet
204	No Content	Success, but there's nothing to send back
206	Partial Content	Server sent only part of the resource (used in streaming/downloads)

3xx — Redirection

Code	Name	Meaning
301	Moved Permanently	The resource has a new permanent URL
302	Found	Temporary redirect to a different URL
303	See Other	Redirect, typically after a form submission
304	Not Modified	The cached version is still valid, no need to re-download
307	Temporary Redirect	Like 302, but guarantees the method (GET/POST) stays the same
308	Permanent Redirect	Like 301, but guarantees the method stays the same

4xx — Client Error

Code	Name	Meaning
400	Bad Request	The request itself is malformed or invalid
401	Unauthorized	You're not authenticated — log in first
403	Forbidden	You're authenticated, but not allowed to access this
404	Not Found	The resource doesn't exist
405	Method Not Allowed	You used the wrong HTTP method (e.g., POST on a GET-only route)
408	Request Timeout	The server gave up waiting for the request
409	Conflict	The request conflicts with the current state (e.g., duplicate entry)
410	Gone	The resource existed once, but is permanently removed
413	Payload Too Large	You sent too much data
415	Unsupported Media Type	The format you sent isn't accepted
422	Unprocessable Entity	The request is well-formed, but the data fails validation
429	Too Many Requests	You're being rate-limited

5xx — Server Error

Code	Name	Meaning
500	Internal Server Error	Something broke on the server, and it's generic/unhandled
501	Not Implemented	The server doesn't support this functionality
502	Bad Gateway	A server acting as a proxy got an invalid response upstream
503	Service Unavailable	Server is overloaded or down for maintenance
504	Gateway Timeout	A proxy/gateway didn't get a response in time

There are a few more obscure ones (like 418 I'm a Teapot, which was originally an April Fools' joke in an RFC and is now sometimes used playfully), but the codes above cover the vast majority of what you'll see in real-world development.

Benefits of Understanding Status Codes

Faster debugging — A 403 tells you immediately it's a permissions issue, not a missing route. You skip straight to checking auth logic instead of guessing.
Better API design — When you build your own API, choosing the right code (like 201 instead of 200 after creating a resource) makes your API predictable and easier for other developers to consume.
Clearer communication with teammates — Saying "we're getting a 429 from their API" is faster and more precise than "it's just... not working."
Smarter error handling in code — Once you know the categories, you can write logic like "if status is in the 4xx range, show a user-facing error; if it's 5xx, retry or alert the team." This pattern shows up in almost every frontend app that talks to an API.
Confidence during interviews — Status codes are a common technical interview topic. Knowing the difference between 401 and 403, or 301 and 302, shows real hands-on experience.

Comparison: 4xx vs 5xx Errors

This distinction trips up a lot of beginners, so it's worth calling out clearly.

4xx (Client Error)

The problem is with the request.
Example: wrong URL, missing auth token, bad input data.
Fix: usually something the frontend or the API consumer needs to correct.

5xx (Server Error)

The problem is on the server's side.
Example: a crash in backend code, a database that's unreachable, a misconfigured server.
Fix: usually something the backend team needs to investigate in logs.

The simple rule: 4xx means "check your request," 5xx means "check the server." This one mental model alone will speed up a huge chunk of your debugging sessions.

Best Tips and Do's & Don'ts

✅ Do check the Network tab in DevTools before assuming your code is broken. The status code often tells you exactly where to look.

✅ Do use specific status codes in your own APIs (201 for creation, 204 for a successful delete with no body) instead of always returning 200.

✅ Do handle 4xx and 5xx differently in your error-handling logic. A 4xx might mean "show the user a message." A 5xx might mean "retry the request" or "alert the team."

❌ Don't treat every error the same way in your frontend code. A 401 should usually redirect to login. A 500 shouldn't.

❌ Don't ignore 429 Too Many Requests. If you're hitting rate limits, slamming the API harder won't help — you need backoff logic.

❌ Don't assume 404 always means "the page doesn't exist." Sometimes it's a typo in your route, a missing trailing slash, or a misconfigured server rule.

Common Mistakes People Make

Mixing up 401 and 403. Beginners often use these interchangeably. 401 means "I don't know who you are — please log in." 403 means "I know who you are, but you're not allowed in." Mixing them up confuses anyone debugging your API later.

Returning 200 for everything, even errors. Some APIs send a 200 OK even when something failed, with the actual error buried inside the JSON body. This breaks standard error-handling patterns and forces every consumer of your API to read documentation just to know if something worked. Stick to proper status codes — it saves everyone time.

Not handling redirects properly. Developers sometimes assume a 301 and 302 behave identically. They don't. A 301 tells browsers and search engines "update your bookmarks, this is permanent" — which affects caching and SEO. A 302 says "this is temporary, don't update anything permanently."

Panicking at any 4xx or 5xx without reading the code. Not all errors are equal. A 404 on an optional resource might be totally fine to ignore. A 500 on a critical checkout flow needs immediate attention. Context matters more than the fact that "something failed."

Wrapping Up

HTTP status codes aren't scary once you see the pattern: 1xx is "wait," 2xx is "success," 3xx is "look elsewhere," 4xx is "you made a mistake," and 5xx is "I made a mistake."

That's the whole mental model. Everything else — every specific code — is just a more detailed flavor of one of those five ideas.

Next time you see a status code pop up in your console, you won't panic. You'll know exactly where to start looking. ✅

If this helped clear things up, consider sharing it with another developer who's still Googling "what does 403 mean" at 1 AM. And if you want more practical, no-fluff developer content like this, you can find more posts at hamidrazadev.com. Drop a comment if you've got a status code horror story — we've all got one. 😊

NestJS: The Backend Framework That Makes Node.js Feel Grown-Up 🚀

Muhammad Hamid Raza — Wed, 17 Jun 2026 11:21:04 +0000

If you have ever tried to build a large Node.js backend and thought, "Why does this feel like I'm making it up as I go?" — you are not alone.

Express is powerful. Fastify is fast. But neither one tells you how to structure your project. You end up inventing your own patterns, copying folder structures from tutorials, and praying nothing breaks when the project grows.

That is exactly the problem NestJS was built to solve. And it is solving it really well.

So what is NestJS, why is everyone suddenly talking about it, and should you actually learn it? Let's find out.

What Is NestJS?

NestJS is a framework for building server-side applications using Node.js. It is written in TypeScript and uses a structured, opinionated architecture inspired by Angular.

Think of it this way:

Node.js is the engine.
Express is a car with no seats, no doors, and no steering wheel — powerful, but you have to build everything yourself.
NestJS is a fully assembled car. The seats, doors, engine, and GPS are already there. You just drive.

Under the hood, NestJS uses Express by default (and optionally Fastify). So you are not throwing away what you know — you are building on top of it with a proper structure.

NestJS uses TypeScript, decorators, modules, controllers, and services to organize your code in a clean, predictable way. If you have used Angular, this will feel very familiar. If you have not, it is still easy to pick up.

Why NestJS Is Getting So Much Attention

Backend development with Node.js has always had an awkward problem. Node.js gives you total freedom, and total freedom means total responsibility for every decision. File structure? Up to you. Dependency injection? Figure it out yourself. Modules? Sure, but how?

For small projects, this is fine. For production-grade apps with teams and deadlines? It becomes chaos.

NestJS fixes this by giving developers a clear, consistent way to build backends. It enforces good habits without being painful. And it does this while staying close to patterns that most JavaScript and TypeScript developers already understand.

Here is why developers are choosing it:

Teams can onboard faster because the folder structure is always familiar
TypeScript is a first-class citizen, not an afterthought
Testing is built into the framework, not bolted on
It works great for REST APIs, GraphQL, WebSockets, and microservices
The documentation is genuinely excellent

Benefits with Real-Life Examples

✅ Structured Architecture Out of the Box

You do not need to spend three hours deciding where to put your files. NestJS gives you modules, controllers, and services right away. A UsersModule with a UsersController and UsersService just makes sense — you can read it and know exactly what each piece does.

✅ TypeScript by Default

No setup, no config fights. You write TypeScript from day one. This means better autocomplete, fewer runtime surprises, and errors you catch before your users do.

✅ Built-In Dependency Injection

NestJS handles dependency injection automatically. You declare what a service needs, and NestJS provides it. No messy manual wiring. This also makes unit testing much cleaner because you can swap out dependencies easily.

✅ Great for REST, GraphQL, and Microservices

Whether you are building a REST API, a GraphQL server, or a message-queue-based microservice, NestJS supports all of it with first-party packages. You do not need to piece together five different libraries and hope they play nicely together.

✅ Powerful CLI

nest generate module users
nest generate controller users
nest generate service users

Three commands and your entire Users feature is scaffolded, connected, and ready for logic. This saves a meaningful amount of time on every project.

✅ Testing Is a First-Class Feature

NestJS generates test files automatically alongside your code. It integrates with Jest and provides utilities for mocking services, making unit and integration testing far less painful than it usually is in Node.js projects.

NestJS vs Plain Express: When Does It Actually Matter?

Situation	Plain Express	NestJS
Quick prototype or tiny API	✅ Perfect	Might be overkill
Medium to large production app	Gets messy fast	✅ Shines here
Team of 2+ developers	Coordination headaches	✅ Consistent structure
TypeScript-first project	Manual setup needed	✅ Built in
Microservices or event-driven	DIY everything	✅ First-party support
GraphQL	Third-party setup	✅ Official package

The honest answer: for small scripts and quick demos, Express is simpler. But the moment your app grows beyond a few routes, or when more than one developer is involved, NestJS becomes the smarter choice.

Core Concepts You Need to Know

You do not need to memorize everything at once. But these four building blocks are the heart of NestJS.

Modules

Modules are organizational units. Every NestJS app has at least one — the AppModule. You then create feature modules like UsersModule, AuthModule, and ProductsModule. Each module owns its own controllers and services.

Controllers

Controllers handle incoming HTTP requests and return responses. A UsersController handles routes like GET /users or POST /users. They are thin — they receive a request, pass it to a service, and return the result.

Services

Services contain the actual business logic. The controller talks to the service. The service talks to the database or external APIs. This separation keeps your code clean and testable.

Providers and Dependency Injection

Services are providers. NestJS injects them automatically where they are needed. If your UsersController needs the UsersService, you just declare it in the constructor and NestJS handles the rest.

Here is a quick example of what this looks like:

@Injectable()
export class UsersService {
  findAll() {
    return [{ id: 1, name: 'Hamid' }];
  }
}

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll() {
    return this.usersService.findAll();
  }
}

Clean. Readable. Predictable. 💡

Best Tips for Getting Started

Start with the official CLI. Install it globally and let it scaffold your project:

npm install -g @nestjs/cli
nest new my-project

Learn modules before anything else. The module system is the foundation of everything. Once it clicks, the rest makes sense quickly.

Use the official documentation. The NestJS docs are some of the best in the Node.js ecosystem. Do not skip them.

Do not force Angular patterns if you do not know Angular. NestJS is inspired by Angular, but you do not need to understand Angular to use it well.

Add validation early. Use the class-validator and class-transformer packages with NestJS pipes. They work seamlessly together and save you from a lot of manual validation code.

Write tests as you go. NestJS generates test files automatically. Use them. Future you will be grateful.

Common Mistakes Beginners Make

Putting logic inside controllers

Controllers should be thin. They receive a request and pass it along. If you are writing database queries or complex business rules inside a controller, move that logic to a service.

Ignoring the module system

Beginners often put everything into AppModule. This works at first and becomes a nightmare by week three. Create a module for each feature from the beginning.

Skipping TypeScript features

NestJS and TypeScript are deeply integrated. Using any everywhere or ignoring types defeats the purpose. Lean into TypeScript — it will actually help you.

Not using pipes for validation

Without validation pipes, invalid request data goes straight into your logic. Use ValidationPipe globally. It is one line of code and it prevents a lot of bugs:

app.useGlobalPipes(new ValidationPipe());

Trying to learn everything at once

NestJS has a lot of features. GraphQL, WebSockets, microservices, guards, interceptors, pipes, middleware. Do not try to learn all of it on day one. Start with modules, controllers, and services. Everything else comes naturally after that.

Is NestJS Worth Learning in 2025?

Absolutely. ⚡

NestJS has gone from an interesting framework to a mainstream choice for serious Node.js development. It is used by teams at companies large and small, across industries. The ecosystem is active, the documentation is strong, and the community keeps growing.

If you are building backends with Node.js and you want your code to be clean, scalable, and easy to work in as a team — NestJS is one of the best investments of your learning time right now.

You do not have to abandon what you already know. You just pick up better habits and better tools. And that is a pretty good deal.

Conclusion

NestJS is not just another framework. It is an answer to a real problem that Node.js developers have been dealing with for years: how do you build large, maintainable backends without inventing your own architecture every single time?

The answer NestJS gives is clear, practical, and well-executed. Modules keep your code organized. Controllers keep routing clean. Services keep business logic separate. TypeScript catches mistakes early. And the CLI keeps you moving fast.

If you are a beginner, NestJS gives you good habits to build on. If you are an experienced developer, it gives you structure that scales. Either way, it is worth your time.

Start small. Build one module. Write one service. Make one API endpoint. The framework will do the rest of the heavy lifting.

Enjoyed this post? Find more practical developer content at *hamidrazadev.com** — free tools, tutorials, and guides built for developers who like to keep things real.*

If this helped you, share it with a teammate or friend who is figuring out their backend stack. It might save them a few hours of confusion. 😊

Why Claude Fable 5 and Mythos 5 Were Banned: The Full Story Explained

Muhammad Hamid Raza — Tue, 16 Jun 2026 04:19:58 +0000

The AI world just got its most dramatic plot twist of 2026. Anthropic launched two groundbreaking models. The internet celebrated. And then, just three days later, they were gone — pulled from every user on the planet.

If you opened Claude last weekend and found Fable 5 missing, you were not alone. The disable was global, sudden, and still being disputed. What exactly happened? And why should any developer care?

Let's break it all down. 👀

What Are Claude Fable 5 and Mythos 5?

On June 9, 2026, Anthropic released two new AI models that sat in an entirely new tier above its flagship Opus line.

Claude Fable 5 was the publicly available version — available to all Claude Pro, Max, Team, and Enterprise users at no extra cost during a launch window. It was described as state-of-the-art on nearly all tested benchmarks, with exceptional performance in software engineering, knowledge work, vision, and scientific research. Its defining trait: the longer and more complex the task, the wider the gap between Fable 5 and everything that came before it. It could autonomously run agentic coding tasks for days with minimal human intervention.

Claude Mythos 5 was the same underlying model, but with some of its safety classifiers lifted. It was never public — only available to a small group of vetted cyberdefenders, critical infrastructure providers, and select biology researchers through Anthropic's restricted Project Glasswing program.

Together, they formed what Anthropic called the "Mythos class" — a new tier sitting above Opus. The name itself is intentional: Fable comes from the Latin fabula (related to the Greek mythos), drawing a clear line between the public-facing model and the less-restricted version.

Both models shared a 1 million token context window, support for up to 128k output tokens per request, and were priced at $10 per million input tokens and $50 per million output tokens — twice the Opus 4.8 rate.

Why This Topic Matters

This is not just another "new AI model" story. It touches something much more important for every developer, startup, enterprise team, and user anywhere outside the United States.

Within 72 hours of launch, the US government stepped in and ordered access cut off — not just in specific countries, but for every user on Earth. That is unprecedented. And the reason given — a potential jailbreak — is being actively disputed by Anthropic itself.

If you build on Claude, depend on its API, or care about where AI regulation is heading, this story affects you directly. It raises questions that no one has clean answers to yet:

Can a government pull a deployed commercial AI model without full explanation?
Who gets to decide what an AI model is "too dangerous" to deploy?
What happens to the hundreds of millions of users who depended on it?

This is the reality of frontier AI in 2026. The story is still unfolding.

What Made Fable 5 and Mythos 5 Powerful

Here is why these were not ordinary model releases — and why their capabilities became the heart of the controversy.

Autonomous, long-running tasks. Fable 5 could handle multi-day agentic workflows — things like reviewing an entire codebase, running a data pipeline, or executing complex software projects — without needing a human to check in every few steps. This was a major leap over Opus.
Exceptional cybersecurity capabilities. Mythos 5 was described by Anthropic as having "the strongest cybersecurity capabilities of any model in the world." It was particularly effective at identifying software vulnerabilities in complex, legacy systems that had been sitting unpatched for years. For defenders, that is incredibly useful.
Scientific breakthroughs. Anthropic's launch post mentioned that these models had contributed to genuine scientific output, including work on AAV (adeno-associated virus) candidates developed by Dyno Therapeutics — a striking example of AI directly assisting biological research.
Safety scaffolding built in. Sensitive topics like cybersecurity exploits, biology, chemistry, and model distillation triggered an automatic fallback to Claude Opus 4.8. Anthropic said these safeguards activated in fewer than 5% of sessions.
Massive context and output. With a 1 million token context window, Fable 5 could ingest entire codebases, lengthy legal documents, or vast research papers and reason over them in one shot.

Fable 5 vs Mythos 5: What Was the Difference?

They were built from the same foundation. The difference was in how much of the safety layer was kept on.

Feature	Claude Fable 5	Claude Mythos 5
Availability	General public, all paid plans	Invite-only (Project Glasswing)
Safety classifiers	Full safeguard layer active	Some safeguards lifted for vetted users
Who it served	Developers, enterprises, general users	Cyberdefenders, critical infrastructure, researchers
Cybersecurity scope	Broad tasks with automatic fallback	Higher-risk analysis for trusted organizations
Context window	1M tokens	1M tokens
Pricing	$10 / $50 per million tokens	$10 / $50 per million tokens
Data retention	30-day mandatory	30-day mandatory

In short: same brain, different safety gear. Fable 5 had its helmet on for the public. Mythos 5 had fewer restrictions for a trusted few.

What Happened: The Ban Explained Step by Step

Here is a clean timeline of how this unfolded.

June 9, 2026 — Launch Day
Anthropic releases Claude Fable 5 publicly and Claude Mythos 5 to Project Glasswing partners. Both are available immediately. Free access for Pro, Max, Team, and Enterprise plans announced through June 22.

June 9–11 — Early Adoption
Developers test it, benchmarks circulate, the community reacts positively. Fable 5 scores roughly 80% on SWE-Bench Pro in independent testing. Reviews highlight the long-horizon agentic performance.

June 12, 2026 — The Directive Arrives (5:21 PM ET)
The US government issues an export control directive, ordering Anthropic to immediately suspend access to Fable 5 and Mythos 5 for any foreign national — whether inside or outside the US — including Anthropic's own foreign national employees.

The directive cites national security authorities. The letter does not provide specific technical details.

June 12 Evening — Global Shutdown
Because verifying the nationality of every user globally is practically impossible, Anthropic decides that selective compliance cannot work. It disables both models for all customers worldwide.

"The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance," Anthropic stated. "Access to all other Anthropic models will not be affected."

June 13–14 — Anthropic Pushes Back
Anthropic publishes a detailed rebuttal. It says the government disclosed only a "narrow, non-universal jailbreak" — essentially a technique involving asking the model to read a codebase and fix any software flaws. Anthropic reviewed the demonstration and found that the vulnerabilities identified were minor, previously known, and discoverable by other publicly available models, including OpenAI's GPT-5.5.

Anthropic's technical team travels to Washington for meetings with White House officials.

June 15–16 — Still Under Review
Talks continue. Access has not been restored. Anthropic is maintaining compliance while arguing that the standard being applied would "essentially halt all new model deployments for all frontier model providers" if applied broadly across the industry.

What Anthropic Actually Said

Anthropic's official statement is worth reading carefully, because it explains not just what happened — but how the company thinks about safety.

The key points from Anthropic:

On the jailbreak itself: The government shared verbal evidence of a narrow, non-universal jailbreak. Anthropic reviewed what it believes was the basis of the directive, validated that the demonstrated capability was already available in other public models, and found that the technique identified only minor, previously known vulnerabilities.

On safeguards: Fable 5 went through thousands of hours of red-teaming with the US government, UK AISI, multiple third-party organizations, and internal teams before launch. No tester found a universal jailbreak — one that could broadly bypass the model's defenses.

On the standard being set: Anthropic warned that perfect jailbreak resistance is not possible for any model provider. Every deployed model in the industry is vulnerable to narrow jailbreaks in specific circumstances. If a narrow jailbreak is grounds for full recall, no frontier model should be deployed anywhere.

On compliance: Despite disagreeing, Anthropic is complying with the legal directive. "We believe this is a misunderstanding and are working to restore access as soon as possible."

Tips for Developers Right Now ⚡

If you had workflows or products relying on Fable 5 or Mythos 5, here is what you can do while access is suspended.

✅ Fallback to Claude Opus 4.8. For most development tasks, Opus 4.8 (released May 28, 2026) is still excellent. It is the next-most-capable model and remains fully available.

✅ Check Anthropic's status page and official blog. Updates on restoration will come from anthropic.com. Do not rely on social media rumors for this.

✅ Do not rebuild your entire architecture. This is a temporary disruption. Anthropic is actively working to restore access and is in direct talks with the White House. Migrating to a completely different provider right now may create more problems than it solves.

✅ Review your data retention understanding. Fable 5 and Mythos 5 required mandatory 30-day data retention. If your project had compliance questions around that, now is a good time to re-read the policy while waiting for access to return.

✅ Follow the story. This situation is evolving quickly. The outcome of Anthropic's talks with the Trump administration will likely shape how all frontier AI models are regulated going forward.

Common Mistakes and Misconceptions Around This Ban

Mistake 1: "Fable 5 was hacked or compromised."
No. The model itself was not hacked. The US government claimed a jailbreak technique was found that could bypass some of its safety filters. Anthropic disputes the severity of this finding. The model's architecture is intact.

Mistake 2: "This only affects users outside the US."
The export control directive targeted foreign nationals — but because Anthropic could not filter users by nationality in real time, it disabled access globally, including for US citizens. Everyone lost access.

Mistake 3: "This is Anthropic's decision."
Anthropic is complying with a legal government directive. The company actively disagrees with the move and is in discussions to reverse it. This was not a voluntary product recall.

Mistake 4: "Mythos 5 was a public model."
Mythos 5 was never publicly available. It was restricted to Project Glasswing partners — a small group of vetted organizations in cybersecurity, critical infrastructure, and biology research.

Mistake 5: "All Claude models are now unavailable."
Only Fable 5 and Mythos 5 are suspended. All other Claude models — including Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5, and others — remain fully available.

Mistake 6: "This proves AI models are dangerous and should be stopped."
The demonstrated jailbreak found minor, previously known vulnerabilities that other public models can also discover. The debate is about regulatory standards and how to define acceptable risk — not about Fable 5 being uniquely dangerous.

What This Means for the Broader AI World

This is the first time a deployed commercial AI model has been pulled globally by government order within days of launch. That alone makes it a defining moment.

The precedent it sets is still being negotiated. Anthropic has publicly argued that if a narrow jailbreak — one that reveals minor vulnerabilities already discoverable by other public models — is sufficient cause for a full global recall, it would make future frontier model deployments nearly impossible.

The Trump administration had already designated Anthropic a "supply-chain risk to national security" in March 2026 (a designation Anthropic contested). This action appears to be a continuation of that tension.

How this gets resolved will send a strong signal to every AI lab, every government, and every developer who builds on top of these models.

Conclusion

Claude Fable 5 and Mythos 5 were arguably the most capable AI models ever made publicly available. They lasted three days.

The story is not really about whether a jailbreak exists — narrow jailbreaks exist for every model in the industry. The story is about who gets to define the line between "safe enough to deploy" and "too dangerous to ship," and what process they follow to make that call.

Anthropic is disputing the ruling, complying with the law, and working to restore access. The broader question of how governments should regulate frontier AI is now front and center — and every developer who builds on these tools has a stake in how it resolves.

Stay updated, keep an eye on anthropic.com, and in the meantime, Claude Opus 4.8 has your back. 🚀

If this breakdown helped you understand what happened, share it with your team or community — a lot of people are confused about this story. And for more developer-focused content, head over to hamidrazadev.com for articles on AI, frontend development, and the tools shaping how we build.

MongoDB Compass: The Complete Zero-to-Hero Guide for Developers 🧭

Muhammad Hamid Raza — Mon, 15 Jun 2026 09:02:06 +0000

So you've heard about MongoDB. Maybe you've even used it. But every time you open the terminal and start typing db.collection.find({}), something feels off. You're not sure if your query is right. You can't see the shape of your data. And debugging? That's just staring at walls of JSON and hoping for the best.

There's a better way.

MongoDB Compass is the free, official GUI tool for MongoDB — and it changes everything about how you explore, query, and manage your database. Whether you're a complete beginner or an experienced developer who just never got around to using it, this guide covers everything you need to know from absolute zero to confidently using every major feature.

Ready to stop guessing and start seeing your data? Let's go. 🚀

What Is MongoDB Compass?

Think of MongoDB like a massive warehouse full of boxes (your documents). The terminal is like walking through that warehouse in the dark with a flashlight — you can find things, but it's slow and uncomfortable.

MongoDB Compass is the warehouse with the lights on.

It's a free, graphical desktop application made by MongoDB itself. Instead of typing raw commands to interact with your database, you click buttons, fill in fields, and see your data displayed visually in a clean interface.

It works with:

MongoDB Atlas (the cloud version)
Local MongoDB running on your machine
MongoDB Enterprise deployments

And the best part? You don't need to write a single command to get started. Though if you want to write queries, Compass fully supports that too — it just shows you the results nicely.

Why MongoDB Compass Matters

Before tools like Compass existed, working with a database meant memorizing syntax, running queries blind, and hoping your output was correct.

Here's why Compass is genuinely important:

For beginners — it removes the fear of databases. You can explore data visually without knowing the full MongoDB query language on day one.

For intermediate developers — it speeds up debugging. You can inspect a collection, understand its structure, and build a complex aggregation pipeline visually in minutes instead of hours.

For teams — it makes communication easier. When everyone can see the data structure, there's less confusion, fewer bugs, and faster development.

For performance — Compass shows you exactly why a query is slow, which indexes are being used, and what you need to fix.

It's one of those tools that once you start using, you wonder how you ever survived without it.

How to Download and Install MongoDB Compass

Let's start from the very beginning. 👇

Step 1 — Download Compass

Go to the official MongoDB website:

https://www.mongodb.com/try/download/compass

Choose your operating system (Windows, macOS, or Linux) and download the installer.

Step 2 — Install It

Windows: Run the .exe installer and follow the prompts.
macOS: Open the .dmg file, drag Compass into your Applications folder.
Linux: Follow the .deb or .rpm installation for your distro.

The app is lightweight and installs quickly.

Step 3 — Open Compass

Launch it like any other desktop app. You'll see the connection screen.

That's it for installation. No complicated setup, no environment variables, no config files. Just install and open. ✅

How to Connect to Your MongoDB Database

Once Compass is open, the first thing you'll do is connect to a database. You'll see a connection screen with a field for a connection string.

Option A — Connect to MongoDB Atlas (Cloud)

Go to your MongoDB Atlas account.
Click Connect on your cluster.
Choose MongoDB Compass from the options.
Copy the connection string. It looks something like this:

mongodb+srv://yourusername:<password>@cluster0.abcde.mongodb.net/

Replace <password> with your actual password.
Paste it into Compass and click Connect.

Option B — Connect to a Local MongoDB Instance

If you have MongoDB running locally, your connection string is simply:

mongodb://localhost:27017

Paste that in and hit Connect. That's all.

Once connected, you'll see your databases listed in the left sidebar. Click any database and you'll see its collections. Click a collection and your data appears — instantly, visually, no command needed.

This is where the fun begins. 😊

Exploring Your Data — The Documents Tab

The Documents tab is where you spend most of your time in Compass. It shows all the documents inside a collection.

What you see:

Every document is displayed in a clean, expandable card format. You can see all the fields and values at a glance. Nested objects and arrays are collapsible, so even complex data structures are easy to read.

What you can do:

Add a Document — Click the "Add Data" button and paste in a JSON object or use the built-in form. No insertOne() command needed.

Edit a Document — Hover over any document and click the pencil icon. You can modify any field value right in the UI. Click Update and it saves immediately.

Delete a Document — Click the trash icon next to a document. You'll get a confirmation prompt before anything is removed.

Copy a Document — Want to duplicate an entry? Click the copy icon and paste it into the Add Data form.

This is beginner-friendly but also genuinely useful for experienced developers doing quick data fixes without spinning up a script.

Querying Made Easy — The Query Bar

The query bar at the top of the Documents view is where you filter your data. You can search and filter your collection without leaving the screen.

Basic Filtering

Click in the Filter field and type a MongoDB query object:

{ "status": "active" }

Hit Find and Compass shows only documents where status is "active". Simple.

Want documents where age is greater than 25?

{ "age": { "$gt": 25 } }

Want to match two conditions at once?

{ "status": "active", "role": "admin" }

These are the same queries you'd type in the terminal — but here you can see the results live, tweak the filter, and instantly see what changes.

Project (Select Fields)

Don't need every field? Use the Project field to specify which ones to show:

{ "name": 1, "email": 1, "_id": 0 }

This returns only the name and email fields, hiding everything else.

Sort

The Sort field lets you order results:

{ "createdAt": -1 }

This sorts your documents by creation date, newest first.

Skip and Limit

These are useful for pagination. Skip the first N results. Limit the total number returned.

For example: Skip 10, Limit 10 — that gives you page 2 of your data.

💡 Natural Language Querying

One of the newer features in Compass is the ability to generate queries using natural language. Instead of writing { "age": { "$gt": 25 } }, you can type:

"Show me all users older than 25 who are active"

And Compass translates it into the correct query for you. This is a huge help when you're not sure about the exact MongoDB syntax.

Schema Analysis — Understanding Your Data Shape

The Schema tab is one of the most underused but most powerful features in Compass.

Here's the problem it solves: in a NoSQL database like MongoDB, different documents in the same collection can have different fields. One user document might have an address field. Another might not. How do you know what your data actually looks like?

The Schema tab tells you.

Compass samples your collection (typically 1,000 documents) and analyzes the structure. It then shows you:

Which fields exist and how often they appear
What data types are used (string, number, date, boolean, etc.)
Value distributions — for example, a bar chart showing the most common values in a status field
Date ranges for date fields
Min/max values for number fields

Real Example

Imagine you inherited a project with a users collection and no documentation. You open the Schema tab and immediately see:

95% of documents have an email field — but 5% don't. That's a bug.
The createdAt field is stored as a string in some documents and a Date in others. That's inconsistent data.
The role field has three common values: "admin", "user", and "guest".

In five seconds, you understand the collection better than someone who's been writing queries against it for weeks. That's the power of schema analysis.

The Aggregation Pipeline Builder

This is the feature that turns people into Compass fans for life.

Aggregation pipelines are MongoDB's way of processing and transforming data across multiple stages. They're powerful, but writing them manually in the terminal is painful — especially for complex pipelines with 5 or 6 stages.

Compass has a visual aggregation pipeline builder that makes this approachable for everyone.

How It Works

When you open the Aggregations tab, you see a canvas where you can:

Add a stage by clicking the + button and choosing from a dropdown (e.g., $match, $group, $sort, $project, $lookup, and more)
Fill in the stage using a form or by writing the JSON directly
See a live preview of the output at each stage as you go
Reorder stages by dragging them
Export the pipeline as JavaScript code you can paste into your application

A Simple Example

Let's say you have an orders collection and want to find the total revenue per product category, sorted highest to lowest.

Your pipeline would be:

Stage 1 — $group

{
  "_id": "$category",
  "totalRevenue": { "$sum": "$price" }
}

Stage 2 — $sort

{ "totalRevenue": -1 }

In the terminal, you'd write this all at once and run it blind. In Compass, you add Stage 1, immediately see a preview of the grouped results, then add Stage 2 and watch the order change in real time.

The aggregation builder is ideal for:

Calculating totals, averages, and counts
Joining collections with $lookup
Reshaping documents with $project
Filtering and grouping data for reporting
Extracting business insights like revenue by region, user churn rates, and more

Indexes — Speed Up Your Queries

An index in MongoDB is like an index at the back of a book. Instead of reading every page to find a topic, you look at the index and jump straight to the right page.

Without indexes, MongoDB scans every document in a collection to find matches — called a collection scan. This is slow when you have millions of documents.

With the right indexes, MongoDB jumps straight to the matching documents — called an index scan. Much faster.

Managing Indexes in Compass

The Indexes tab shows you all existing indexes on a collection. For each index you can see:

Name of the index
Fields it covers
Type (single field, compound, text, etc.)
Usage stats — how many times the index was used recently
Size on disk

Creating a New Index

Click Create Index, choose the field(s) you want to index, pick the type, and hit Create. Done.

Dropping an Index

If an index is large, slow to maintain, and never used (you can see this in the usage stats), click the trash icon and remove it. Dropping unnecessary indexes actually improves write performance.

A simple rule: index the fields you query and sort on the most.

Performance Monitoring — The Explain Plan

This is the debugging superpower you didn't know you needed.

Every time MongoDB runs a query, it generates an Explain Plan — a detailed breakdown of exactly how the query was executed: what indexes were used, how many documents were scanned, and how long each step took.

Reading an Explain Plan in the terminal looks like a wall of JSON. Reading it in Compass looks like a visual flowchart.

How to Use the Explain Plan

Go to the Documents tab and enter your query in the filter bar.
Click the Explain button instead of Find.
Compass shows you a visual tree of the query execution.

You'll see at a glance:

✅ IXSCAN — the query used an index (fast)
⚠️ COLLSCAN — the query scanned the entire collection (slow)
How many documents were examined vs how many were returned
Total execution time in milliseconds

If you see a COLLSCAN on a field you query constantly, that's your signal to add an index.

Real-Time Server Metrics

The Performance tab shows live charts of:

Operations per second (reads, writes, commands)
Query execution times
Document read/write rates
Network and memory usage

It's like a health monitor for your database. When something feels slow, you open this tab and spot the spike immediately.

Compass vs The Terminal: Which Should You Use?

This is a fair question. Here's an honest comparison:

Task	Terminal	Compass
Quick one-line queries	✅ Fast	⚡ Also easy
Exploring unfamiliar data	😬 Painful	✅ Perfect
Building aggregation pipelines	❌ Hard to visualize	✅ Visual & live preview
Schema analysis	❌ Manual work	✅ Automatic
Debugging slow queries	❌ Raw JSON output	✅ Visual Explain Plan
Scripting & automation	✅ Terminal wins	❌ Not for scripting
Sharing data with team	❌ Hard to show	✅ Easy to screenshot

The honest answer: They complement each other. Use Compass for exploration, debugging, and building complex pipelines. Use the terminal (or your app's driver) for automation and scripting.

Don't think of it as either/or. Most experienced MongoDB developers use both.

Best Tips for Using MongoDB Compass 💡

✅ Use Schema Analysis before writing queries. When working with a new collection, always check the Schema tab first. Knowing the actual field names, types, and distributions saves you from writing queries against fields that don't exist the way you think they do.

✅ Build aggregations in Compass, then export to code. Use the visual builder to design your pipeline, confirm it works with the live preview, and then export it as JavaScript to paste into your application.

✅ Check the Explain Plan before going to production. Any query that will run frequently in your app deserves a quick Explain check in Compass. Make sure it's using an index.

✅ Use the query bar for quick data fixes. Instead of writing a full script to update a few documents, filter them in Compass and edit them directly. It's faster for one-off fixes.

✅ Monitor index usage stats. If an index hasn't been used in weeks, it's dead weight. Remove it. Unused indexes slow down write operations.

✅ Save your favorite connections. Compass lets you save connection strings with nicknames like "Atlas Production" or "Local Dev". Set these up once and stop re-entering credentials every session.

Common Mistakes People Make

❌ Connecting to Production Without Thinking

Compass makes it easy to connect to any database — including production. One wrong edit or delete on live data can cause real damage. Always double-check which environment you're connected to before making changes.

Fix: Color-code or clearly label your connections. Treat production connections with extra caution.

❌ Ignoring the Schema Tab

Most people open Compass, go straight to Documents, and start filtering. They skip the Schema tab entirely. Then they spend 30 minutes writing queries against data they don't fully understand.

Fix: On any new collection, open Schema first. Spend two minutes there. You'll save hours later.

❌ Building Aggregations in Code First

Some developers write complex aggregation pipelines directly in their application code, run them, get wrong results, and spend ages debugging. Then someone tells them about the Compass aggregation builder.

Fix: Always prototype aggregations in Compass. Confirm the output is correct at each stage, then export to code.

❌ Forgetting to Sample Size Limits

The Schema tab analyzes a sample of documents (default 1,000). If your collection has millions of records with edge cases in rare documents, the schema analysis might miss them.

Fix: Increase the sample size in Compass settings, or add a filter before running schema analysis to target specific segments of your data.

❌ Not Using the Explain Plan at All

Many developers write a query, see it returns the right data, and move on. They never check how it ran. Then on production with 2 million documents, the same query takes 8 seconds.

Fix: Any query you plan to use in an app should be checked with Explain. It takes 10 seconds and can save you from a major performance crisis later.

Conclusion

MongoDB Compass is one of those tools that seems like a nice-to-have until you actually use it — and then it becomes non-negotiable.

Here's what you now know how to do:

Install and connect Compass to any MongoDB instance
Explore documents visually and perform CRUD operations without writing commands
Query your data with the filter bar, sorting, projecting, and even natural language
Analyze your schema to understand data shape, types, and inconsistencies
Build aggregation pipelines visually with live stage previews
Manage indexes and understand which ones are helping or hurting performance
Debug slow queries using the Explain Plan
Monitor your database in real time with server metrics

You're not just reading about MongoDB anymore. You have a full visual interface to actually work with it — and that changes everything.

Start with your own project, open Compass, and explore a collection you haven't looked at closely before. You might be surprised what you find hiding in your data.

For more practical guides like this one, check out hamidrazadev.com — where I write about frontend development, databases, AI tools, and the kind of stuff no one explains clearly enough.

If this guide helped you, share it with a developer friend who's still fighting the terminal 😄. Drop a comment below if you have questions — I read them all.

Chrome's Latest Update Brings 4 Handy New Features — Here's What Changed 🚀

Muhammad Hamid Raza — Fri, 12 Jun 2026 09:34:45 +0000

Ever see the little "Your Chrome has been updated" message, click it away without reading, and go straight back to your 47 open tabs? 😅 Same here, most of the time.

But this update is actually worth a second look — especially if you're a developer (or just a human) who lives inside a browser all day: tabs for docs, tabs for Stack Overflow, tabs you swear you'll "read later."

Chrome just rolled out four small but genuinely useful features: PDF annotations and signing, smarter autofill powered by Google Wallet, a built-in split view, and tab groups that follow you across devices.

So what do they actually do, why should you care, and how do you use them without digging through settings for ten minutes? Let's go through it. 👀

What's New in This Chrome Update?

Think of this update less like a big redesign and more like Chrome quietly handing you a few tools that used to need separate apps or extensions.

In simple words, here's what changed:

PDF Annotations – draw, highlight, and sign PDFs right inside Chrome.
Autofill with Google Wallet – Chrome can now fill in loyalty cards, vehicle info, and flight details, not just passwords and addresses.
Split View – view two tabs side by side in the same browser window.
Tab Groups Sync – your tab groups follow you across your laptop, phone, and any signed-in device.

None of these need a tech background to use. They're built for everyday browsing — but they happen to save a lot of time for developers too.

Why This Update Matters (Especially for Developers)

If you're a frontend dev, a student, or just someone who treats Chrome like an operating system, small friction adds up fast.

Signing a PDF used to mean downloading it, opening another app, signing, then re-uploading. Now it's done right in the tab.

Comparing two things — like your code and a tutorial — used to mean snapping windows around or squinting at tiny tab titles. Split View fixes that in one drag.

And losing your carefully organized tab groups every time you switch from desktop to mobile? That was just annoying. Now they sync automatically.

Fewer tools, fewer tabs about tabs, a little more focus. 💡

Benefits With Real-Life Examples

1. PDF Annotations & Signing

No more "print, sign, scan, email" loop.

Example: You get an internship offer letter as a PDF. Instead of printing it (who even has a printer anymore?), open it in Chrome, click Annotations, pick the pen or highlighter, draw your signature, and hit Save. Done in under a minute.

Good to know: if a signature line is small, zoom in on the PDF first — it makes drawing your signature far more accurate.

2. Autofill With Google Wallet

This goes beyond the usual "remember my password" autofill.

Example: Booking a flight? Chrome can now autofill your confirmation number and travel dates. Renewing car insurance or booking parking online? It can pull your vehicle info. Got a coffee shop loyalty card saved? Chrome can fill that in too, so you're not digging through a physical wallet.

To turn it on: go to Settings → Autofill and passwords → Enhanced Autofill, and switch it on.

3. Split View

This one is great for anyone who multitasks — so, basically everyone.

Example: You're following a tutorial in one tab while writing code in another. Instead of Alt-Tabbing every few seconds, drag one tab to the left or right edge of the browser window — Chrome snaps it into a side-by-side view. You can also right-click a link and choose Open Link in Split View.

4. Tab Groups That Sync Across Devices

If you've ever lost a perfectly organized "Research" tab group after restarting your laptop, this one's for you.

Example: You group all your job-hunting tabs on your laptop, then open Chrome on your phone later — and the same tab group is sitting right there. Just sign in to Chrome and create a tab group; it saves to your Google Account automatically. On mobile, you'll find synced groups in your open tabs view, and on desktop, in the tab group icon on your bookmarks bar or Chrome menu.

Old Way vs New Way

Task	Before This Update	After This Update
Signing a PDF	Print → sign → scan → re-upload	Open PDF → Annotations → sign → Save
Filling travel / loyalty info	Typing it manually every time	Autofilled via Google Wallet
Comparing two pages	Switching tabs back and forth	Split View, side by side
Organizing tabs across devices	Rebuilding groups on each device	Tab groups sync automatically

It's not a dramatic overhaul — just fewer repetitive steps in things you probably already do every week. ✅

Best Tips & Do's and Don'ts

Do:

Zoom in before signing a PDF — it makes your signature look way less like a seismograph reading. 😄
Turn on Enhanced Autofill if you regularly fill travel, insurance, or loyalty forms.
Try dragging a tab slowly toward the edge the first time, so you get a feel for where Split View kicks in.
Sign in to Chrome with your Google Account if you want tab groups to follow you across devices.

Don't:

Don't expect autofill to fill every field — it works best with information it recognizes, like flight or vehicle details.
Don't drag tabs only "close" to the edge expecting Split View — Chrome needs the tab to actually reach the window edge.
Don't forget tab groups only sync if you're signed in. Browsing as a guest? They'll stay local to that device.

Common Mistakes People Make

Mistake 1: Skipping the update notification entirely
Most people close it instantly (zero judgment, we've all done it). But that's exactly how useful features sit unnoticed for months.

Mistake 2: Signing a PDF without zooming in first
A tiny signature line plus default zoom equals a signature that looks nothing like yours. Zoom in, sign, then zoom back out.

Mistake 3: Expecting Split View to behave like two separate windows
Split View keeps both pages inside the same tab. If you want two fully separate windows, that's a different (older) Chrome feature.

Mistake 4: Not signing in, then wondering why tab groups "disappeared"
If you're not signed into your Google Account, tab groups stay local to that device. Sign in first, then build your groups.

Final Thoughts

Chrome's latest update isn't flashy, but it quietly removes a bunch of small annoyances: signing PDFs, filling repetitive forms, comparing tabs, and keeping your browser organized across devices.

If you only try one thing from this post, make it Split View — once you use it for a tutorial-and-code workflow, it's hard to go back. 🚀

If this helped you spot a feature you didn't know about, share it with a friend who still prints PDFs just to sign them (we all know one 😄). And if you'd like more practical dev and browser tips, check out hamidrazadev.com — and drop a comment if you've found other hidden Chrome features worth knowing about!

VS Code 1.124: Autopilot Is Now On by Default — Here's Everything That Changed 🚀

Muhammad Hamid Raza — Wed, 10 Jun 2026 12:28:55 +0000

You open VS Code, start an agent session, and then sit there waiting for it to fully load before you can even think about the next task. Meanwhile, your coffee gets cold and your focus breaks.

VS Code 1.124, released on June 10, 2026, is designed to fix exactly that. This update sharpens the AI agent experience in ways that actually matter — smarter task completion, background sessions, full session recovery, and a browser history feature that should have been there from day one.

If you work with AI agents inside VS Code, this release deserves more than a glance. Let's walk through every meaningful change. 👀

What Is VS Code 1.124?

VS Code 1.124 is the June 2026 release of Visual Studio Code — the free, open-source code editor from Microsoft that millions of developers use daily.

This version is heavily focused on the Agents window, VS Code's dedicated interface for running and managing AI coding sessions. Think of it like a control room for your AI assistant — you can start sessions, switch between tasks, review changes, and monitor what the agent is doing.

Version 1.124 makes that control room faster, smarter, and far less annoying to navigate.

Why This Update Matters

AI agents in VS Code aren't experimental anymore. Developers are using them for real work every day — writing code, debugging, refactoring, running terminal commands, and browsing documentation.

The friction was still real, though. You had to wait for a session to load before composing the next one. Switching between sessions meant clicking around. And it was genuinely hard to tell whether the agent had actually finished its job or just… stopped.

VS Code 1.124 targets all of this directly. Less waiting. Better navigation. Smarter judgment. This update respects your time and your workflow.

What's New in VS Code 1.124

1. Autopilot Is Now On by Default ⚡

Autopilot is the mode that lets your AI agent act autonomously — completing tasks without asking you to approve every single step.

Previously, you had to enable it manually. Now it's on by default.

This is a meaningful shift. If you're in a trusted environment and want the agent to just get on with the job, you no longer have to configure anything to make that happen.

You can still adjust the permission level anytime using chat.permissions.default, and organizations can manage Autopilot access centrally via chat.tools.global.autoApprove.

2. Advanced Autopilot: Smarter Task Completion 💡

Here's a tricky problem: how does an AI agent know when it's truly done?

Stop too early and the task is incomplete. Keep looping and you burn time and tokens. VS Code 1.124 introduces Advanced Autopilot, which solves this with a small utility model that reads the conversation transcript and decides whether the task is actually finished — instead of relying on fixed rules.

There's also a tooltip above the chat that shows exactly what objective the agent is working toward, so you're never left guessing. And to keep things bounded, the agent loops a maximum of three times before stopping.

Enable it by setting chat.autopilot.advanced.enabled to true.

3. Background Sessions: Queue Tasks Without Waiting 🔧

This one is immediately useful.

Before 1.124, starting a new agent session meant waiting for it to fully load before you could compose the next request. Now, you can press Alt+Enter (or hold Alt and select Send) to send a request in the background.

The view resets instantly. Your model and context stay selected. Only the query text clears — so you can keep queuing up tasks without interruption. Each session appears in the list once it commits.

It's like sending an email while already typing the next one. Once you use it, going back feels painful.

4. Session Navigation: Find and Switch Fast

If you run multiple agent sessions in parallel, finding the right one used to involve a lot of scrolling. VS Code 1.124 adds proper keyboard-driven navigation:

Sessions Picker — Press Ctrl+R (or Cmd+R on macOS) to open a searchable Quick Pick. Sessions are grouped as recently opened and others. Search by title or folder name.
Back and Forward — Ctrl+Tab / Ctrl+Shift+Tab moves through sessions in most-recently-visited order.
Previous / Next Session — Alt+↑ / Alt+↓ steps through sessions in the order they appear in the list.
Jump by Position — Ctrl+1 through Ctrl+9 focuses the Nth visible session directly.

If you've ever lost track of which session was handling what task, these shortcuts will feel like a lifesaver.

5. Restore Sessions on Reload

Reloading the Agents window used to wipe your layout. You'd have to manually reopen everything and figure out where you left off.

VS Code 1.124 restores your full session layout automatically on reload — which sessions were open, their order, the active session, pinned sessions, per-session layouts, and open editors.

It sounds like a small detail. It doesn't feel small when you're in the middle of five things at once.

6. Close All Sessions

Simple and useful: there's now a Close All Sessions command.

Use Ctrl+K Ctrl+W (or Cmd+K Cmd+W on macOS) while a session has focus. It closes everything in one step — exactly like "Close All Editors" but for agent sessions.

When you've got eight sessions open and want a clean start, this is the command you'll reach for.

7. Browser History in the Integrated Browser

The integrated browser now remembers where you've been.

Previously visited pages appear as suggestions when you type in the URL bar, making it easy to jump back to documentation, APIs, or any page you've already opened. You can manage history from within a browser tab, and the maximum number of entries is configurable via workbench.browser.maxHistoryEntries.

If you spend any time bouncing between MDN, package docs, and Stack Overflow inside VS Code, this is a quiet improvement you'll notice immediately.

8. Improved Browser Toolbar Customization

Before 1.124, only two actions could be pinned to the browser toolbar. Now, you can right-click the toolbar area to the right of the URL bar and toggle any overflow action to be persistently visible.

More control. Less hunting through menus.

9. Faster Agentic Text Entry

When an agent needed to type text into a page and press Enter, it previously required two separate tool calls. The typeInPage tool now supports a submit parameter, combining both actions into one.

This is a small change that reduces round-trips during common text-entry tasks and makes the agent just a bit faster — which adds up when you're running a long workflow.

10. Create Folders from the Simple File Dialog

A clean quality-of-life addition: when you open a folder using the simple file dialog (files.simpleDialog.enable), you can now type a new folder name and press Enter to create it on the spot.

No more switching to your system file explorer just to make a new directory.

11. Single-File Diff in the Changes View

By default, selecting a file in the Changes view opens the multi-file diff editor. If you'd rather focus on one file at a time, enable sessions.changes.openSingleFileDiff.

It keeps the view focused and removes the distraction of other files sitting alongside the one you're reviewing.

12. Enterprise: Centralized Copilot Plugin Policies

For developers in larger organizations, VS Code 1.124 gives admins centralized control over which Copilot plugins and marketplaces are available.

A single policy file now governs both VS Code and Copilot CLI, so configurations don't need to be managed separately. Three new policy-backed settings handle the specifics:

chat.plugins.enabledPlugins — allowlist or blocklist specific plugin IDs
chat.plugins.extraMarketplaces — add organization-approved marketplaces
chat.plugins.strictMarketplaces — trust only policy-supplied marketplaces

Plugins blocked by policy stay visible but appear disabled, so developers can see what's restricted without confusion.

Before vs After: Quick Comparison

Feature	Before 1.124	After 1.124
Autopilot	Off by default	On by default
Task completion detection	Fixed rules	Utility model decides
New session startup	Wait to load, then type	Send in background immediately
Session recovery on reload	Layout lost	Fully restored
Browser history	Not available	Available with URL suggestions
Toolbar customization	2 pinnable actions	All overflow actions pinnable
Folder creation in dialog	Not supported	Supported
Typing + submitting in browser	Two tool calls	One tool call

Best Tips for VS Code 1.124

✅ Use Alt+Enter for background sessions. It genuinely changes how you work with multiple tasks. Queue them up and let the agents run.

✅ Enable Advanced Autopilot with chat.autopilot.advanced.enabled: true if you want the agent to make smarter decisions about when it's done.

✅ Learn the session keyboard shortcuts. Ctrl+R for the picker and Ctrl+1–9 for position jumps are the two most useful ones. Build the habit early.

✅ Set workbench.browser.maxHistoryEntries to a comfortable limit if you're concerned about privacy or memory.

✅ Try sessions.changes.openSingleFileDiff if you find the multi-file diff view too noisy when reviewing agent changes.

❌ Don't leave Autopilot on without checking chat.tools.global.autoApprove in team or enterprise environments. Understand what permissions you're granting before relying on it.

❌ Don't manually reopen sessions after a reload. Let VS Code restore them. You might be doing extra work for no reason.

❌ Don't assume Advanced Autopilot will loop forever. It has a three-loop maximum. For longer tasks, you may need to continue manually after that point.

Common Mistakes to Avoid

1. Thinking Autopilot can't be turned off

"Enabled by default" does not mean forced. You can change the permission level at any time in the chat input box. It's fully configurable.

2. Still manually reopening sessions after a reload

Old habit. VS Code 1.124 handles this automatically. Your layout is restored right where you left it.

3. Ignoring the session picker

A lot of developers still scroll through the sessions list with their mouse. Ctrl+R opens a searchable picker in half a second. It's worth learning.

4. Not setting a history limit for the integrated browser

Browser history grows over time. If you're particular about privacy or lightweight performance, configure workbench.browser.maxHistoryEntries early rather than after it's already grown large.

5. Overlooking single-file diff

If you review agent changes frequently, the default multi-file diff can feel cluttered. sessions.changes.openSingleFileDiff narrows the focus to one file at a time. Many developers who discover it don't go back.

Conclusion

VS Code 1.124 is a focused, practical update. It doesn't reinvent the editor — it tightens up the parts that were causing the most friction in real AI-assisted workflows.

Autopilot on by default. Smarter task detection. Background sessions. Full session recovery. Better browser tools. Every change in this release is aimed at one thing: letting you move faster without losing context.

If you haven't updated yet, open VS Code and use Check for Updates. The rollout is live for all users now.

Want more VS Code breakdowns, developer tools, and frontend content? Head over to hamidrazadev.com — new posts go up regularly. If this saved you the time of reading the full changelog, share it with a teammate. They'll thank you. 😊

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!