DEV Community: Antonios Thanasis

How to Save Money Using Free AI Tools (No Paid Subscription Needed)

Antonios Thanasis — Tue, 05 May 2026 10:10:32 +0000

I'm not claiming this is the best approach. This is simply what I do, and it genuinely helps me. If it helps you too, great.*

The Problem

Most developers are overpaying for:

Claude Pro
ChatGPT Plus
Cursor Pro
GitHub Copilot (paid plan)

The truth? Free tiers are powerful enough if you combine them, switch when limits hit, and avoid wasting tokens on tasks you can do yourself.

Core Strategy: Rotation Over Subscription

Instead of committing to one paid tool, I keep a roster of free AI assistants and cycle through them based on task complexity and remaining quota.

My always-available lineup:

Cursor (free tier) – agentic coding with project context
GitHub Copilot (free tier / limited access) – inline autocomplete
Windsurf (free tier) – multi-file edits through natural language
Claude (browser, free) – complex reasoning & architecture
ChatGPT (free tier) – general fallback
Gemini (browser, free) – another fallback
DeepSeek (browser) – overflow capacity

No single tool is my “main”. They all are.

How I Use Each Free Tier Efficiently

I think of tasks in three difficulty levels. Matching the tool to the task preserves high-value quotas.

🟢 Simple Coding Tasks

These need speed, not deep thinking:

Fast autocomplete → GitHub Copilot
Basic refactors, single-file edits → Cursor basic agent

🟡 Medium Complexity

Multi-file changes, understanding project-wide impact:

Multi-file edits with natural language → Windsurf
Project-level changes, agentic refactors → Cursor agents

🔴 Complex Architecture & Reasoning

When I need to think through hard problems:

System design discussions
Debugging complex logic
Refactoring strategy

→ Use browser-based Claude (no code execution needed, just reasoning)

Make Every Token Count: Use AI Selectively, Not Blindly

Free tiers have limits. The best way to stretch them is to only involve AI where it adds real value.

1. Use AI for complexity, not routine

I don’t copy-paste simple Trello/Linear tickets into a chat window. If the task is straightforward (rename a variable, add a basic endpoint), I just code it. I reserve AI for the hard parts: designing architecture, solving tricky bugs, or optimizing logic.

2. Form my own idea first

Before asking AI to “build feature X,” I think through a rough approach. I write a quick outline or a dirty first draft — then I ask:

“Here’s my plan for the auth flow [describe it]. Is this a good approach, and how should I refactor it?”

Now I’m using AI as a reviewer and a refactoring partner, not as a code generator from scratch. This saves tokens and produces better output because I provide context.

3. Ask for opinions, not just code

Instead of “write a caching layer,” I try:

“I’m thinking of using Redis for session caching. Does that make sense for my use case, or is there a simpler pattern?”

I get high-value reasoning without burning quota on boilerplate the AI would have generated anyway.

4. Write quick-and-dirty, then request a refactor

I stub out the core logic myself — even if it’s messy. Then I feed it to the AI with:

“Here’s a rough implementation. How can I make this cleaner or more idiomatic?”

I learn more, keep control of the design, and the AI focuses on exactly what I need: improving existing code, not guessing requirements.

Result: I stay in the driver’s seat. The AI augments my thinking, not replaces it — and my free quotas last far longer.

What I Do When I Hit a Limit

Limits will happen. I don’t stop working — I switch.

If this limit is hit	I switch to
Cursor free quota	Copilot or Windsurf
Copilot free quota	Cursor or browser tools
Windsurf free quota	Cursor agents or Claude browser
All desktop app limits	Claude / ChatGPT / Gemini / DeepSeek (browser)

I keep rotating. I treat each tool like a resource bar — when one is empty, the next is full.

Why This Works (for me)

Most people overpay because they treat one tool as their only source of AI assistance. But:

Free tiers have different limits. Cursor gives fast requests, Copilot offers completions, Claude browser offers high reasoning depth.
Browser-based AIs are unlimited in sessions (you just wait or switch accounts). They're perfect for complex thinking I'd otherwise do inside Cursor.
I rarely need all modalities at once. When I'm doing heavy reasoning in Claude, I’m not burning Cursor quota.

Plus: By using AI only for the genuinely hard parts and feeding it my own ideas, I drastically cut unnecessary token consumption. The sum of free tiers + smart usage > any single paid plan.

The Mindset Shift That Helps Me

Don't rely on one subscription. Tools are interchangeable. Limits are temporary. Switching is part of the workflow.

Don't outsource your thinking — use AI to sharpen it.

I stopped treating AI like a paid service I need to subscribe to. I think of myself as a systems operator managing multiple resources, and a craftsman who knows when to reach for a power tool.

My Final Free Stack

These are all set up, no credit card required (or included in free plans I already had):

✅ Cursor (free)
✅ GitHub Copilot (free tier)
✅ Windsurf (free)
✅ Claude (browser, free tier)
✅ ChatGPT (free)
✅ Gemini (browser, free)
✅ DeepSeek (browser, overflow)

Total cost: $0/month.

Coverage: full-stack coding, architecture, debugging, and learning.

The Result (what I get out of it)

Full coding coverage — from autocomplete to system design
No subscription cost — I keep my money for compute, domains, or coffee
Always-on backup — no single point of failure, no “service down” panic
Flexible workflow — adapts to any task, any language, any time of day
Better code — because I'm thinking first and using AI to refine, not to guess

Again: this isn't some universal "best way." It's just what I do, and it honestly helps me. Maybe it can help someone else too.

🐱 Stop Using `env()` in Runtime Code

Antonios Thanasis — Mon, 27 Apr 2026 08:36:36 +0000

The Symptoms 😿

Jobs fail randomly
API calls return 401 Unauthorized

The "Solution" 🔄

php artisan config:clear

Then restart workers to pick up fresh environment values.

It works temporarily. Then fails again.

The Real Problem 🐛

The app was configured correctly. All env() calls lived inside config files. Config caching worked perfectly.

Then a developer added this directly in runtime code:

$newApiKey = env('NEW_API_KEY');

No config file entry. No config('services.new_api_key'). Just env() in the middle of a controller.

It worked fine in development because .env was being loaded on every request.

But in production, config:cache was running on every container restart. Laravel stops loading .env files when config is cached.

The config cache didn't have NEW_API_KEY because there was no config file for it. So env('NEW_API_KEY') returned null.

Boom. null → Unauthorized → crash.

Why config:clear "Fixes" It 🔁

config:clear removes the cached config file. Laravel starts loading .env fresh again.

env('NEW_API_KEY') works again → everything runs fine.

Until the next container restart runs config:cache and breaks it again.

It's a temporary bandage. Not a fix.

The Actual Fix ✅

Add the new env variable to the proper config file

// config/services.php
return [
'api' => [
'key' => env('API_KEY', ''),
'new_key' => env('NEW_API_KEY', ''), // Add this line
],
];

Use config() in runtime code

// ❌ Don't do this
$newApiKey = env('NEW_API_KEY');

// ✅ Do this instead
$newApiKey = config('services.api.new_key');

Redeploy and cache

php artisan config:cache

The Results 🎉

✅ No more random Unauthorized errors
✅ No more config:clear bandages
✅ New env variables work with config cache

The Lesson 🐾

If your fix is config:clear + restart, that's not a fix — it's a symptom.

One hard rule:

Every new env() call must first go through a config file.

config file ← env()
runtime code ← config()

No exceptions.

🐱 Remember

Config files are the bridge between .env and your code.

Break the bridge, break the app.

Now go fix your config.

Stop clearing. Start fixing.

How We Fixed a Puppeteer Memory Leak in a Laravel IoT App

Antonios Thanasis — Tue, 03 Mar 2026 10:02:25 +0000

We were running an IoT application on Azure and kept hitting a frustrating problem — randomly, Docker commands would hang or fail entirely. No obvious reason. Just… dead.

After digging, we found the culprit: a Puppeteer scraper silently leaking Chromium processes every time it ran multiple scrapes.

🔍 Investigation

First thing we checked was memory:

ps aux --sort=-%mem | head -20

We spotted multiple orphaned Chromium processes, each eating ~90MB:

green  10374  0.1  1.1  /usr/lib/chromium/chrome --type=renderer --headless ...
green  10367  0.1  1.1  /usr/lib/chromium/chrome --type=renderer --headless ...
green  10347  0.9  1.0  /usr/lib/chromium/chrome --headless --enable-automation ...

Docker stats confirmed the problem:

sudo docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}"

scraper_1       320.5MiB / 7.772GiB  ← 🚨
app_1           143.8MiB / 7.772GiB
queue_worker_1  120.5MiB / 7.772GiB

The scraper container was using much more memory than expected, and it kept growing over time.

🕵️ The Root Cause

The scraper visits router admin pages using Puppeteer to collect bandwidth data. Originally, the code launched one browser per device:

Sequential failures left Chromium processes orphaned.
Memory usage grew with each failed scrape.
Docker eventually ran out of memory or hung.

Original Problematic Pattern

// ❌ Launches a browser per URL
const browser = await puppeteer.launch();
const page = await browser.newPage();

try {
    await page.goto(url);
    // scrape logic
    await browser.close(); // only runs on success
} catch (err) {
    // may never reach browser.close()
}

Each failure left a Chromium instance alive.
With 15+ routers, these quickly stacked up.

✅ The Fix: Single Browser, Multiple Pages

Instead of launching a browser per device, we:

Launch one shared browser.
Open/close a page per URL.
Always close the browser in a finally block.

Runner (scraper logic)

const runner = async ({ url, browser }) => {
    const page = await browser.newPage();

    try {
        // Go to the router URL
        await page.goto(url, { waitUntil: 'load', timeout: 15000 });

        // Fill in login form
        await page.$eval('input[name="username"]', (el, v) => el.value = v, config.teltonika_username);
        await page.$eval('input[name="password"]', (el, v) => el.value = v, config.teltonika_password);
        await page.$eval('input[type="submit"]', btn => btn.click());

        // Wait for page to load after login
        await page.waitForTimeout(15000);

        // Scrape the values
        const sent = await page.$eval("#lb_tx_sum", el => el.textContent.trim());
        const received = await page.$eval("#lb_rx_sum", el => el.textContent.trim());
        const total_today_usage = await page.$eval("#lb_all_sum", el => el.textContent.trim());

        return { fields: { sent, received, total_today_usage } };

    } catch (err) {
        throw err; // let the caller handle errors
    } finally {
        // Always close the page to prevent leaks
        await page.close();
    }
};

Main Scraper Loop

const browser = await puppeteer.launch({
    executablePath: process.env.PUPPETEER_EXECUTABLE_PATH,
    args: ["--ignore-certificate-errors", "--no-sandbox", "--disable-dev-shm-usage"]
});

try {
    for (const dom of domains) {
        const results = await teltonika.exec({ id: dom.id, url: dom.url, browser });
        // send results to API
    }
} finally {
    await browser.close(); // ✅ guaranteed cleanup
}

📊 Results

Metric	Before	After
Scraper container memory	320.5 MiB	34.77 MiB
Orphaned Chromium processes	3+ (growing)	0 ✅
VM RAM usage	7/8 GB	Stable
Docker commands failing	Frequently	Never

That's a 10x memory reduction from a single finally block.

🧠 Key Takeaways

Use try/catch/finally with Puppeteer — ensures browser cleanup even if an error occurs.
Do not launch one browser per URL — reuse a single instance for multiple pages.
Set timeouts for goto, waitForSelector, and waitForTimeout — avoids hangs on unreachable hosts.
Scrape sequentially for many devices — parallel Chromium launches explode memory usage.
Monitor with ps aux | grep chromium — if processes accumulate, you have a leak.

🔧 Bonus: Quick Cleanup if You're Already Leaking

If you're in this situation right now and need to free memory immediately:

# Kill all orphaned Chromium
pkill -f chromium

# Free OS cache (safe)
sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

# Add swap as a safety net
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

This approach ensures Puppeteer scrapers are robust, memory-efficient, and production-safe, even when scraping dozens of devices sequentially.

Deploy Your Laravel Demo for Free — Domain, MySQL & Hosting at $0

Antonios Thanasis — Sun, 22 Feb 2026 14:02:11 +0000

If you've built a Laravel project and need a live demo link — for a portfolio, a client presentation, or just to share with friends — spinning up a VPS just to host a demo feels like overkill.

InfinityFree gives you:

🌐 A free subdomain (yourapp.great-site.net or .epizy.com)
🗄️ A free MySQL database
☁️ PHP hosting

All for $0.

The catch? It's not a typical shared host. There are real restrictions that break a standard Laravel deployment out of the box. This post documents exactly what breaks and how to fix every single one of them — based on a real deployment I did for a Laravel social media app.

⚠️ Know the Limitations First

Before you start, understand what you're working with:

Feature	Available?
Free subdomain	✅ Yes
Free MySQL database	✅ Yes
PHP support	✅ Yes
File Manager (browser-based)	✅ Yes
SSH access	❌ No
`php artisan` commands	❌ No
Symlinks (`storage:link`)	❌ No
`open_basedir` restriction	❌ PHP only reads inside `htdocs/`
Composer on server	❌ No

🔴 The open_basedir restriction is the biggest gotcha. PHP will refuse to read any file outside of htdocs/ — which completely breaks Laravel's default folder structure.

Step 1 — Prepare Your Project Locally

Set your .env for production

APP_NAME=YourApp
APP_ENV=production
APP_KEY=base64:YOUR_32_CHAR_KEY_HERE==
APP_DEBUG=true   # temporarily true to see errors
APP_URL=http://yourapp.great-site.net

DB_HOST=sql123.epizy.com   # from your cPanel
DB_DATABASE=epiz_xxxxx_dbname
DB_USERNAME=epiz_xxxxx_user
DB_PASSWORD=yourpassword

💡 You can't run php artisan key:generate on InfinityFree. Generate your APP_KEY locally and paste it in. It must start with base64:.

Package your files into two ZIPs

The vendor/ folder is typically 30–50MB which exceeds the File Manager upload limit. Split it:

# ZIP 1 — everything except vendor/
zip -r project.zip . --exclude="vendor/*" --exclude=".git/*"

# ZIP 2 — vendor/ folder only
zip -r vendor.zip vendor/

Step 2 — Upload via File Manager

FTP may not connect reliably on InfinityFree's free tier. Use the built-in File Manager in your cPanel instead:

Log in to InfinityFree → open File Manager
Navigate to htdocs/
Upload project.zip → right-click → Extract
Upload vendor.zip → extract into the same folder
Upload your .env file into the project root

✅ Everything — and I mean everything — must be inside htdocs/. Due to open_basedir, PHP cannot access any path above it.

Your final directory structure should look like this:

htdocs/
├── index.php        ← moved from public/
├── .htaccess        ← moved from public/
├── storage/
│   └── avatars/     ← manually created for uploads
├── app/
├── bootstrap/
├── config/
├── database/
├── resources/
├── routes/
├── vendor/
├── .env
└── ...

Step 3 — Fix index.php

Laravel's default public/index.php references ../vendor and ../bootstrap — paths that go outside htdocs/. Since everything is now flat inside htdocs/, you need to remove the ../.

Here's the full corrected index.php:

<?php

// Temporary — remove once everything works
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

define('LARAVEL_START', microtime(true));

// ✅ No more ../ — everything is in htdocs/
require __DIR__.'/vendor/autoload.php';

$app = require_once __DIR__.'/bootstrap/app.php';

$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

$response->send();

$kernel->terminate($request, $response);

The only change from the default: __DIR__.'/../vendor' → __DIR__.'/vendor' (same for bootstrap).

Step 4 — Fix File Uploads (No storage:link)

php artisan storage:link creates a symlink from public/storage to storage/app/public. Symlinks don't work on InfinityFree.

The fix is to bypass Laravel's storage system for uploads and write directly to the web-accessible folder using $_SERVER['DOCUMENT_ROOT'].

// ❌ Default Laravel — breaks on InfinityFree
$attributes['avatar'] = request('avatar')->store('avatars', 'public');

// ✅ InfinityFree-compatible
if (request('avatar')) {
    $file     = request('avatar');
    $filename = time().'.'.$file->getClientOriginalExtension();
    $dest     = $_SERVER['DOCUMENT_ROOT'].'/storage/avatars';

    $file->move($dest, $filename);
    $attributes['avatar'] = 'avatars/' . $filename;
}

Files saved this way are immediately accessible at:

yourapp.great-site.net/storage/avatars/filename.jpg

✅ Make sure the htdocs/storage/avatars/ folder exists before uploading. Create it manually in File Manager.

Step 5 — Set Up the Database

Since there's no SSH, you can't run php artisan migrate. Export your schema locally and import it via phpMyAdmin:

# Export locally
mysqldump -u root -p your_local_db --no-data > schema.sql

Then in InfinityFree cPanel:

Go to MySQL Databases → create a database and user
Open phpMyAdmin
Select your new database → click Import → upload your .sql file

Errors You'll Hit & How to Fix Them

Error	Cause	Fix
`403 Forbidden`	No `index.php` found in `htdocs/`	Move `public/` contents into `htdocs/`
`HTTP 500`	Missing `APP_KEY` in `.env`	Set `APP_KEY` manually starting with `base64:`
`open_basedir restriction`	Files placed outside `htdocs/`	Move everything inside `htdocs/`, fix `index.php` paths
Images not loading	`storage:link` not supported	Use `DOCUMENT_ROOT` to write uploads directly to `htdocs/storage/`

✅ Deployment Checklist

Before going live, run through this:

[ ] APP_KEY set in .env (starts with base64:...)
[ ] All files inside htdocs/ — nothing outside
[ ] index.php uses __DIR__.'/vendor' not __DIR__.'/../vendor'
[ ] .htaccess moved from public/ to htdocs/
[ ] vendor/ folder uploaded and extracted
[ ] Database schema imported via phpMyAdmin
[ ] htdocs/storage/avatars/ folder created manually
[ ] File upload controller uses $_SERVER['DOCUMENT_ROOT']
[ ] APP_DEBUG set to false when done ✅

Final Thoughts

InfinityFree is not for production. There's no SSH, no queue workers, no scheduler, and performance is limited. But for demo projects, portfolios, and proof-of-concept apps it does exactly what it promises — gets your Laravel app live with a real URL, a real database, and zero cost.

If you outgrow it, the same codebase deploys cleanly to any proper VPS — just reverse the index.php paths and re-run php artisan storage:link.

Built and deployed a Laravel project on InfinityFree? Drop your experience in the comments — especially if you hit an error not covered here! 👇

Queue Runs in Sync Mode Despite QUEUE_CONNECTION=database in .env

Antonios Thanasis — Fri, 13 Feb 2026 14:03:42 +0000

Queue Runs in Sync Mode Despite `QUEUE_CONNECTION=database` in `.env`

Sometimes after switching your queue connection from sync to database, jobs still run synchronously — or nothing works as expected.

The culprit is usually Laravel's configuration cache.

Even if your .env is correct:

QUEUE_CONNECTION=database

Laravel may still be reading a stale cached config.

✅ Fix

Run these two commands:

php artisan config:clear
php artisan queue:restart

config:clear — removes the cached configuration so Laravel reads your .env fresh
queue:restart — signals running queue workers to restart and pick up the new config

After that, your queue should correctly use the database driver. 🚀

Happy coding!