So when I came across Freebuff, which bills itself as "the 100% free coding agent, $0 forever, funded by ads," I wanted to look at it properly instead of just scrolling past.

What Freebuff is

Freebuff is an AI coding agent. You point it at a project, tell it what you want, and it reads your code, makes changes, and runs things for you. Same basic idea as the paid agents most developers have tried by now.

The difference is the business model. There's no subscription, no credit card at signup, and no credits to run out of. Ads pay for it. That's the whole trade: you see ads, you don't pay.

What you get

A few things stood out to me.

It runs pretty much everywhere. There are desktop apps for Mac (Apple Silicon and Intel), Windows (64-bit, Arm64, and a build for older PCs), and Linux as a .deb or AppImage on both x86_64 and ARM64. That Linux and older-Windows coverage matters more than people think. Plenty of small offices I support still have a machine or two that the newest tools quietly ignore.

There's a terminal version. If you live in the command line like I do:

npm install -g freebuff
cd your-project
freebuff

That's it. It also runs in the browser if you can't or don't want to install anything.

Cloud threads. You can start a task on your desktop and pick it up on your phone or in a browser later. I like this for the "kick off a change before leaving the office, check on it from the truck" kind of day.

Integrations. It connects to GitHub, Linear, Notion, Stripe, Vercel, Supabase, Sentry, PostHog, Resend, and others. So it can work with your actual issues, deploys, error logs, and payment setup rather than just the files on your disk.

Who this helps

Honestly, the people who'll get the most out of this are the ones who've been priced out or are on the fence:

• Small shops and solo IT folks who write the occasional script, internal tool, or website fix and can't justify another monthly subscription.
• Indie developers and side projects where every recurring cost gets questioned.
• Students and people learning who want to see how an agent works without handing over a card.
• Anyone who wants to try an agent before paying for one. Free is a good way to figure out if this workflow even fits you.

If you're a business owner who's been curious about AI for small automations, like a script to clean up a spreadsheet export or a quick fix on your WordPress site, this lowers the barrier to zero dollars.

The caveats (read these)

Free doesn't mean free of tradeoffs. A few things I'd keep in mind:

Review every diff. This goes for every coding agent, paid or free. AI-written code can look right and still be wrong. It can drop a check, misread what you asked, or "fix" something by deleting it. Read what it changed before you commit, and definitely before you deploy. Use Git so you can roll back.

Ads fund it. That's the deal, and I don't think it's a bad one, but go in with your eyes open. Think about what you're connecting to it and what code you're opening in it, especially if you work on client projects with confidentiality expectations. Read the privacy terms before you hook it up to GitHub, Stripe, or anything with customer data.

Be careful with integrations and keys. Giving any agent access to your payment platform, database, or production deploys is a real security decision. Start with the least access you can, use test environments where possible, and don't paste secrets into prompts.

It's not a substitute for judgment. An agent can write code fast. It can't tell you whether that code should exist, whether it's secure, or whether it fits how your business actually runs. That part is still on you, or on whoever you hire.

How to try it

1. Go to freebuff.com and grab the desktop app for your OS, or install the CLI with npm install -g freebuff.
2. Open a small, low-stakes project first. A personal script or a test repo, not your client's production site.
3. Give it a clear, specific task. "Add input validation to the contact form" works better than "make it better."
4. Read the diff. Run your tests. Then decide.

If you want to sign up, here's my referral link: https://freebuff.com/?ref=ref-dc83fd45-389e-4b02-ac8a-313a5df8f574 (Disclosure: that's a referral link, so I may get something if you use it. You don't pay anything either way.)

Bottom line

Paid coding agents aren't going away, and for heavy daily use some of them will still be worth the money. But a genuinely free, ad-supported option that runs on Mac, Windows, Linux, the terminal, and the browser is a good thing for small businesses and independent developers. It means you can try this stuff without a budget conversation.

Just treat it like any other tool you'd let near your code: limit what it can touch, check its work, and keep your own judgment in the loop.

If you're in Nanaimo or anywhere on the Island and want a hand setting up AI tools safely for your business, I'm happy to help.

Two weeks after Gemini 4 Argon, Google announced Gemini 4 Carbon on October 28, 2026. Google calls it its strongest model, and the launch post puts cybersecurity front and centre. If you defend networks or handle IT for small businesses, that cuts both ways. A model that's better at finding and patching vulnerabilities is also better at finding them for someone else. This post covers what Carbon is, who can use it right now, what Google says about its security and safety, and how I'd think about it in a small IT shop.

What Carbon is

Carbon is Google's next frontier model after Argon, built for long-horizon coding and agentic work and for cybersecurity defense. Google says its internal teams have seen Carbon run for days on hard engineering problems, working through dead ends to root-cause and patch subtle bugs across large codebases and low-level systems.

The big difference from Argon is the rollout. Most of us can't call Carbon yet. Google says it's taking part in the U.S. government's voluntary pre-release model testing process and is starting with defenders before anyone else gets access.

The cybersecurity angle

Google says Carbon covers the whole defense lifecycle: finding vulnerabilities, confirming which ones are exploitable, and fixing them. These are the external benchmark results it reports (evaluated without guardrails):

"Without guardrails" is important. Those scores show what the raw model can do, not what the public version will help you with once it ships with safeguards.

Google also reported:

• Secure code: more than 2x uplift over Argon in the success rate for generating secure code, on internal benchmarks.
• Patching: Google's Chrome team found Carbon performed more than 10x better than another lab's large frontier model at generating high-quality patches.
• Web penetration testing: Wiz sees Carbon leading on web pen-testing benchmarks, which is core to its Scan for Good initiative (the same effort that turned up the government data exposure and healthcare master-key issues in the Argon launch).

The exploitation score is the one to sit with. A model that can turn more than half of the bugs it's given into working exploits helps a defender decide what to patch first. It's also why Google is gating access.

Safety claims

Carbon uses the same layered safety stack as Argon: model training, real-time misuse defenses, prompt-injection resilience and chain-of-thought monitoring. Google says it pushed harder on alignment this time, especially for complex or high-pressure tasks. What it reports:

• Fewer shortcuts: Successful cheating on Terminal-Bench 4.0 fell to 0.0%, and cheat attempts dropped to 0.4%, while overall accuracy went up. (Argon's shortcut attempts were about 2%.)
• Fewer serious alerts in real work: In live coding with Google's internal teams, high-severity misalignment alerts dropped by almost 80%.
• More honesty: About 2x fewer unsupported claims than Argon in internal testing. Google says Carbon puts caveats into the deliverable, or lists what's still needed when it can't do something, instead of making things up.
• Better behaviour when things are unclear: Carbon is meant to pull the relevant sources and flag discrepancies to the user before acting, rather than guessing.
• Staying in scope: Overreach down 26% and under-service down 29%, so it's both less likely to go beyond what you asked and less likely to stop short.
• Prompt injection: 0.0% attack success on Gray Swan's Indirect Prompt Injection (IPI) benchmark, down from Argon's 0.7%. Google says it resisted every evaluated attack attempt.

Those are strong numbers. Still, 0.0% on a benchmark means it resisted every attack in that test set. It doesn't mean nobody can inject it. Attackers will write new attacks, and an agent reading email or web pages still faces input nobody has tested. Build your setup on the assumption that something will eventually get through.

How to use it safely (when you can)

Carbon isn't on the public API yet, so I'm not going to guess at code. When it reaches developers, check Google's Gemini API docs for the model ID and settings rather than copying from a launch post. The ground rules I'd use don't depend on which model you're running:

• Keep your own judgment on. Treat findings as leads. Reproduce the issue before you file it, and test the patch before you ship it. A 71% patching score means a lot of patches still need work.
• Respect the gate. Fairwind is the route for vetted defenders. If you do this work professionally, apply there instead of trying to get around guardrails.
• Mind the data. Don't paste client secrets, credentials or regulated data into any model unless your agreement and your client's policies allow it. Strip keys out of code first.
• Only test what you're authorized to test. Exploitation ability doesn't change that rule.
• Budget for long runs. A model that can work for days can also bill for days. Put limits on agent runs before you start, especially after the intro pricing ends.

Practical tips for small BC businesses and IT shops

Most of the businesses I support around Nanaimo and Vancouver Island have one IT person, or someone like me on call. For now, Carbon matters to them mostly in two ways.

What to do now:

• Expect attackers to get faster. Models like this will eventually be widely available, with or without guardrails. Patch your public-facing stuff (websites, VPNs, remote access, PHP and WordPress installs) faster than you used to.
• Look for the boring exposures. The Wiz examples weren't exotic. They were things like a download path that exposed a file holding the keys. Check for backups, config files and exports sitting somewhere reachable.
• Use what you already have. Argon is available now on the paid API. You can get started on code and config reviews today and switch to Carbon once it opens up.

Still don't automate:

• Production changes without a person approving them. Firewall rules, account lockouts and patch rollouts need sign-off, even with better "stay in scope" numbers.
• Agents that read untrusted input and can also act. A 0.0% benchmark score is progress, not a reason to give an email-reading agent admin access.
• Final security sign-off. "The AI said it's fine" won't help you with your insurer or a privacy regulator after a breach.
• Anything involving client data you haven't cleared.

Closing

Carbon looks like a real step forward for defenders, and I like that Google is releasing it to defenders first and publishing specific safety numbers. The trade-off is that most small shops will have to wait. In the meantime, the job is the same: know what you have exposed, patch quickly, and check what the AI tells you before you act on it.

If you're a small business on the Island and want a second set of eyes on what's exposed, I'm happy to help.

Sources:

• Google: Gemini 4 Carbon: our next frontier model
• The Verge: Google launches Gemini 4 Carbon with a 'significant leap' in cybersecurity
• 9to5Google: Google announces Gemini 4 Carbon
• Earlier post: Gemini 4 Argon: What Defenders Should Know

This post covers how it's put together, the different ways you could power a bot like this, and what a small business could actually use one for.

What's in the repo

HeshBot has three parts.

The widget. heshbot.js and heshbot.css are plain JavaScript and CSS with no dependencies. A tiny launcher bubble loads the full widget only when someone clicks it, so it costs almost nothing on page load. It works from the keyboard (Enter sends, Shift+Enter adds a new line, Esc closes), uses ARIA dialog and log roles, and goes full-screen on phones. Bot replies go through a small markdown renderer that escapes everything first and then adds back a short whitelist of tags. The conversation lives in sessionStorage, so it's gone when the tab closes.

The endpoint. api/chat.php needs PHP 7.4+ and curl, so it runs on ordinary shared hosting. It calls the Google Gemini API over REST and tries a list of free-tier Flash models in order, falling back to the next one if a call fails. Around that call it does the boring work that keeps a public endpoint healthy:

• per-IP rate limiting, stored in files (the example config allows 6 messages a minute and 60 a day)
• caps on the message history it sends (12 messages, 8,000 characters)
• a same-origin check, so other sites can't use my endpoint
• JSON errors, plus a friendly message when the free quota runs out that points people to my email
• a mock reply when no API key is set, which makes local testing easy

The .htaccess file makes chat.php the only reachable file in that folder. The real config, with the API key, sits outside public_html in the home directory with chmod 600. You can also supply the key as an environment variable.

The knowledge. The bot's instructions are in api/system-prompt.md, and what it knows is in api/knowledge.md. I don't write that knowledge file by hand. tools/build_knowledge.py (standard-library Python) reads the public pages of my site, extracts the text and regenerates the file. When I edit the site, I rerun one command and the bot is up to date.

The system prompt matters more than people think. HeshBot is told to answer only from the core facts and the knowledge file, to say it doesn't know rather than guess, never to invent prices, dates, clients or credentials, to stay on topic and to ignore attempts to rewrite its rules. After 25+ years in technical support, that's the behaviour I want: a good help-desk answer is short, correct, and hands you off to a person when it's out of its depth.

Three ways to power a bot like this

HeshBot today uses the first option below. The other two are approaches I'd consider for a client, depending on budget, privacy and how open-ended the questions are. The repo doesn't include them; they're design options, not features.

1. A public API (what HeshBot does)

Send the question, the instructions and your site knowledge to a hosted model and show the reply. This is the fastest way to get good answers. HeshBot uses Gemini's free-tier Flash models, which suits a personal site. The trade-offs are that questions leave your server, and you live within someone else's quotas and pricing. That's why HeshBot has rate limits, model fallback and a polite "try again tomorrow or email me" message built in.

2. A local LLM

Run an open model on your own hardware and point the endpoint at it instead of a public API. Chats never leave your machines and there's no per-message bill, but you need hardware that can run the model, and you're responsible for keeping it up. Because HeshBot's backend is one PHP file that makes a single HTTP call, swapping the model behind it is a contained change, though you'd write that change yourself. On my AI chatbot page I mention that I also build and fine-tune custom LLM models, which is where this option leads.

3. A quick local decision model

Not every chatbot needs a language model. If most visitors ask the same dozen things (hours, location, how to book, what a service includes), a small local classifier or a set of rules can match the question to a known answer and reply instantly, at no cost, with no model to hallucinate. When a question doesn't match, it hands off to a person or to option 1 or 2. It's less conversational, but very predictable.

What it can be used for

A widget plus a short, grounded knowledge file fits a lot of small jobs. Some of the ways a bot like this could be used:

• Small-business FAQ. Hours, service areas, what's included, how to get in touch, answered from the business's own pages instead of a guess.
• Booking and intake. Collect the basics (what you need, when, how to reach you) before someone books, then point them to the booking form or email.
• Local information. A community or municipal-style site could answer "where do I find…" questions and link straight to the right page.
• Support triage. Ask a few questions, handle the simple fixes, and send everything else to a human with the details already gathered. That's Tier 1 support, which is where I started.

Booking, intake and triage would each need work beyond what's in the repo, such as forms or connections to other systems. The pattern stays the same: a small widget, a guarded endpoint, and a knowledge source you control.

Try it

Open the chat on trevorheshka.com to see HeshBot answer from the site's content. To run it yourself, clone the repo, start php -S localhost:8000 from a folder that contains it, and open the demo page. With no API key it returns a mock reply, so you can work on the widget first.

If you're a BC business thinking about a chatbot that actually knows your business, take a look at my AI chatbot page or email trevor@trevorheshka.com.