Chuyển đến nội dung chính

Free AI coding agents: how to use OpenCode's free models without regretting it

The barrier to trying an AI coding agent used to be an API key and a credit card. OpenCode removed both: its Zen gateway ships hosted models you can select and start using immediately, at no cost and with no key.

Which means the last excuse for not learning how agentic coding works is gone. It also means a lot of people are about to point a free model at a private repository without thinking about what that involves.

Both things are worth taking seriously. Here’s what the free tier is actually good for, what it costs you in a currency that isn’t money, and how to structure your work so you’re not paying for a frontier model to rename variables.

What “free” means here

Three separate things get bundled under the word, and they have different limits:

The tool is free. OpenCode itself is open source. There’s no cap on the client, no seat licence, no metering. Bring your own API key from any provider and it behaves like any other agent harness.

The hosted models are free with a quota. OpenCode Zen is the built-in gateway. Its free tier runs at $0/month with roughly 100 requests per day, no credit card, access to the Zen model lineup. The models are grouped into tiers rather than sold individually — a default tier with large context, an advanced tier with the largest context window, and a fast tier with a small context window and much lower latency.

Free is not unlimited, and it is not private. Those are the two things people skip, and they’re the two that matter.

The quota is smaller than it sounds

100 requests a day sounds generous until you watch an agent work. A single “fix this failing test” can burn five to fifteen requests as the agent reads files, runs the suite, edits, re-runs, and reads the error again. Agentic loops consume requests in bursts.

Practically: expect a handful of real tasks per day, not a full workday of continuous agent use. That’s fine for learning. It is not a workflow you can commit to a deadline.

Your code is the other price

This is the part that deserves a flat statement rather than a footnote: on the free tier, prompts and completions are generally retained and used to improve future models. That is the business model. One model in the lineup is documented as never storing or training on your data — if privacy is the requirement, that’s the one to check for and verify against the current docs, because these policies change.

There’s a saying that gets repeated here — if you’re not paying for the product, you’re the product — and in this case it’s not a metaphor. The payment is your code.

Note also that model names and free-tier composition churn fast. The lineup shifted twice in the months before this was written. Treat any specific model name you read in a blog post, including this one, as a snapshot. Check the Zen model list for what’s actually free today, and check the data policy at the same time.

What never goes into a free-tier model

Not a vague “be careful.” A list:

  • Credentials of any kind — API keys, tokens, passwords, connection strings, .env contents, private keys
  • Private source you don’t own the disclosure rights to — employer code, client code, anything under NDA
  • Customer data — real user records, PII, anything from a production database
  • Internal documents — architecture docs, contracts, roadmaps, incident write-ups
  • Anything under a compliance regime — health, financial, or regulated data

The rule underneath: if you’d need permission to email it to a stranger, don’t paste it into a model whose retention policy you haven’t read.

One trap specific to agents rather than chat: an agent reads files you didn’t explicitly hand it. Point it at a repo root and it may read .env, config/secrets.yml, or a fixture full of real customer records — none of which you meant to send. Chat models only see what you paste; agents see what they open.

So before running any agent, free or paid, on a repo you didn’t create for the purpose:

git ls-files | grep -Ei '\.env|secret|credential|\.pem$|\.key$|token'

Anything that turns up should be in .gitignore, in an ignore file the agent respects, or moved out of the tree entirely.

The escalation ladder

The useful mental model isn’t free-versus-paid. It’s three tiers, matched to what a task actually needs:

TierUse it forWhy
FreeLearning the tool, side projects, throwaway scripts, exploring an unfamiliar codebase, bulk mechanical editsZero cost, and the failure mode is a wasted retry
Paid midReal work — daily feature development, bug fixing, refactors, reviewReliability and rate limits you can plan around; data handling you can point at in writing
FrontierGenuinely hard problems — subtle concurrency bugs, architecture decisions, large multi-file refactors, anything where being wrong is expensiveCosts real money per task; worth it exactly when a wrong answer costs more

Most people get this backwards in both directions. They run frontier models on boilerplate, and they run free models on the gnarly bug that’s eaten two days. Both waste money — one in tokens, one in your time.

The tell for escalating: if you’ve re-prompted three times and the answer is still wrong in the same way, the model isn’t the bottleneck you think it is. Either escalate a tier, or — more often — your prompt is missing context the model can’t infer. Try the context first; it’s free.

Getting genuinely useful work out of a free tier

Free models are smaller and less patient. Adapt the work to fit rather than expecting them to behave like a frontier model.

Give it a smaller job. “Refactor the auth module” is a frontier-model task. “In auth/session.py, extract the token-refresh logic into its own function and update the two call sites” is a free-model task. Smaller scope also burns fewer requests, which matters when you have a hundred.

Point at files explicitly. Letting an agent discover which files matter costs requests and often goes wrong with a smaller model. Naming the three files it needs saves both.

Batch mechanical work. Renames, adding type hints, converting a test suite from one assertion style to another, writing docstrings from existing signatures — this is exactly what free models are good at, and the results are cheap to verify.

Read a codebase with it. One of the best uses of a free tier is asking a fast model to explain an unfamiliar repo. “Trace what happens when a request hits /api/orders” is low-risk, high-value, and doesn’t need frontier reasoning.

Use the fast tier for fast things. The small-context fast tier is genuinely better for quick lookups and single-file edits than the big-context tier — lower latency, and context you don’t use is context that can distract.

The other free option

Worth knowing about: Hermes Agent is also free and works over messaging — you drive the agent from Telegram or Discord rather than a terminal. Different ergonomics entirely. If the appeal is kicking off a task from your phone and reading the result later, that’s a better fit than a CLI. The same data-handling caution applies, with an extra wrinkle: a chat platform keeps its own copy of everything you send.

A starting setup that won’t burn you

  1. Install OpenCode. Setup is genuinely a couple of minutes.
  2. Start on a repo you own and that contains nothing confidential. Not the work monorepo. A side project.
  3. Check the current free lineup and its data policy at opencode.ai/zen before your first real task, not after.
  4. Run the secret sweep above on any repo before pointing an agent at it.
  5. Do three real tasks — a bug fix, a small refactor, an explain-this-code session. That’s enough to know whether the tool fits how you work.
  6. When you find yourself relying on it, move to a paid mid-tier model. The moment agent output goes into work someone pays for, both the rate limit and the retention policy stop being acceptable.

Step 6 is the one people postpone, usually until a rate limit hits mid-sprint. Move before that, not after.

The honest summary

The free tier is an excellent way to learn and a bad way to ship. That isn’t a criticism — it’s what a free tier is for, and OpenCode is unusually upfront about the trade.

Learn on free. Work on paid. Escalate to frontier only when a task is genuinely hard. And read the retention policy before the first prompt, not after you’ve pasted something you can’t unpaste.

FAQ

Is OpenCode itself free, or just the models? The tool is open source and unmetered. Zen’s free tier is the hosted-model part, with a daily request cap. You can also plug in your own API key from any provider.

How many requests do I actually get? The free tier is documented at roughly 100 requests per day. Agent loops consume several requests per task, so plan on a handful of substantial tasks rather than continuous use.

Is my code used for training? On the free tier, generally yes — prompts and completions are retained and used to improve models. At least one model in the lineup is documented as excluded from this. Verify against the current docs, because these terms change.

Can I use it for client work? Not on a free tier with a training-retention policy, unless the client has explicitly agreed in writing. Use a paid tier with contractual data handling.

Which free model should I start with? Start on the default tier for general coding, switch to the advanced tier when a task needs more context or more reasoning, and use the fast tier for quick single-file work. Specific model names change often — check the current list rather than trusting any blog post, including this one.

Is a free model good enough to learn agentic coding? Yes, and that’s the strongest argument for it. Learning how to scope tasks, supply context, and verify output transfers completely to paid models. The skill is the durable part, not the model.


This piece expands on a note circulating in Vietnamese developer communities about OpenCode’s free models, whose central warnings — free isn’t unlimited, your data trains the next model, never paste secrets — are the right ones. Model names and quotas here reflect what was published at the time of writing and change frequently; the links go to the current source of truth.


Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Nhận xét

Bài đăng phổ biến từ blog này

Thiết kế giao diện với DotNetBar (Phần 1)

Đây là phiên bản DotNetBar hỗ trợ C# và Visual Basic https://www.dropbox.com/s/wx80jpvgnlrmtux/DotNetBar.rar  , phiên bản này hỗ trợ giao diện Metro cực kỳ “dễ thương” Các bạn load về và cài đặt, khi cài đặt xong sẽ có source code mẫu của tất cả các control. Để sử dụng được các control của DotNetBar các bạn nhớ add item vào controls box. Thiết kế giao diện với DotNetBar, giao diện sẽ rất đẹp. Link các video hướng dẫn chi tiết cách sử dụng và coding: http://www.devcomponents.com/dotnetbar/movies.aspx Hiện tại DotNetBar có rất nhiều công cụ cực mạnh, trong đó có 3 công cụ dưới đây: DotNetBar for Windows Forms Requires with Visual Studio 2003, 2005, 2008, 2010 or 2012.   DotNetBar for WPF Requires with Visual Studio 2010 or 2012 and Windows Presentation Foundation.   DotNetBar for Silverlight Requires with Visual Studio 2010 or 2012 and Silverlight. Dưới đây là một số hình ảnh về các control trong DotnetBar.   Metro User Interface  controls with Metro Tiles, toolba...

5 concepts every Flutter dev should know

  Phụ lục: State management architecture Testing IDE Shortcuts Platform channel Maintaining a project Tôi đã làm việc với Flagship trong một thời gian dài, và đây là những điều mà tôi phát hiện ra là điều cần phải có đối với bất kỳ nhà phát triển Flagship nào, về tổng thể nó sẽ khiến bạn trở thành một nhà phát triển Flagship giỏi trong thời gian dài. 1. State management architecture Đây là một trong những chủ đề quan trọng nhất trong cộng đồng thiết bị rung, nó khá quan trọng nếu bạn muốn duy trì một dự án rung kích thước trung bình hoặc lớn. Nó sẽ giúp tạo một dự án suôn sẻ và thêm các tính năng mới một cách hoàn hảo.  2. Testing Đây là một chủ đề duy nhất mà tôi không hiểu tại sao nó lại quan trọng trước đó trong sự nghiệp của tôi, nhưng khi tôi tiến lên trong sự nghiệp của mình và có kinh nghiệm với nhiều dự án và vấn đề xảy ra trong môi trường sản xuất. Tôi đã nhận ra một cách khó khăn, tại sao điều này lại quan trọng như vậy. Nếu bạn vẫn muốn có thêm lý do để cân nhắc thử...

Announcing Flutter 2

  Phụ lục: Flutter on the web Flutter 2 on desktops, foldables, and embedded devices The growing Flutter ecosystem Dart: The secret sauce behind Flutter Flutter 2: Available now Hôm nay, chúng tôi sẽ công bố Flutter 2: một bản nâng cấp lớn cho Flutter cho phép các nhà phát triển tạo các ứng dụng đẹp, nhanh chóng và di động cho bất kỳ nền tảng nào. Với Flutter 2, bạn có thể sử dụng cùng một cơ sở mã để gửi các ứng dụng gốc cho năm hệ điều hành: IOS, Android, Windows, macOS và Linux; cũng như trải nghiệm web nhắm mục tiêu các trình duyệt như Chrome, Firefox, Safari hoặc Edge. Flutter thậm chí có thể được nhúng vào ô tô, TV và thiết bị gia dụng thông minh, mang đến trải nghiệm di động và lan tỏa nhất cho thế giới điện toán xung quanh. Mục tiêu của chúng tôi là thay đổi cơ bản cách các nhà phát triển nghĩ về việc xây dựng ứng dụng, bắt đầu không phải với nền tảng bạn đang nhắm mục tiêu mà là với trải nghiệm bạn muốn tạo. Flutter cho phép bạn tạo ra những trải nghiệm tuyệt đẹp trong đó ...