DEV Community: Sajid Hossain

[Boost]

Sajid Hossain — Fri, 06 Nov 2026 00:17:15 +0000

Sajid Hossain

Nov 6

Free AI Power Is a Lifestyle: How I Built an AI Fleet Without Paying a Dime

#ai #security #opensource #productivity

6 min read

Free AI Power Is a Lifestyle: How I Built an AI Fleet Without Paying a Dime

Sajid Hossain — Fri, 06 Nov 2026 00:13:08 +0000

Some people collect stamps. Some people collect sneakers. And some of us, ever since the days of FitGirl repacks and PirateBay.org, collect free stuff like it's an Olympic sport.

Naturally, we brought that lifestyle with us into the AI age.

With OpenCode's long, generous free run winding down, a lot of free-tier AI users are staring at their terminals and wondering where to go next. I'd like to say I stayed calm. I did not. I built a fleet instead.

And honestly? It's not even only about the money. Some of us just enjoy the puzzle: figuring out how different services fit together and squeezing every last drop out of what's available. Saving money is just a very nice side effect.

So the idea was simple: instead of depending on one provider, build a whole AI fleet out of whatever's lying around for free.

The crew

Here's what's in the current environment:

AI Studio
OpenCode
DSH
MiniMax
GitHub Copilot
Antigravity
Freebuff
LM Studio

Glue them together with a FreeLLMAPI pipeline that connects a pile of model providers, and suddenly there's a very respectable menu of models for every kind of job.

Here's how it came together.

Step 1: Getting FreeLLMAPI up and running

The starting point was FreeLLMAPI.

I gave Freebuff its own throwaway Gmail account and a simple job: set up the app, then go work through the free providers. Basically, "here's a mailbox, go make friends."

Once everything was installed and configured, Freebuff got busy signing up for accounts and collecting API keys wherever automation allowed. It also kept a separate list of providers that needed a human, mostly because of CAPTCHAs. (Turns out robots are still not allowed to prove they aren't robots.)

The final tally:

37 providers on the list
About 5 needed me to step in and grab the API keys by hand
2 wanted Chinese-specific email addresses, so they got politely skipped

After that little exercise, I had a healthy pool of providers ready to plug into my dev workflow.

Step 2: Picking the actual fleet

Having 30+ providers doesn't mean you need to use every model. That would be like owning 30 hammers because they were free. I piped the available models into DSH, my main harness, through FreeLLMAPI's single unified API key, then filtered out the smaller, less useful ones.

The main fleet ended up being:

Nemotron VL Super
DeepSeek V4.1
GLM 5.3
MiniMax 3.1

Everyone gets a job:

Images and video: Nemotron and MiniMax handle most of it.
Coding: DeepSeek and GLM carry the bulk of the workload.
Web dev and UI/UX: Google AI Studio takes care of websites, interface design and frontend tasks.

I also have access to Claude Opus 5, Sonnet 5 and Haiku 5 through the free allocations available to me. Those are my "call the senior engineers" models, saved for planning, architectural reviews and auditing implementations.

The philosophy: don't ask one model to do everything. Let each one do what it's good at, like a team where nobody has to pretend to be a frontend designer.

Step 3: Many harnesses, one workflow

The other tools haven't gone anywhere. OpenCode, GitHub Copilot, Antigravity and MiniMax are all still part of my daily routine. Each has its limits, but each still hands out some useful free allowance, and I'm not about to turn down free allowance.

Depending on the task, one harness might do the implementation, another helps with planning, and a third reviews or audits the result. It all meets in the same GitHub repo in the end, like a group project where everyone actually showed up.

The big win is not being locked in. No single harness, model or provider is holding the whole thing up. Workloads get spread around, models get swapped when needed, and development keeps going even if one service has a bad day.

Wait, but is this thing secure?

Good question. Because here's the uncomfortable truth: I've built a setup that holds API keys for dozens of providers, runs AI agents that can touch my code, and funnels everything through a single unified key. That's a very convenient setup. It's also a very convenient target if I'm careless.

So here's how I think about locking it down, and how I keep it that way.

Treat the unified key like a master key

FreeLLMAPI gives me one key that opens many doors. Great for convenience, scary if it leaks. So:

Never commit keys to Git. Keep them in environment variables or a .env file that's in .gitignore. Turn on GitHub's secret scanning for your repos so a mistake gets flagged fast.
Keep the service off the open internet. If FreeLLMAPI only needs to be reached from your own machine, bind it to localhost. If you need remote access, put it behind a VPN or a reverse proxy with authentication, and check how the app itself handles auth rather than assuming it does.
Rotate keys now and then. If a key ever shows up somewhere it shouldn't, revoke it and generate a new one. Don't wait and hope.

Lock down the throwaway accounts

The throwaway Gmail is the front door to every provider account Freebuff created. If someone gets into that mailbox, they can reset passwords all over the place.

Use a long, unique password from a password manager, and turn on 2FA for that Gmail.
Store the keys and logins for the providers that needed manual signup in the password manager too, not in a random text file.
Don't reuse that password anywhere. Ever.

Don't give your agents the keys to the kingdom

AI coding agents can run commands and edit files, which is wonderful until one confidently does something silly.

Run them in a sandbox if you can: a container, a VM, or at least a separate user account.
Keep production credentials, SSH keys and personal files out of reach of the agents.
Review what they produce before it merges. That's another reason the shared GitHub repo is useful: pull requests make a good checkpoint. Let one model audit another's work, then let a human glance at it too.

Remember: free tiers aren't always private

Some free tiers may log prompts or use them to improve their models. I don't assume otherwise, so I don't paste secrets, client code, customer data or anything I wouldn't want read. For sensitive work, a local model through LM Studio is the safer choice, since the data never leaves the machine.

Read the terms (yes, really)

Automating signups and farming free keys can bump into providers' terms of service, and some providers limit one account per person. Check the rules for each service you use. Getting banned from a free tier is a very expensive way to save money.

Keeping it healthy: my maintenance routine

Setting it up is the fun part. Keeping it safe is the "eat your vegetables" part. Here's the routine I follow, roughly once a month:

Update things. Pull the latest FreeLLMAPI, update dependencies, and keep the OS and harnesses patched.
Audit the provider list. Delete accounts and keys for providers I no longer use. Every dormant key is a liability.
Rotate the important keys. At least the unified key and anything that touches the repo.
Check usage and quotas. A sudden spike in requests that I didn't make is a red flag that a key may have leaked.
Back up the config. Keep an encrypted copy of the setup so rebuilding after a disaster takes an afternoon instead of a week.
Check what's exposed. Confirm the service is still only reachable the way I intended, and that the repo has no secrets in its history.

It takes maybe half an hour. Much cheaper than the alternative.

Why bother with all this?

Because relying on a single free provider is risky. Free quotas change. Models disappear. Restrictions appear. Sometimes the service you've loved for months turns into a shadow of itself overnight.

A diversified setup gives you options. If one service tightens its limits, there's another. If a model flops at a task, route that task elsewhere. And having models dedicated to specific jobs means less compromise between speed, capability and availability.

Is it a bit of work? Yes. Account management, API configs, routing, quota watching and now security upkeep are all part of the deal. But for me, that trade-off is worth it.

Final thoughts

I'm not claiming this is the ultimate AI setup, or that free tiers will stay this generous forever. It's just what works right now, and I'm enjoying it.

The AI world is moving at a ridiculous speed, and there are more capable models and tools out there than ever. You don't have to pick one provider or pay for five subscriptions to build a solid development environment.

Sometimes you just need to connect the dots. OpenCode's free run may be changing, but the free AI ecosystem is a lot bigger than any single platform.

Secure Your Workstation, Network, and Development Environment Without Slowing Down Your Game

Sajid Hossain — Thu, 05 Nov 2026 00:29:12 +0000

🛡️ Secure Your Workstation, Network & Development Environment

Practical cybersecurity for developers — without unnecessary complexity.

Security doesn't have to mean expensive software, complicated infrastructure, or dozens of security tools.

For independent developers, freelancers, and small teams, the best security improvements are often the simplest ones.

Think about it: your workstation stores your code, your network connects your devices, and your development environment holds your credentials and projects.

If one layer is compromised, the others can be exposed too.

The goal isn't maximum complexity. It's maximum protection with minimum overhead.

Let's break it down.

💻 01 — Secure Your Workstation

Your workstation is the foundation of everything you do. It contains your source code, credentials, personal files, development tools, and potentially sensitive information.

Start with these essentials:

Operating system updates: Enable automatic security updates.
Standard user accounts: Avoid using administrator privileges for everyday activities.
Full-disk encryption: Enable BitLocker on supported Windows editions or an equivalent solution.
Firewall protection: Keep your built-in firewall active.
Password management: Use unique, strong passwords with a password manager.
Multi-factor authentication: Protect GitHub, email, cloud accounts, and other important services.
Automatic screen locking: Lock your workstation whenever you step away.

A useful reminder:

You don't need multiple antivirus products running simultaneously. A properly configured, up-to-date built-in security solution is a sensible starting point.

🌐 02 — Protect Your Work Network

A secure workstation connected to an insecure network is still exposed to unnecessary risks.

Your router is more important than you might think.

Essential router hardening

Security measure	Why it matters
Change default credentials	Prevents easy administrative access
Use WPA2-AES or WPA3	Protects wireless connections
Disable WPS	Reduces unnecessary attack surface
Update firmware	Patches known vulnerabilities
Disable unnecessary remote administration	Reduces external exposure
Create a guest network	Separates visitors and untrusted devices

One more thing: Avoid exposing development servers, databases, SSH, or remote-access services directly to the public internet unless you have a properly secured reason to do so.

What about VPNs?

A VPN can protect traffic on an untrusted network, but it isn't a magic security shield.

It won't automatically protect you from malware, phishing, compromised applications, or weak passwords.

👨‍💻 03 — Secure Your Development Environment

This is where developers often overlook important security risks.

Your development environment may contain:

API keys
Authentication tokens
Database credentials
Private SSH keys
Cloud access credentials
Proprietary source code

A single accidentally exposed credential can create a much bigger problem than a coding mistake.

Protect your secrets

Never commit API keys, passwords, or private tokens to Git.
Store credentials in environment variables or a secrets manager.
Add .env and private configuration files to .gitignore.
Use separate credentials for development and production.
Apply the principle of least privilege to applications and API tokens.
Review unfamiliar packages before installing them.

Add automated security checks

A few open-source tools can help:

Tool	Purpose
`Gitleaks`	Detects exposed secrets
`Bandit`	Finds common Python security issues
`pip-audit`	Checks Python dependencies for known vulnerabilities

You can also use GitHub's available secret-scanning and dependency-security features where supported.

My preferred approach: automate security checks instead of depending entirely on memory.

For example, a small security check running whenever you push code can catch problems before they become bigger issues.

🔬 04 — Isolate Your Experiments

Developers constantly experiment with new tools, scripts, libraries, AI models, and open-source projects.

But not everything you download deserves unrestricted access to your workstation.

Consider using:

Python virtual environments to separate project dependencies.
Docker containers for isolated development and testing.
Virtual machines for testing unfamiliar or potentially risky software.
Separate development and production environments.
Restricted permissions for experimental applications.

Remember that containers are not complete security boundaries. Avoid giving them unnecessary host access, sensitive mounts, or privileged permissions.

A simple rule: Don't give an experimental tool access to resources it doesn't need.

💾 05 — Back Up Your Work

Cybersecurity isn't only about preventing attacks. It's also about recovering when something goes wrong.

A practical backup strategy should include:

Automatic backups of important project files.
Git version control for source code.
Separate backups of important documents and configurations.
At least one backup that isn't continuously accessible from your workstation.
Occasional restoration tests.

Remember the 3-2-1 backup principle

3 copies of your important data.
2 different storage types.
1 copy stored off-site.

Git is excellent for tracking source-code changes, but a Git repository alone isn't a complete backup strategy.

⚙️ 06 — Automate the Routine Security Work

Security becomes much easier when repetitive tasks happen automatically.

Here's a simple toolkit:

Task	Solution
OS security updates	Automatic updates
Credential protection	Password manager + MFA
Secret detection	Gitleaks
Python dependency auditing	pip-audit
Python static analysis	Bandit
Source-code tracking	Git
Environment isolation	Docker / Python venv
Data recovery	Scheduled backups
Network protection	Firewall + router hardening

You don't need to install everything on day one.

Start with the basics, automate what makes sense, and gradually improve your setup.

✅ 07 — The Practical Security Checklist

Use this as a quick workstation security audit.

Workstation

[ ] Operating system and applications updated.
[ ] Disk encryption enabled.
[ ] Firewall enabled.
[ ] Standard user account used for everyday work.
[ ] Password manager and MFA configured.

Network

[ ] Router administrator password changed.
[ ] Wi-Fi secured with WPA2-AES or WPA3.
[ ] WPS disabled if unnecessary.
[ ] Unnecessary exposed ports and services disabled.

Development

[ ] API keys and secrets kept out of source control.
[ ] Dependencies checked for known vulnerabilities.
[ ] Experimental software tested in isolation.
[ ] Development and production credentials separated.

Recovery

[ ] Important files backed up.
[ ] At least one isolated or offline backup maintained.
[ ] Backup restoration tested.

🔐 Final Thoughts — Security Should Enable Productivity

Security and productivity shouldn't be opposing goals.

You shouldn't have to spend half your day managing security tools just to feel safe working on a project.

A patched workstation, properly configured firewall, protected credentials, secure network, isolated development environment, and reliable backups provide a strong practical foundation.

You don't need an enterprise security budget to start building better security habits.

Start small. Automate what you can. Keep your attack surface under control.

Spend less time worrying about preventable security problems and more time building something meaningful.

What simple security practices or tools do you use to protect your development environment? I'd love to hear what works for other developers.