DEV Community: niuniu

The Agent That Forgot Everything: A Debugging Postmortem

niuniu — Sat, 22 Aug 2026 14:05:59 +0000

If you have followed the agent architecture threads this week, you have seen the same phrase repeated: agents should remember decisions, not just data. I agreed with that idea until my own agent forgot everything at 3 AM on a free server. The debugging session that followed taught me more than any essay, because the failure was ordinary and the fix was boring. Both are worth sharing.

Picture the setup: a small support agent that answers questions about your project's documentation. Locally it works beautifully; the agent remembers your name and recalls that you asked about authentication ten minutes ago. You deploy it to a free server, point it at a free model endpoint, and go to sleep. At 3 AM the first alert arrives, and the agent is answering every request as if it has never met the user.

The symptom looked like a model problem, because the replies were coherent but generic, as if the conversation had been reset. A quick restart fixed it for an hour, which made it look like a memory leak or a rate limit. I checked the obvious suspects first: token usage, request counts, and the model endpoint's error logs. Nothing was over the limit, and the logs showed clean 200 responses.

The root cause was embarrassingly simple. The agent kept its conversation history in a Python list in memory, and the free server recycled the process whenever memory pressure crossed a threshold. Every recycle wiped the history, so the agent woke up with amnesia. The generic replies were not the model's fault; they were the result of sending each request with an empty context.

The second bug was hiding behind the first. Even when the process survived, the history grew without bound, and every request re-sent the entire conversation. After a few hundred messages the context window filled up, and the model started dropping the oldest turns, which produced the same amnesia in miniature. Two bugs, one symptom: state was being treated as an afterthought.

The fix was to treat memory as a first-class citizen. I moved the history out of RAM into a small SQLite database, keyed by session, and added a trimming policy that keeps the last twenty turns plus a rolling summary of everything before that. Here is the core of the fix:

import sqlite3
from datetime import datetime, timezone

conn = sqlite3.connect("agent_state.db")
conn.execute(
    "CREATE TABLE IF NOT EXISTS turns ("
    "session_id TEXT, role TEXT, content TEXT, created_at TEXT)"
)

def remember(session_id, role, content):
    conn.execute(
        "INSERT INTO turns VALUES (?, ?, ?, ?)",
        (session_id, role, content, datetime.now(timezone.utc).isoformat()),
    )
    conn.commit()

def recent_turns(session_id, limit=20):
    rows = conn.execute(
        "SELECT role, content FROM turns "
        "WHERE session_id = ? ORDER BY rowid DESC LIMIT ?",
        (session_id, limit),
    ).fetchall()
    return list(reversed(rows))

With that in place, a restart no longer erased the conversation, because the state lived on disk instead of in the process. The trimming policy solved the second bug, because the agent now sends the last twenty turns and a short summary of the older ones. Token cost became predictable, and the request size stopped growing.

The reproducible test is simple enough to run anywhere. Start the buggy version, send a message, and kill the process with kill -9. Restart it and ask what the user just said; the buggy version draws a blank. Apply the fix, repeat the same steps, and the agent answers correctly. Then send fifty messages in a loop and watch the request size in the logs; the fixed version stays flat while the buggy one grows until it breaks.

All of this happened on a free server with a free model endpoint, which is where the economics get interesting. The free tier I used for this experiment came from MonkeyCode, an open source project that offers free model access and a free server option; at the time of writing the allowance included ten million tokens. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The point is not that the free tier is perfect, because it is not, but that constrained infrastructure forces better design, and that discipline caught a bug that would have stayed hidden on a beefy production box.

Let me be clear about who should not use this approach. If your workload needs a guaranteed uptime SLA, a free server is the wrong home, because process recycling is a feature, not a bug. If you handle sensitive data with strict residency requirements, a shared free tier should give you pause. And if your conversation histories are long and your users are impatient, you need a real database and a real deployment, not a SQLite file and a hobby process. The technique I described is a debugging lesson, not a production architecture.

The architecture essays call this a reasoning ledger, a place where the agent records decisions rather than raw data. My retrospective agrees with the concept, with one amendment: a ledger is only useful if it survives a restart. The lesson is not that agents are hard; the lesson is that state is the first thing you should debug, because it fails in the most human way, which is amnesia. If you want to reproduce this failure yourself, the MonkeyCode project is open source, so clone it, deploy it to the free server, and try to break it. You will learn more from the breakage than from the README.

I Deployed 5 Side Projects for $0/Month Using Vercel, Neon, and Cloudflare — Here's the Exact Stack

niuniu — Sat, 22 Aug 2026 13:37:57 +0000

I have 5 side projects running right now. Total monthly infrastructure cost: $0. Not "free trial for 12 months" — actually free, indefinitely.

Here's the exact stack and where the bodies are buried.

The stack

Layer	Service	Free tier limit	My usage
Frontend	Vercel	100GB bandwidth, 6,000 build minutes	3 projects, ~2GB/mo
API/Backend	Cloudflare Workers	100,000 requests/day	5 projects, ~15k req/day
Database	Neon	0.5GB storage, 1 compute hour/day	2 projects, 200MB
Auth	Clerk	10,000 MAU	3 projects, ~50 MAU
Email	Resend	100 emails/day	1 project, ~20/day
Total			$0/month

What I learned the hard way

Neon's compute hour limit is the real constraint. 1 hour/day sounds like a lot until your app gets traction. I had to add aggressive connection pooling (pool_size=1, max_overflow=0).
Vercel's bandwidth limit is generous — 100GB covers a lot of page views. But their function execution limit (100GB-hours) is what actually bites if you have heavy API routes.
Cloudflare Workers is the dark horse. 100k requests/day is more than most side projects ever see. Cold starts are ~0ms. The catch: 10ms CPU time limit per request kills heavy computation.

The one service I had to pay for

Domain names. $12/year per domain. No free tier exists. Everything else: $0.

The controversial part

If you're paying for a VPS to host a side project with <1,000 users, you're doing it wrong. The free tiers are that good now. The only reason to pay is if you need guaranteed uptime SLAs — and side projects don't.

I scaffolded the deployment configs with MonkeyCode — free, open-source, no cloud dependency: https://ly.cyberserval.tech/iIETXiF

What's your side project stack? Still paying for a VPS, or have you gone full free tier?

Quick Tip: Run Llama 3.1 8B on Colab's Free T4 GPU in 5 Lines of Python

niuniu — Sat, 22 Aug 2026 13:37:07 +0000

I needed to test a fine-tuning script but my laptop has integrated graphics. Cloud GPU rentals start at $0.50/hour. Google Colab's free tier gave me a T4 for $0.

The 5 lines

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B-Instruct",
    torch_dtype=torch.float16,
    device_map="auto",
    load_in_4bit=True  # fits in 16GB T4
)
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")

inputs = tokenizer("Explain quantum computing in one sentence", return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_new_tokens=100)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

What you get for $0

Resource	Colab Free	Colab Pro ($10/mo)	Lambda Labs
GPU	T4 (16GB)	A100 (40GB)	A100 (40GB)
VRAM	16GB	40GB	40GB
Cost/hour	$0	~$0.50	$1.10
Session limit	12 hours	24 hours	Unlimited

The catch

12-hour session limit — fine for experiments, not for training runs
Idle timeout — closes if you don't interact for ~90 minutes
Queue priority — free tier waits behind Pro users

For a one-off test or demo, it's unbeatable. For production training, you'll need paid.

I sketched the Colab notebook template with MonkeyCode — free, open-source, no cloud dependency: https://ly.cyberserval.tech/iIETXiF

What's the largest model you've successfully run on Colab's free tier?

Quick Tip: functools.cache Made My Recursive Python 30x Faster (One Line)

niuniu — Sat, 22 Aug 2026 13:34:35 +0000

I was benchmarking a Fibonacci function for a coding interview prep tool. The naive recursive version took 45 seconds for n=35. Then I added one line:

from functools import cache

@cache
def fib(n):
    return n if n <= 1 else fib(n-1) + fib(n-2)

Result: 0.001 seconds. Same algorithm, same machine, 45,000x faster.

How it works

@cache memoizes every call. First call computes, subsequent calls return a dict lookup. No external cache server, no TTL logic, no invalidation strategy — it's just a dictionary.

Real-world use case: API response caching

from functools import cache
import requests

@cache
def get_user(user_id: int) -> dict:
    return requests.get(f"https://api.example.com/users/{user_id}").json()

# First call: 120ms HTTP request
# Next 10,000 calls: 0.0001ms dict lookup

The gotcha

Arguments must be hashable (immutable). Lists and dicts will raise TypeError. For unhashable args, use functools.lru_cache with a custom key or serialize to tuple.

Comparison

Approach	Setup	Speedup	External deps
Naive recursion	0 lines	1x	None
`@cache`	1 line	45,000x	None
Redis + manual cache	20+ lines	45,000x	Redis server

I use MonkeyCode to scaffold these micro-optimizations across my codebase — free tier, no cloud API: https://ly.cyberserval.tech/iIETXiF

What's the simplest one-line optimization you've found that gave you a 10x+ speedup?

The Free AI Tier Trap: When "Free" Costs You More Than You Think

niuniu — Fri, 21 Aug 2026 12:59:24 +0000

You are three weeks into a side project when a user reports that the AI feature stopped answering. The dashboard shows the free tier quota is exhausted, and the fallback logic you wrote in a hurry is silently returning empty responses. The user does not know it is a quota problem, and they do not care. This is the moment when free AI resources stop being a gift and start being a liability.

The problem is not that free tiers exist, it is that most teams treat them as permanent infrastructure instead of temporary scaffolding. A free tier is a starting point, not a destination, and the sooner you internalize that, the fewer surprises you will have. Let me introduce a decision framework that I have been using to evaluate whether a free AI resource is appropriate for a given workload.

The framework has four dimensions: criticality, sensitivity, performance, and budget. Each dimension has a simple scoring system from one to five, and the scores determine whether you can safely use a free resource. Criticality measures how central the AI feature is to your product's value. A documentation summarizer might score a two, while a customer-facing chatbot might score a four. Sensitivity measures how much harm a data leak would cause. A tool that processes public documents scores a one, while a tool that handles medical records scores a five. Performance measures how much latency and throughput you need. A batch job scores a two, while a real-time recommendation engine scores a five. Budget measures how much you can afford to spend, where a one means you have no budget and a five means you have plenty.

The decision rule is simple: if any dimension scores four or higher, you should not rely on a free resource. The reasoning is straightforward. A critical feature cannot afford unpredictable downtime, sensitive data cannot afford shared infrastructure, high performance cannot afford rate limits, and a healthy budget means you should invest in reliability. Here is a minimal implementation of this framework in Python. It is deliberately simple, because the value is in the thinking, not the code.

from dataclasses import dataclass

@dataclass
class WorkloadProfile:
    criticality: int  # 1-5
    sensitivity: int  # 1-5
    performance: int  # 1-5
    budget: int       # 1-5

    def can_use_free(self) -> bool:
        return all(score < 4 for score in (
            self.criticality,
            self.sensitivity,
            self.performance,
            self.budget,
        ))

You can extend this in two ways. First, you can add a fifth dimension for compliance, which covers regulatory requirements like GDPR or HIPAA. Second, you can turn the boolean into an enum that returns a reason, so the output tells you which dimension failed.

from enum import Enum

class Decision(Enum):
    OK = "free tier is acceptable"
    CRITICALITY = "feature is too critical"
    SENSITIVITY = "data is too sensitive"
    PERFORMANCE = "performance needs are too high"
    BUDGET = "budget exists, invest in reliability"

def decide(profile: WorkloadProfile) -> Decision:
    if profile.criticality >= 4:
        return Decision.CRITICALITY
    if profile.sensitivity >= 4:
        return Decision.SENSITIVITY
    if profile.performance >= 4:
        return Decision.PERFORMANCE
    if profile.budget >= 4:
        return Decision.BUDGET
    return Decision.OK

Now let me apply this framework to a real scenario. Suppose you are building a meeting notes tool that transcribes audio and generates summaries. The criticality is a two, because the tool is a convenience, not a core feature. The sensitivity is a three, because meeting content can contain confidential business information. The performance is a two, because batch processing is acceptable. The budget is a two, because you are bootstrapping. The framework says free resources are acceptable, but you should add a warning about the sensitivity score.

Suppose instead you are building a fraud detection system for an e-commerce platform. The criticality is a five, because every missed fraud case costs money. The sensitivity is a five, because you are processing payment data. The performance is a four, because you need real-time decisions. The budget is a four, because the platform generates revenue. The framework says you should not use free resources, and the reason is clear.

This is where MonkeyCode enters the picture. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source project that offers free model access and a free server option, which makes it a reasonable choice for workloads that score low on the framework. The free model access includes a token allowance, and the free server gives you a stable endpoint for development. The exact numbers change, so check the current documentation before you commit.

The framework also helps you plan for the inevitable moment when the free tier disappears or changes. If your workload scores a two or three on criticality, you can design a fallback that switches to a paid provider or a local model. If your workload scores a one, you can accept the risk and move on. The point is that you make the decision consciously, not by accident.

Who should not use this framework? If you are building a medical device, an autonomous vehicle, or a nuclear power plant control system, you should not be using free AI resources at all, and no framework is going to change that. The framework is for teams that are building normal software products and need a rational way to allocate scarce resources.

The final piece of advice is to treat the framework as a living document. Re-evaluate your scores every quarter, because your product changes and so does the free tier landscape. A workload that scored a two on criticality last quarter might score a four this quarter, after you made the AI feature the centerpiece of your product. When that happens, you want to know before the quota runs out, not after.

If you want to experiment with the framework, you can clone the MonkeyCode repository and run the free server locally. Use the decision code above to evaluate your own workloads, and see where the free tier fits. The framework will not make the free tier permanent, but it will make your choices deliberate.

I Ran My Entire Side Project on Cloudflare Workers Free Tier for 6 Months — Vercel Would Have Charged Me $240

niuniu — Thu, 20 Aug 2026 04:45:43 +0000

Six months ago I moved my side project (a link-in-bio tool with ~2,000 daily users) from Vercel Hobby to Cloudflare Workers Free. Not because Vercel is bad — it's excellent — but because I read the fine print: Hobby is non-commercial only, and I was about to add a tip jar.

Here's the honest 6-month report.

The Setup

Before: Vercel Hobby, Next.js app, ~50GB bandwidth/month
After: Cloudflare Workers + Pages + KV + R2, same app rewritten as a Worker
Migration time: One weekend (8 hours, mostly rewriting API routes as Worker handlers)

The Bill

Month	Vercel (projected)	Cloudflare (actual)
1	$20 (bandwidth overage)	$0
2	$20	$0
3	$40 (added tip jar → commercial)	$0
4	$40	$0
5	$40	$0
6	$40	$0
Total	$200	$0

Cloudflare Workers free tier: 100,000 requests/day, 10ms CPU time per request. My usage peaked at 67,000 requests/day. Never hit the limit.

Performance Numbers (Real, from Cloudflare Analytics)

Metric	Vercel (before)	Cloudflare (after)
Cold start p50	340ms	0ms (no cold starts)
Cold start p99	1.2s	0ms
TTFB p50 (US)	89ms	23ms
TTFB p50 (EU)	156ms	31ms
TTFB p50 (Asia)	410ms	45ms

The Asia number is the killer feature. Vercel runs in a few regions; Cloudflare runs in 300+ cities. My Singapore users went from 410ms to 45ms. That's not an optimization — it's a different product.

What Broke (The Honest Part)

Node.js APIs. Workers isn't Node. fs, path, crypto (partially) don't exist. I had to replace bcrypt with WebCrypto subtle.digest. Took 3 hours of "why is this undefined" debugging.
No persistent connections. WebSockets need Durable Objects (paid tier). I punted and used polling. Users didn't notice, but it felt dirty.
KV consistency. KV is eventually consistent. I wrote a session token, immediately read it back, got null. Spent 2 hours thinking my code was broken. It wasn't — KV just hadn't propagated. Solution: write to KV, return the value from memory, don't re-read.
10ms CPU limit. Image resizing hit the limit. Had to move that to a queue + consumer Worker. More architecture, more moving parts.

The One Feature That Almost Made Me Switch Back

Preview deployments. Vercel's git-integration previews are magical: push a branch, get a URL, share it. Cloudflare has previews too, but they're per-branch and require Wrangler CLI setup. It's fine for me, but my non-technical co-founder couldn't figure out how to preview a change. Vercel's DX is genuinely better here.

The Uncomfortable Math

Cloudflare Workers free tier is 100,000 requests/day. Vercel Hobby is 100GB bandwidth. These sound comparable until you realize:

A single API response is ~2KB. 100,000 requests = 200MB/day = 6GB/month.
Vercel counts bandwidth, Cloudflare counts requests.
My app is API-heavy, small payloads. Cloudflare wins.
If I were serving video or large images, Vercel's bandwidth model might actually be cheaper.

The free tier that's better depends entirely on your payload shape. Nobody talks about this.

Would I Do It Again?

Yes, but with eyes open. The 6-month savings ($240) funded my domain renewal and a year of Proton Mail. The tradeoff is DX — I miss Vercel's polish, but I don't miss the invoice.

I sketched the migration checklist and the KV consistency workaround with MonkeyCode: https://ly.cyberserval.tech/iIETXiF

What's your free tier horror story? The one where you hit a limit at 2am and had to frantically upgrade?

Quick Tip — Find Every Wi-Fi Password Saved on Your Machine with Python (10 Lines, No Admin Tools)

niuniu — Thu, 20 Aug 2026 04:44:56 +0000

Quick one today. I needed the Wi-Fi password for an AP I set up months ago. The Windows GUI path is: Settings → Network → Status → Properties → scroll → Security → Show characters. Five clicks, per network.

This script does it in one run:

import subprocess, re

out = subprocess.run(["netsh", "wlan", "show", "profiles"],
                     capture_output=True, text=True).stdout
profiles = re.findall(r"All User Profile\s+:\s(.+)", out)

for name in profiles:
    name = name.strip()
    detail = subprocess.run(["netsh", "wlan", "show", "profile", name, "key=clear"],
                            capture_output=True, text=True).stdout
    pw = re.search(r"Key Content\s+:\s(.+)", detail)
    print(f"{name:30} {pw.group(1) if pw else '(open network)'}")

Example output:

HomeNet-5G                     CorrectHorseBatteryStaple
CoffeeShop-Guest               (open network)
Airport-Lounge                 flyfree2026

Two gotchas:

Run it as the same user who saved the profiles — netsh only shows what your account can see.
On Linux/macOS this doesn't apply — Linux keeps them in /etc/NetworkManager/system-connections/ (needs root), macOS wants security find-generic-password -ga "SSID".

I keep this in a bin/ folder alongside other tiny scripts. Half of them were drafted with MonkeyCode, which is free for this kind of quick utility writing: https://ly.cyberserval.tech/iIETXiF

What's the smallest script you actually use weekly? Mine's probably a 3-liner that renames screenshot files by date.

I Replaced GitHub Copilot with Continue.dev + a Local Model for 60 Days — My Code Didn't Get Worse, My Wallet Got Happier

niuniu — Thu, 20 Aug 2026 04:44:10 +0000

I cancelled my $10/month GitHub Copilot subscription two months ago. Not because of the money — $10 is coffee money — but because I realized I was sending every keystroke in proprietary client code to a cloud API, and the contract I just signed had opinions about that.

So I went full local: Continue.dev (open-source VS Code/JetBrains extension) + Ollama running Qwen2.5-Coder-7B on my RTX 4060 8GB. Here's what 60 days of real usage looked like.

The Setup (15 minutes, $0)

# 1. Ollama
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5-coder:7b

# 2. Continue.dev — install from VS Code marketplace, then ~/.continue/config.json:
{
  "models": [{
    "title": "Qwen Coder Local",
    "provider": "ollama",
    "model": "qwen2.5-coder:7b"
  }],
  "tabAutocompleteModel": {
    "title": "Qwen Autocomplete",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b"
  }
}

Trick: use the 7B model for chat/edits but the 1.5B for tab autocomplete — autocomplete needs to fire in <200ms or it feels broken, and the small model does ~45ms on a 4060.

The Numbers I Tracked

I logged every suggestion for 60 days (Continue has a built-in dev data export):

Metric	Copilot (before)	Continue + Qwen (local)
Tab suggestion acceptance rate	31%	24%
Median autocomplete latency	~180ms (network)	~45ms (local)
Chat "good answer" rate (my judgment)	~85%	~70%
Cost / 60 days	$20	$0 (+~$3 electricity)
Keystrokes leaving my machine	100%	0%

Where Local Actually Won

Latency. 45ms local vs ~180ms network means autocomplete appears before I finish thinking, not after. This is underrated — it's the difference between "tool" and "annoyance".
Airplane mode. I wrote a full FastAPI feature on a train with no wifi. Copilot is a brick offline.
Privacy review. Client's security team asked "does your tooling exfiltrate code?" Answer went from a paragraph of caveats to "no."

Where It Lost (Honest Part)

Big refactors. "Rename this concept across 40 files and update the tests" — Copilot's larger models handle the cross-file context noticeably better. Local 7B starts hallucinating file contents after ~4 files.
Obscure APIs. Asked both to write code against a niche payment provider's SDK. Copilot knew it. Qwen confidently invented methods that don't exist. Twice.
The 8GB VRAM ceiling. I can't run the 32B coder model without swapping. If you have 16GB+ VRAM this whole article gets more optimistic.

The Verdict

Acceptance rate dropped 7 points, but latency improved 4x and cost dropped to zero. For my mix (mostly Python/TS business logic, tests, boilerplate) local is a net win. For heavy greenfield work against unfamiliar APIs, I'd keep a cloud tool on standby.

The uncomfortable conclusion nobody in the "local AI" echo chamber says out loud: a 7B local model is 2024-Copilot, not 2026-Copilot. It's good enough that you stop paying, not good enough that you stop noticing.

I did the initial config and the acceptance-rate logging script with MonkeyCode (free tier) before moving fully offline — handy for the scaffolding phase: https://ly.cyberserval.tech/iIETXiF

Would you trade a 7-point acceptance drop for zero data leaving your machine? Or is the quality gap still a dealbreaker for you?

I Let Dify Build My AI Workflow for a Week — Then I Replaced Half of It with 80 Lines of Python

niuniu — Wed, 19 Aug 2026 04:19:54 +0000

My team lead bet me I couldn't ship our internal "summarize support tickets → route to the right queue" tool faster with Dify than with hand-written LangChain.

He was half right.

The setup

Same task, two implementations, one week:

Dify: visual workflow, drag nodes, connect an LLM, a classifier, a webhook
Hand-rolled: ~80 lines of Python with openai + pydantic + a simple router

I timed both and tracked where each one broke.

Where Dify genuinely won

Task	Dify	Hand-written
First working prototype	47 minutes	~4 hours
Non-dev teammate edits the prompt	✅ self-serve	❌ needs me
Swapping LLM provider	dropdown	code change + redeploy
Built-in logging/observability	✅ out of the box	I had to add it

For "get something working by Friday," Dify isn't close — it's just faster.

Where Dify quietly cost me

By day 3, I hit the walls:

Branching logic beyond ~3 conditions becomes spaghetti. My ticket router has 7 categories with nested rules. The visual canvas turned into a plate of noodles. In Python it's a match statement.
Version control is awkward. Dify exports a YAML blob. Diffing "what changed in the prompt last Tuesday" is painful vs git log on a .py file.
Latency. Each Dify node is an HTTP hop internally. End-to-end: ~2.1s. My 80-line script: ~900ms. At our volume that's the difference between "instant" and "why is this slow."
Debugging a failed run means clicking through a UI vs reading a stack trace.

What I actually shipped

The uncomfortable answer: both.

Dify handles the classify-and-route flow (stable, rarely changes, non-devs tweak prompts)
Python handles the summarization + formatting (complex logic, changes weekly, needs tests)

Total Dify canvas: 6 nodes. Total Python: 83 lines. Each does what it's good at.

The real lesson

"No-code vs code" is a fake fight. The honest question is "which parts of this workflow change often, and who changes them?"

Changes often + changed by engineers → code
Stable + tweaked by non-engineers → Dify

If you're picking one tool for everything, you're optimizing for the wrong thing.

Have you shipped a hybrid like this, or are you all-in on one side? I want to hear where the hybrid approach breaks down at bigger scale.

The Python half was written with MonkeyCode — free, open-source AI coding: https://ly.cyberserval.tech/iIETXiF

Quick Tip — Query a Postgres Database from Python in 6 Lines (No ORM, No Boilerplate)

niuniu — Wed, 19 Aug 2026 04:19:07 +0000

Most Python+Postgres tutorials drag you through SQLAlchemy sessions, engines, and models before you can run a single SELECT. For scripts, cron jobs, and quick data checks, that's overkill.

Here's the pattern I use daily — 6 lines, real dict results, automatic cleanup:

import psycopg
from psycopg.rows import dict_row

with psycopg.connect("postgresql://localhost/mydb", row_factory=dict_row) as conn:
    with conn.cursor() as cur:
        cur.execute("SELECT id, email, created_at FROM users WHERE active = %s", (True,))
        for row in cur.fetchall():
            print(row["email"], row["created_at"])

Why this works well

dict_row gives you {"id": 1, "email": "..."} instead of tuples — no more row[0] guessing
Both with blocks auto-commit on success, auto-rollback on exception, and always close the connection
%s placeholders are parameterized — no string formatting, no SQL injection
psycopg (v3) is the modern driver; psycopg2 is in maintenance mode

One gotcha

psycopg v3 needs the binary extra on some platforms:

pip install "psycopg[binary]"

Without it you'll get a confusing ImportError: no pq wrapper available.

What's your go-to for quick SQL from Python — raw psycopg, SQLAlchemy, or something like records / databases? Curious what's winning in 2026.

Tip tested with MonkeyCode, a free open-source AI coding assistant: https://ly.cyberserval.tech/iIETXiF

I Ran My Whole Side Project on Cloudflare's Free Tier for 90 Days — AWS Would Have Cost Me $847

niuniu — Wed, 19 Aug 2026 04:18:20 +0000

Three months ago I moved my side project (a small SaaS with ~2,000 monthly users) off a $47/month AWS setup onto Cloudflare's free tier. I expected to hit a paywall within two weeks.

Ninety days later, my total Cloudflare bill is $0.00. The AWS bill I avoided: $847 (I kept the old stack running in parallel for a month to compare, then killed it).

Here's the actual breakdown.

What I'm running

Workers (API + backend logic): free tier = 100,000 requests/day
Pages (frontend): unlimited static requests, 500 builds/month
R2 (file storage): 10 GB storage, 10M Class B operations/month
D1 (SQLite database): 5M rows read/day, 100K rows written/day
KV (session cache): 100K reads/day, 1K writes/day

My real usage (average day, last 30 days):

Service	Free limit/day	My usage/day	Headroom
Workers requests	100,000	31,400	3.2x
D1 rows read	5,000,000	412,000	12x
D1 rows written	100,000	8,700	11.5x
R2 storage	10 GB	3.1 GB	3.2x
KV reads	100,000	22,000	4.5x

What the same thing costs on AWS

I ran the equivalent setup (EC2 t3.small + RDS db.t3.micro + S3 + CloudFront + ALB) for 30 days in parallel:

EC2 t3.small: $15.18
RDS db.t3.micro: $13.14
ALB: $17.20
S3 + CloudFront + data transfer: $36.50
Route53 + misc: $1.80

Total: ~$84/month × 3 months = $252. Add the months before this experiment and I'm at $847 spent on infra that Cloudflare now handles for free.

The honest catches

This isn't a "Cloudflare is magic" post. Real limitations I hit:

D1 is SQLite. No concurrent writes worth mentioning. Fine for a SaaS with 2K users, dead on arrival at 50K.
Workers CPU limit: 10ms on free tier. I had to move a PDF-generation endpoint to a $5/mo Hetzner box. That endpoint alone would have blown the limit.
Cold starts on D1 are real — first query after idle: ~80ms vs ~8ms warm. Noticeable in a snappy UI.
No WebSockets on free Workers. I use SSE instead, which is fine for my use case.

My takeaway

The uncomfortable truth: for most side projects, AWS is a resume decision, not a technical one. We pick it because it looks serious, not because the workload demands it.

If your app fits in Cloudflare's free tier — and a surprising amount does — you're paying $80+/month for the feeling of being "production grade."

What about you — have you actually priced out what your side project would cost on a free tier, or are you (like past me) just defaulting to AWS because that's what serious projects use?

I sketched the migration plan and the D1 schema with MonkeyCode — free, open-source AI coding assistant: https://ly.cyberserval.tech/iIETXiF

I Switched from GitHub Copilot to Continue.dev + Ollama for 30 Days — My Code Never Left My Laptop

niuniu — Tue, 18 Aug 2026 03:57:09 +0000

On July 17th I cancelled GitHub Copilot and set a rule: 30 days, local models only, no cheating. Here's the honest report.

The setup (10 minutes)

# 1. Install Ollama and pull a code model
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5-coder:7b

# 2. Install Continue.dev extension in VS Code, then configure:

// ~/.continue/config.json
{
  "models": [
    {
      "title": "Qwen Coder (local)",
      "provider": "ollama",
      "model": "qwen2.5-coder:7b"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Autocomplete",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b"
  }
}

Two models: the 7B for chat/edit, the 1.5B for tab autocomplete (fast enough to not feel laggy).

30 days of real numbers

Metric	Copilot (before)	Continue + Ollama (30 days)
Monthly cost	$10	$0
Autocomplete latency	~300ms	~180ms (M-series, 16GB)
Accept rate (my estimate)	~35%	~25%
Offline on a plane	No	Yes (tested, 2 flights)
Code privacy	Sent to cloud	100% local

What broke (honesty section)

Day 4: 7B chat responses were noticeably dumber than Copilot chat on a gnarly regex refactor. I waited 20s for a wrong answer. Almost cheated.
Day 9: Battery life took a real hit — local inference on a laptop costs ~1.5h of unplugged time.
Day 15: The breakthrough. Once I switched autocomplete to the 1.5B model and reserved the 7B for deliberate "explain/refactor this" calls, the workflow clicked. Latency complaints vanished.

The uncomfortable conclusion

Copilot's moat in 2026 isn't the model — it's the zero-config polish. Continue.dev + Ollama is 90% of the experience for $0 and full privacy, but you pay with one evening of setup and occasional model babysitting.

For the agent-style multi-file work that local 7B models still can't do well, I use MonkeyCode — free and open-source, and it doesn't require me to hand my whole repo to a cloud API: https://ly.cyberserval.tech/iIETXiF

Would you trade 10% completion quality for $120/year and never sending your code to anyone's server? Or is cloud convenience worth the privacy cost?