Fuck the AI Subscription Circus. I Built Something Better with OpenCode.

October 22, 2026 Reading time: 46 minutes

Billions of tokens. $55 in purchased credits. Three independent OpenCode plugins. One released Bludit Wizard. And a development workflow that convinced me to stop paying for someone else's AI coding ecosystem.

The AI Coding Subscription Problem

On October 22, 2026, Arol Wright published an article on How-To Geek titled "“How I Ditched Cursor's Subscription for an Open-Source Alternative That Actually Works Offline.”" (https://www.howtogeek.com/ditched-cursors-subscription-for-lightweight-alternative-works-offline/)

His argument was reasonable.

Cursor made AI-assisted programming accessible and convenient, but its subscription model, cloud dependence, and editor-specific ecosystem introduced limitations that eventually outweighed the benefits.

His solution was "Cline" (https://github.com/cline/cline), an open-source coding agent that integrates with Visual Studio Code and supports both cloud-based and locally hosted language models.

I agree with much of his assessment.

But I took a different approach.

Instead of replacing one editor-integrated AI assistant with another, I moved to "OpenCode" (https://opencode.ai/), connected it to "LLM Gateway" (https://llmgateway.io/), and began building a customized agentic software development environment.

My workflow now revolves primarily around DeepSeek V4.1 Flash, specialized AI agents, independently developed plugins, and automated testing.

And unlike a hypothetical demonstration built around a trivial application, I've used this environment to develop, test, refactor, and release actual software.

As of October 22, 2026, my LLM Gateway account reports:

$55.00 in cumulative credit purchases
$33.81 in actual usage charges
$21.19 in remaining credits
13,723 API requests
2.9 billion input tokens
2.8 billion cached tokens
9.7 million output tokens
99.69% request success rate

Those numbers deserve some context, particularly the distinction between purchased credits, consumed credits, and cached tokens.

But they illustrate why I started questioning the assumption that serious AI-assisted development requires an expensive, tightly integrated commercial subscription.

The most interesting question isn't whether Cline or OpenCode is a better Cursor replacement.

It's whether the traditional subscription-based AI coding environment is even the right architecture for developers who want meaningful control over their tools, models, costs, and workflows.

Three Different Approaches to AI-Assisted Development

Cursor, Cline, and OpenCode solve overlapping problems, but they approach those problems from fundamentally different architectural directions.

Cursor: Convenience Through Integration

Cursor's primary advantage is convenience.

It combines a familiar editor with AI-assisted code completion, conversational assistance, multi-file editing, and autonomous development capabilities.

For someone who wants an integrated product requiring relatively little configuration, that's genuinely valuable.

The trade-off is that Cursor controls more of the overall experience.

Its pricing, usage allowances, product roadmap, supported integrations, and editor-specific behavior remain tied to the platform.

Cursor supports customization, external integrations, and multiple AI models, but the development experience is still centered on Cursor itself.

That isn't inherently bad.

It simply wasn't what I wanted.

I didn't want my development workflow to depend on a particular editor, subscription structure, or model-selection policy.

Cline: An Open-Source Agent Inside VS Code

Cline addresses several of Cursor's limitations by separating the coding agent from the commercial editor subscription.

It supports multiple AI providers, locally hosted models, terminal commands, file operations, MCP integrations, and agentic development workflows.

Its ability to connect to locally running models through tools such as Ollama and LM Studio makes offline operation possible.

That's a meaningful advantage.

But Cline approaches the problem primarily as an agent integrated into an existing editor.

For developers who already live in Visual Studio Code, that may be exactly what they want.

I wanted something different.

I wanted the coding agent to be an independent development platform rather than an extension of my editor.

OpenCode: The Agent as the Development Platform

OpenCode approaches AI-assisted development as an independent, extensible agentic environment.

It supports configurable models, primary agents, subagents, custom tools, plugins, and Model Context Protocol integrations.

Its terminal interface allows development workflows to operate independently of a particular graphical editor.

That separation matters.

I'm no longer interested in simply asking an AI assistant to generate a function or explain an error message.

I want a development environment capable of investigating repositories, understanding architectural constraints, implementing changes, running tests, diagnosing failures, and coordinating specialized operations when necessary.

I also want the ability to extend that environment when its default capabilities don't solve a problem.

OpenCode provides the foundation for doing that.

Cursor vs. Cline vs. OpenCode: A Technical Comparison

The following comparison focuses on the concerns raised in Wright's article and the requirements that influenced my own development workflow.

These are architectural comparisons, not benchmark results.

None of these tools wins every category.

Cursor's integrated experience may be ideal for developers who prioritize convenience and polished autocomplete.

Cline makes sense for developers who want an open-source agent without leaving VS Code.

OpenCode becomes particularly interesting when the coding agent itself is something you want to configure, extend, and integrate into a larger development system.

That last category describes my workflow.

The Architecture: OpenCode, LLM Gateway, and DeepSeek

One of the most important decisions I made was separating my development environment from the model provider.

In my configuration, OpenCode serves as the agentic development platform.

LLM Gateway provides access to language models.

The underlying model handles inference.

Conceptually, the architecture looks like this:

                DEVELOPER
                    |
                    v
                OPENCODE
                    |
      +-------------+-------------+
      |             |             |
      v             v             v
 Primary Agent   Subagents    Custom Tools
      |             |             |
      +-------------+-------------+
                    |
         +----------+----------+
         |                     |
         v                     v
    Native Plugins         MCP Tools
         |                     |
         +----------+----------+
                    |
                    v
               LLM GATEWAY
                    |
      +-------------+-------------+
      |             |             |
      v             v             v
   DeepSeek      DeepSeek      Alternative
   V4 Flash      V4.1 Flash      Models

This is a conceptual architecture rather than a literal export of every agent definition and routing rule in my configuration.

The key benefit is separation of concerns.

The coding environment, the agentic workflow, and the language model are independent architectural decisions.

If a better model becomes available, I don't need to replace OpenCode.

If a provider changes pricing or availability, I can evaluate alternatives.

If I need additional development capabilities, I can build tools or plugins without replacing the underlying inference system.

This flexibility matters because the AI model market changes rapidly.

Models improve.

Prices change.

Providers introduce new restrictions.

Capabilities appear and disappear.

I don't want my entire development workflow tied to whichever model or vendor happens to be fashionable this month.

Why DeepSeek V4.1 Flash Became My Primary Development Model

My development workflow initially relied heavily on DeepSeek V4 Flash.

When DeepSeek V4.1 Flash became available through LLM Gateway, I began transitioning my development work to the newer model.

Eventually, I moved my development work to V4.1 Flash almost exclusively.

That decision wasn't based on marketing material or a leaderboard.

It was based on actual development experience.

I also experimented with alternatives, including GLM 5.3 Flash.

My experience with GLM was considerably less favorable.

DeepSeek V4.1 Flash has consistently been the better fit for my particular development tasks.

That doesn't establish that DeepSeek universally outperforms GLM across every benchmark or workload.

It establishes something more relevant to my workflow: when I needed to get actual projects completed, DeepSeek was the model I preferred.

What Matters in an Agentic Coding Model

My priorities are different from those of someone using AI primarily for autocomplete.

I need a model to:

Understand existing repository structure.
Preserve established architectural decisions.
Follow detailed project requirements.
Reason across multiple files.
Use development tools reliably.
Diagnose errors instead of repeatedly guessing.
Recognize when an approach isn't working.
Make targeted corrections without introducing unnecessary changes.
Complete tasks with minimal supervision.

A model can generate beautiful code snippets and still perform poorly in a sustained agentic development environment.

The important question is whether it can reliably carry a task through investigation, implementation, testing, and correction.

And that leads to one of my most revealing development experiences.

Case Study: GLM Couldn't Get Through the First Prompt. DeepSeek Finished the Project.

One of the clearest demonstrations of why model selection matters came from developing Bludit Wizard, my native plugin for the Bludit content management system.

The project began as an effort to bring AI-assisted content-management functionality directly into Bludit.

The goal was to develop a functional plugin with its own administrative interface and practical content-management capabilities.

I initially attempted the project using GLM 5.3 Flash.

It couldn't successfully get through the initial development prompt.

That was not exactly an encouraging beginning.

Rather than continue fighting the same problem, I switched to DeepSeek V4.1 Flash through LLM Gateway.

The difference in my experience was substantial.

DeepSeek became the model I used to complete the project.

It worked through implementation, debugging, testing, and the changes required to prepare Bludit Wizard for release.

And the result wasn't merely a generated prototype.

It became a functional native Bludit plugin with its own administrative interface and content-management capabilities.

The development process included:

More than 400 automated tests.
Nearly 40 manual tests.
Functional validation of the plugin.
Iterative debugging and corrections.
Release preparation and publication.

Bludit Wizard was subsequently released, and I began introducing it to the wider Bludit community.

The project also expanded into related work involving a separate MCP server, intended to expose Bludit functionality to compatible AI clients.

Why This Experience Matters

The most interesting part wasn't simply that one model performed better than another.

It was that I didn't need to change my development environment when the original model failed.

I changed the model.

OpenCode remained my development platform.

LLM Gateway remained my model access layer.

The project requirements remained the same.

DeepSeek V4.1 Flash took over the work that GLM 5.3 Flash had failed to initiate successfully.

This wasn't a controlled benchmark proving universal model superiority.

It was a firsthand development experience demonstrating how dramatically model choice can affect the outcome of a real project.

When a model doesn't work, I want to replace the model, not rebuild my entire development workflow.

That's one of the most important reasons I value OpenCode and LLM Gateway.

The Best Agentic Workflow Sometimes Doesn't Need More Agents

One of the more surprising developments in my workflow has been how infrequently I've needed to delegate work to specialized agents since switching to DeepSeek V4.1 Flash.

OpenCode supports specialized agents with configurable instructions, models, and permissions.

These capabilities make it possible to separate development responsibilities.

A multi-agent system might include specialized roles for planning, implementation, debugging, code review, and testing.

But there's an important distinction between having specialized agents available and needing to invoke them for every problem.

In my recent experience, DeepSeek V4.1 Flash has been capable of investigating, reasoning through, and resolving most of the development problems I've given it directly.

That changes the economics and complexity of agentic development.

Agent Delegation Isn't Free

Every additional agent invocation can introduce:

Additional context processing.
More API requests.
Increased latency.
Coordination overhead.
Potentially duplicated work.
Additional opportunities for misunderstandings.
More complicated debugging when something goes wrong.

Multi-agent orchestration can be valuable when a problem benefits from specialized responsibilities or independent analysis.

But it can also become unnecessary complexity.

A primary agent that can solve a problem reliably without delegation may be more efficient than a collection of specialized agents repeatedly passing information between one another.

Capability Matters More Than Agent Count

There's a tendency in AI development to assume that more agents automatically produce better results.

I don't subscribe to that assumption.

Ten agents aren't inherently better than one.

Five layers of orchestration aren't automatically more sophisticated than a direct solution.

The purpose of an agentic development environment should be to solve problems effectively.

Not to maximize the number of models involved in solving them.

My preference for DeepSeek V4.1 Flash is partly based on its ability to handle tasks that might otherwise require more extensive delegation.

When a specialized agent genuinely adds value, the architecture can support it.

When the primary model can solve the problem itself, unnecessary delegation is simply overhead.

The objective isn't maximum agent activity. It's successful task completion with minimum unnecessary complexity.

I Didn't Just Configure OpenCode. I Started Building Tools for It.

One of the biggest advantages of an extensible development environment is that you're not limited to the capabilities its maintainers decide to provide.

When I encountered recurring problems in my AI-assisted development workflow, I started developing solutions.

That work produced three independent OpenCode plugin projects:

Checkpoint Orchestrator, Git That Shit, and Stranger Danger.

These weren't designed as mandatory components of one bundled framework.

Each addresses a different problem.

Each was developed with independence and testability in mind.

And each reflects something I learned while working with agentic software development.

Checkpoint Orchestrator: Because AI Agents Need More Than Conversation History

Long-running development tasks introduce problems that ordinary conversational AI doesn't adequately solve.

Sessions end.

Processes fail.

Context becomes fragmented.

Development work gets interrupted.

Checkpoint Orchestrator addresses the need for persistent task state, recoverable checkpoints, and resumable development workflows.

Its development has included architectural work involving SQLite persistence, session isolation, and failure recovery.

Earlier approaches based on JSON and Markdown storage were replaced during development work with session-scoped SQLite persistence.

The goal was to improve consistency, durability, and independence.

Validation included concurrency testing, crash-consistency checks, and controlled execution in a Docker-based laboratory environment.

A migration test suite passed 137 tests during that work.

The underlying principle is straightforward:

Development state should not disappear merely because an AI session ends.

"Explore Checkpoint Orchestrator on GitHub" (https://github.com/gitdamnit)

Git That Shit: Version Control Belongs in the Workflow

An AI coding agent capable of changing dozens of files needs reliable version-control practices.

Git is already fundamental to software development.

Agentic coding makes disciplined version control even more important.

Git That Shit is my independent project for bringing Git-oriented capabilities into the development workflow.

Its OpenCode V2 development work retained a standalone command-line interface while emphasizing namespaced configuration, storage, and logging.

An important design objective was independence.

I don't want one plugin to require my entire personal development ecosystem merely to function.

That creates unnecessary coupling, complicates installation, and increases maintenance requirements.

Git That Shit is intended to solve its own problem without dragging unrelated components along for the ride.

Because the only thing worse than an AI making a terrible code change is discovering you have no clean way to recover from it.

"Explore Git That Shit on GitHub" (https://github.com/gitdamnit/opencode-git-that-shit)

Stranger Danger: Powerful Agents Need Boundaries

AI coding agents operate with access to development tools, files, commands, and potentially external services.

That creates capabilities that are genuinely useful.

It also creates risks.

A coding agent isn't simply a chatbot answering questions.

Depending on its permissions, it may execute operations that modify files, invoke external tools, or affect the local development environment.

Stranger Danger is my security-oriented OpenCode plugin project, developed with an emphasis on defensive hardening and independent operation.

Its development has included security-focused changes, compatibility work, and validation of plugin independence.

The broader lesson is simple:

A model's willingness to execute a command is not evidence that the command is safe.

Powerful automation requires appropriate boundaries.

"Explore Stranger Danger on GitHub" (https://github.com/gitdamnit)

Three Independent Plugins, One Development Philosophy

These projects address three recurring concerns in agentic development:

Continuity: Preserve state and recover from interruptions.

Control: Maintain reliable version-control workflows.

Security: Recognize that autonomous tools require operational boundaries.

They also demonstrate why OpenCode's extensibility matters to me.

I'm not merely installing someone else's coding assistant.

I'm developing tools that change how my development environment behaves.

My open-source projects are available through "GitHub" (https://github.com/gitdamnit).

Native Plugins, MCP, and the Importance of Architecture

One of the more useful architectural distinctions I've encountered is the difference between a native plugin and an MCP server.

Both can extend an AI-assisted workflow.

They do not necessarily serve the same purpose.

Native Plugins

Native OpenCode plugins integrate with the coding environment's supported tools, hooks, and lifecycle events.

They can provide functionality closely connected to how the development agent operates.

This makes them useful for internal workflow automation and environment-specific capabilities.

Model Context Protocol

The Model Context Protocol provides a standardized mechanism for exposing tools and resources to compatible AI clients.

An MCP server can make functionality available across different applications without requiring every application to implement an entirely separate integration.

This becomes especially valuable when the underlying capability should not depend on one coding environment.

What Bludit Wizard Taught Me

My Bludit Wizard project illustrates why these distinctions matter.

The project originated from an effort to reproduce and extend the capabilities of a custom GPT used for managing a Bludit website.

That effort evolved into a native Bludit plugin and a separate MCP server project.

The native plugin provides functionality inside Bludit itself.

The MCP server is intended to expose relevant capabilities to compatible AI clients.

These are different architectural components.

They should be capable of independent development and maintenance.

The lesson is that integration architecture matters just as much as the model generating the code.

Choosing the right boundaries between application functionality, AI tools, and external protocols can prevent substantial maintenance problems later.

Billions of Tokens, $55 in Credits: The Economics of My Setup

This is probably the most surprising part of my experience.

As of October 22, 2026, my LLM Gateway account reports $55 in cumulative credit purchases.

Of that amount, $33.81 has been consumed through reported usage charges, leaving $21.19 in available credits.

Across the same reporting period, the dashboard records:

These numbers represent LLM Gateway activity, not an independently audited OpenCode-only usage export.

They also span more than one model and potentially more than one type of AI-assisted activity.

Nevertheless, they provide a useful picture of the scale and economics of my model usage.

Purchased Credits vs. Actual Usage

The distinction between deposited credits and consumed credits is important.

I have purchased $55 in credits.

I have not consumed all $55.

My reported usage charges total $33.81.

That means the remaining $21.19 is still available for future usage.

Average Cost Per Request

Using the dashboard totals:

$33.81 ÷ 13,723 requests = approximately $0.00246 per request.

That's roughly one-quarter of one cent per request.

Of course, request count alone doesn't measure useful work.

Some requests are simple.

Others involve substantial context, multiple tool interactions, or complicated reasoning.

A failed request and a successful implementation request also have very different practical value.

But the average is still useful as a description of observed gateway spending.

Understanding the Token Numbers

The dashboard reports approximately:

2.9 billion input tokens.
2.8 billion cached tokens.
9.7 million output tokens.

Adding the displayed categories produces approximately 5.71 billion token events.

However, cached-token accounting can differ between reporting systems.

If cached tokens are already included in the input-token total, adding them again would double-count usage.

For that reason, I am not treating 5.71 billion as a verified nonoverlapping token total.

Even the reported input volume alone is substantial.

Why Caching Matters

Agentic development frequently involves repeatedly processing repository context, project instructions, source files, and tool results.

That can become expensive when every request requires the same context to be processed at full price.

Caching can reduce the cost of repeated context when supported by the provider and model.

My dashboard reports approximately 2.8 billion cached tokens.

That volume helps explain why understanding cache behavior is important when evaluating the economics of agentic development.

A model's advertised input-token price doesn't necessarily tell the whole story.

What These Numbers Do Not Prove

The financial statistics don't establish that every request was made through OpenCode.

They don't establish that every token was processed by DeepSeek V4.1 Flash.

They don't establish that every request contributed to productive development work.

And they don't establish that my entire development environment cost exactly $33.81.

I've used other development tools and services.

The gateway figures should not be mistaken for a complete accounting of all software-development expenses.

What they demonstrate is that substantial AI usage can be achieved at relatively low reported inference cost when model selection, provider pricing, and caching are favorable.

The Hidden Cost of AI Coding Is Rework

Token pricing receives enormous attention.

Developer time receives considerably less.

That is backwards.

Suppose Model A costs almost nothing but repeatedly introduces regressions.

Model B costs more per request but consistently completes tasks with fewer corrections.

Which one is cheaper?

The answer depends on the entire development process.

A useful evaluation must consider:

Effective development cost = inference spending + correction effort + testing overhead + failure recovery.

Those quantities aren't directly comparable in dollars without assigning a value to developer time.

But they are all real costs.

This becomes especially important in agentic workflows.

A complicated task may generate substantial internal activity before producing a final result.

More tokens don't automatically mean more progress.

More agents don't automatically mean better reasoning.

And elaborate orchestration doesn't automatically produce better software.

The goal should be reliable completion of useful work.

Not maximizing the number of AI requests.

This is one reason I prefer evaluating models through real projects rather than isolated benchmarks.

Testing Is What Separates Development From Code Generation

One of my strongest objections to simplistic AI coding demonstrations is the tendency to treat generated code as finished software.

A model produces an application.

The application launches.

Someone declares success.

Unfortunately, software development is slightly more complicated than that.

An application can launch successfully while containing broken workflows, security vulnerabilities, inconsistent state, and substantial regressions.

My projects have required automated testing, manual validation, dependency checks, and repeated corrections.

Independent Plugin Testing

My OpenCode plugin migration work included independent testing in a rootless Docker laboratory.

The objective was to validate plugin behavior without relying on uncontrolled interactions with my everyday development environment.

That work also included checking whether independently developed plugins could operate without importing or depending on one another.

This matters because modular software should remain modular in practice, not merely in its documentation.

Development Isolation

Another principle I take seriously is separating development environments from production systems.

A capable coding agent can make changes quickly.

That's useful when the changes are correct.

It's dangerous when they aren't.

For larger projects, I prefer working against development copies and controlled test environments before accepting changes into production.

My TRAVIS development work, for example, has involved explicit requirements, development-only database changes, and staged acceptance.

The objective is to prevent an automated system from turning a misunderstanding into a production incident.

Tests Are Evidence, Not Proof of Perfection

Passing hundreds of tests is meaningful.

It isn't a guarantee that software is defect-free.

Tests can omit important cases.

Assertions can be incorrect.

Mocked environments can behave differently from production.

A responsible development process combines automated validation with architecture review, manual testing, and appropriate release controls.

The point of using AI isn't to eliminate engineering discipline.

It's to apply that discipline more efficiently.

Offline Development: Where Cline and OpenCode Both Have an Advantage

Wright emphasizes offline capability as one of the major reasons he chose Cline.

That's a legitimate advantage.

But it isn't exclusive to Cline.

OpenCode also supports local model providers.

With an appropriate local model and supporting tools installed, it can perform AI-assisted operations without depending on cloud inference.

The important distinction is between the coding agent and the model.

OpenCode can operate locally.

A cloud-hosted model cannot magically continue answering requests when the internet connection disappears.

My primary LLM Gateway configuration uses remote inference.

Consequently, my normal DeepSeek-powered workflow depends on network connectivity.

If I configure OpenCode to use a suitable local model, that changes the inference dependency.

But local inference introduces other considerations.

Hardware Requirements

Running capable language models locally requires sufficient memory, processing resources, and storage.

The requirements depend on model size, quantization, context length, and performance expectations.

Model Capability

A local model that works adequately for routine code explanations may struggle with complicated repository-wide reasoning.

That limitation matters when using autonomous agents.

Privacy

Local inference can reduce exposure of source code to external model providers.

However, local inference alone doesn't guarantee complete privacy.

Plugins, telemetry, package managers, web tools, and external integrations may still transmit data.

A privacy-sensitive workflow needs to evaluate the entire toolchain.

For my own development, remote inference has generally been an acceptable trade-off.

I prioritize model capability, flexibility, and cost.

Someone working with confidential client code under stricter contractual requirements may reach a different conclusion.

And that's precisely why architectural flexibility matters.

Why I Don't Want My Development Workflow Locked to One Model

The AI model market changes too quickly for me to build my entire development process around a single vendor.

A model that performs exceptionally well today may be surpassed tomorrow.

A provider may change pricing.

A model may become unavailable.

An API may introduce different limits.

Or a new model may simply perform better on the kinds of tasks I care about.

My transition from DeepSeek V4 Flash to V4.1 Flash illustrates this.

I didn't need to replace my development environment.

I changed the model powering it.

The same general principle applies when evaluating alternatives.

I can compare models within a familiar workflow instead of repeatedly rebuilding that workflow around new applications.

This is the distinction between model portability and workflow portability.

Model portability means I can change the inference provider.

Workflow portability means my project knowledge, tools, and development practices aren't unnecessarily tied to one provider or application.

OpenCode, LLM Gateway, vendor-neutral documentation, and independently developed tools help me pursue both.

That doesn't eliminate every dependency.

OpenCode has configuration conventions and plugin compatibility requirements.

LLM Gateway introduces another service dependency.

Different models may behave differently under identical instructions.

There is no magical architecture without trade-offs.

But I would rather manage those trade-offs explicitly than surrender control of the entire workflow to one commercial platform.

Where Cursor Still Makes Sense

Despite my preference for OpenCode, I don't think Cursor is a bad product.

It solves a real problem.

Its integrated experience reduces configuration work and provides features that many developers find valuable.

Fast inline completion, familiar editor behavior, and cohesive interfaces can be more important to some developers than deep customization.

Not everyone wants to manage model providers, API credentials, agent permissions, plugins, and infrastructure.

Nor should they have to.

If a developer values convenience more than architectural independence, Cursor may be worth its subscription cost.

The mistake would be assuming that convenience is the only meaningful criterion.

For my workflow, it isn't.

Where Cline Makes Sense

Cline also deserves credit.

It addresses many of the limitations that motivated Wright to leave Cursor.

It offers open-source agentic coding, broad model support, local inference options, and integration with an editor that many developers already know.

For a VS Code user who wants greater control without changing their broader development environment, Cline may be the most practical choice.

I wouldn't recommend abandoning a working Cline configuration merely because OpenCode exists.

The meaningful question is whether the developer benefits from separating the agent from the editor and extending its behavior more directly.

For me, the answer was yes.

Where OpenCode Falls Short

An honest comparison also needs to acknowledge the limitations of my preferred setup.

OpenCode doesn't automatically eliminate complexity.

In some respects, it introduces more.

Configuration Takes Work

A customized agentic environment requires decisions about models, providers, permissions, project instructions, and tools.

Those decisions can be time-consuming.

Plugins Require Maintenance

Extensibility creates responsibility.

Custom plugins need testing, compatibility checks, and updates when underlying interfaces change.

My own OpenCode V2 migration work demonstrates that maintenance burden.

Multiple Agents Can Increase Costs

Agent specialization can improve task organization, but unnecessary delegation can waste tokens and complicate debugging.

A multi-agent architecture isn't inherently superior to a well-configured single agent.

Remote Models Still Depend on External Services

My LLM Gateway configuration doesn't eliminate network dependence.

It changes how I access remote models.

Cheap Inference Doesn't Guarantee Cheap Development

A low per-token price is useful only when the model can reliably perform the work.

These limitations are real.

I accept them because the benefits of customization and independence matter more to my development process.

What I'd Recommend to Someone Starting Today

I wouldn't recommend that every developer immediately reproduce my entire environment.

That would be an excellent way to spend several days configuring tools before writing a single useful line of code.

Instead, start with the simplest architecture that satisfies your actual requirements.

If you want a polished, integrated AI editor and don't mind the commercial model, evaluate "Cursor" (https://cursor.com/).

If you already use VS Code and want an open-source agent with local inference support, evaluate "Cline" (https://github.com/cline/cline).

If you want a standalone, highly configurable coding agent that you can extend with custom tools and workflows, evaluate "OpenCode" (https://opencode.ai/).

And if you want to experiment with multiple model providers while maintaining a consistent development interface, consider an appropriate gateway architecture such as "LLM Gateway" (https://llmgateway.io/).

Whatever you choose, establish basic engineering controls before giving an agent extensive permissions.

Use version control.

Define project requirements.

Review changes.

Test the resulting software.

Understand which services receive your source code.

And measure successful outcomes rather than treating token consumption as an achievement by itself.

What I've Actually Learned

My experience with OpenCode has changed how I think about AI-assisted software development.

Initially, the attraction was straightforward: access to capable AI models without depending on another expensive subscription.

Over time, the more significant benefit became architectural control.

I could select my own models.

I could develop specialized tools.

I could maintain independent plugins.

I could experiment with agentic workflows.

I could integrate development practices emphasizing testing, isolation, and reproducibility.

And I could do all of this without treating one commercial editor as the foundation of my entire software development process.

The result has been a collection of real projects, including Checkpoint Orchestrator, Git That Shit, Stranger Danger, ProDoc Guard, and Bludit Wizard.

Not every experiment succeeded.

Not every model performed equally well.

Not every architectural decision survived testing.

And some development work required substantial refactoring.

That's software engineering.

The fact that AI participated in the process doesn't make those realities disappear.

But it has changed how much I can attempt, how quickly I can explore solutions, and how I organize development work.

Conclusion: The Best AI Coding Tool Is the One You Control

I agree with Arol Wright's central argument: developers should question whether subscription-based AI coding environments offer the flexibility and value they actually need.

Cline is one credible answer.

For me, OpenCode was another.

But the real benefit wasn't simply replacing Cursor with a free application.

It was separating the major components of my development environment so that I could make independent decisions about each one.

OpenCode provides the agentic development platform.

LLM Gateway provides model access.

DeepSeek V4.1 Flash currently provides my preferred inference capabilities.

My custom tools and plugins extend the environment around the problems I actually encounter.

And testing, version control, and project requirements provide the engineering discipline that AI-generated code still requires.

My dashboard currently reports billions of tokens of activity, more than 13,000 requests, and $33.81 in consumed gateway credits out of $55 purchased.

Those figures don't prove that OpenCode is universally better than Cursor or Cline.

They demonstrate that my particular configuration has supported substantial AI usage at remarkably low reported inference cost.

More importantly, the resulting work exists outside the dashboard.

There are repositories.

There are tests.

There are releases.

There are integrations.

And there is software that actually works.

That's what ultimately matters.

I didn't replace a coding subscription just to save twenty dollars. I replaced an approach to AI-assisted development that gave me less control than I wanted.

And after building my own workflow around OpenCode, I have very little interest in going back.

Technical References and Projects

Development platforms

"OpenCode" (https://opencode.ai/)
"OpenCode Documentation" (https://opencode.ai/docs/)
"Cline on GitHub" (https://github.com/cline/cline)
"Cursor" (https://cursor.com/)
"LLM Gateway" (https://llmgateway.io/)
"Model Context Protocol" (https://modelcontextprotocol.io/)

Original article

"How I Ditched Cursor's Subscription for an Open-Source Alternative That Actually Works Offline" (https://www.howtogeek.com/ditched-cursors-subscription-for-lightweight-alternative-works-offline/) — Arol Wright, How-To Geek, October 22, 2026.

Open-source development projects

"Checkpoint Orchestrator and other projects" (https://github.com/gitdamnit)
"Git That Shit" (https://github.com/gitdamnit/opencode-git-that-shit)
"Stranger Danger and other projects" (https://github.com/gitdamnit)
"Bludit Wizard and other projects" (https://github.com/gitdamnit)
"All repositories" (https://github.com/gitdamnit)

Usage statistics reflect LLM Gateway dashboard information from October 22, 2026. Credit purchases and usage charges are reported separately. Token figures are rounded as displayed, and cached-token overlap has not been independently verified. Model comparisons reflect firsthand development experience rather than controlled benchmarks. This article is an independent technical account and is not sponsored.