Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 7 min read

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

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 wit

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:

  1. Update things. Pull the latest FreeLLMAPI, update dependencies, and keep the OS and harnesses patched.
  2. Audit the provider list. Delete accounts and keys for providers I no longer use. Every dormant key is a liability.
  3. Rotate the important keys. At least the unified key and anything that touches the repo.
  4. Check usage and quotas. A sudden spike in requests that I didn't make is a red flag that a key may have leaked.
  5. Back up the config. Keep an encrypted copy of the setup so rebuilding after a disaster takes an afternoon instead of a week.
  6. 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.

Now if you'll excuse me, my fleet needs a quota check.

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.