The Case Against “Free” AI: What Twelve Providers Taught Us About the Real Cost of Coding Models

November 10, 2026
jenholm
Uncategorized
0

An OpenCode field investigation into authentication failures, restrictive quotas, unreliable inference, and the two services that emerged from the wreckage with their reputations substantially intact.

There is something faintly absurd about the present marketplace for artificial intelligence. A developer seeking access to a language model is greeted by an apparently inexhaustible selection of providers, each advertising generous allowances, enormous context windows, impressive benchmarks, and increasingly capable models, often at no charge whatsoever. The abundance is remarkable, the prices inviting, and the accompanying marketing materials leave little doubt that reliable, inexpensive artificial intelligence has finally become a commodity. What those materials are considerably less eager to disclose is how much of that advertised capability survives contact with an actual software development environment.

I recently undertook what I supposed would be a straightforward exercise: identify the best providers of free or inexpensive AI models for use with OpenCode, the open-source coding harness through which I conduct a substantial portion of my software development. My requirements were neither exotic nor unreasonable. I wanted models capable of reading source code, following development instructions, using tools, and completing useful programming tasks without exhausting their allowances after a handful of exchanges or requiring more administrative labor than the programming tasks themselves.

The inquiry soon became considerably more instructive than a conventional comparison of model catalogs. Providers that looked excellent on paper failed to authenticate, imposed token limits incompatible with ordinary coding-agent workloads, or required credentials and account relationships that their documentation made unnecessarily difficult to understand. One service could be made to function only by repeatedly retrying requests that its servers were apparently too busy to process. Another offered an impressive allocation of free requests that proved inaccessible behind an Alibaba Cloud account-linking procedure.

Yet the investigation also produced two comparatively favorable experiences. Kilo Gateway authenticated successfully and ran a Nemotron model without incident, while CommandCode, a provider initially omitted from our comparison, had already demonstrated satisfactory performance through its API in OpenCode. The latter was particularly significant because CommandCode was not principally a free provider at all, but a subscription service whose modest price made its demonstrated utility more important than its failure to qualify as entirely free.

The exercise exposed a defect not merely in individual services, but in the customary manner of evaluating them: we tend to reward companies for what they advertise rather than for what their customers can accomplish.

The Original Ranking, and the Defect in Its Reasoning

Our initial scoring system assigned points for the number of available free models, token pricing, request allowances, coding capability, service reliability, and ease of integration. It was a reasonable framework for comparing published specifications, but it contained a substantial weakness: it awarded credit for capabilities that had never been demonstrated to work.

OpenRouter emerged at or near the top of the original ranking because of its enormous catalog and attractive nominal pricing. Google AI Studio also scored exceptionally well, benefiting from Google’s formidable resources and ostensibly convenient API integration. ModelScope received high marks for its advertised daily request allowance, while Z.AI appeared promising because of its capable GLM models and free API offerings.

This analysis committed an elementary error of measurement. It treated the declared attributes of the providers as if they were equivalent to operational results, when the purpose of the exercise was precisely to determine whether those providers could accomplish useful work.

An OpenCode agent does not ordinarily submit one brief question and await one brief answer. It transmits instructions, tool definitions, repository context, previous exchanges, and source files, often repeatedly, while navigating a sequence of dependent tasks. An allowance that appears generous when expressed as requests per day may prove entirely inadequate when those requests contain substantial context. Likewise, an enormous model catalog has little economic value when authentication fails before inference begins.

The proper unit of evaluation, therefore, is not the number of models advertised or the nominal number of tokens offered, but useful programming work completed without interruption, measured against the developer’s expenditure of money and time.

That distinction would eventually overturn much of our initial ranking.

OpenRouter: A Service Without a Working Entrance

OpenRouter was the first major disappointment. After configuring multiple API keys in OpenCode, the service persistently returned a Missing Authentication header error. Upgrading the harness to OpenCode 2 did not resolve the difficulty, and further attempts with additional credentials proved no more successful.

It would be improper to infer from this experience that OpenRouter is universally defective. Other developers plainly use the service successfully, and some report satisfactory performance with its extensive model catalog. But the question before us was not whether OpenRouter worked for someone, somewhere, under circumstances we had not examined. It was whether the service worked in the environment in which I intended to use it.

On that question, the evidence was decisive. A gateway that cannot be authenticated has no practical advantage over one that offers no models whatsoever, and its theoretical superiority in catalog breadth is irrelevant to the result.

OpenRouter was therefore disqualified for my OpenCode installation, receiving an operational score of zero.

Google AI Studio: The Generosity of a 16,000-Token Ceiling

Google AI Studio presented a different difficulty. Its Gemma 4 31B IT model initially appeared usable, only to terminate the session with a quota error reporting a limit of 16,000 input tokens per minute on Paid Tier 1. The error recommended waiting approximately 31 seconds before retrying.

The distinction between a rate-limit violation and exhaustion of an account’s total allowance is technically important, but it does little to improve the developer’s position when the immediate consequence is an interrupted coding session. Google’s rate-limit documentation makes clear that models are subject to multiple independent quotas, any one of which may prevent a request from being processed.

In ordinary conversational use, a modest token ceiling may present little inconvenience. In an agentic coding environment, where source files, instructions, and previous context are transmitted repeatedly, the same ceiling can become the principal limitation on the service.

Google was not condemned for failing to provide unlimited computing resources without charge. No rational evaluation would impose such an obligation. The objection was that the available throughput proved insufficient for the task being evaluated, despite the service’s otherwise impressive specifications.

The tested Google route was consequently disqualified for our workload, although that finding does not establish that every Google model or billing tier suffers the same limitation.

Z.AI: The Model Works, When the Service Permits It

Z.AI, using GLM-4.7-Flash, managed to authenticate and execute requests, but with a disquieting lack of consistency. OpenCode reached its fourth retry attempt while displaying a warning that the service might be temporarily overloaded. Repeated attempts eventually succeeded, distinguishing Z.AI from a completely inaccessible provider, but hardly establishing it as a dependable foundation for unattended development.

Subsequent research found reports of significant instability involving other Z.AI services, including HTTP 502 responses and interrupted streaming connections. One GitHub incident report described extensive failures during October 2026. Those reports do not establish the precise failure rate of GLM-4.7-Flash on the endpoint I tested, but they provide independent evidence that service instability was not merely imaginary.

The distinction between a capable model and a dependable delivery service deserves more attention than it ordinarily receives. A model may possess excellent reasoning and coding capabilities while remaining practically unsuitable for autonomous work because its infrastructure cannot deliver those capabilities consistently.

Z.AI remained in the ranking, but its score was reduced to 52 out of 100, reflecting usable model access burdened by unacceptable uncertainty about sustained availability.

ModelScope: Free Access, Conditional Upon Access Being Possible

ModelScope initially appeared to offer one of the most generous free allocations in the comparison, advertising up to 2,000 API calls per day. That advantage proved entirely theoretical in my installation.

Two separately generated tokens failed in OpenCode with an authentication error. The attempted remedy required creating and linking an Alibaba Cloud computing account, a process that also failed. The advertised inference allowance was never reached because the account could not satisfy the prerequisites for using it.

Public reports revealed similar difficulties. In ModelScope GitHub issue #1524, a developer in Kuwait described obtaining API credentials but being unable to use them because of the Alibaba Cloud account-linking requirement. A project representative explained that the relevant binding mechanism was restricted to accounts on Alibaba Cloud’s mainland-China system.

One may appreciate the administrative reasons a company might impose restrictions upon access to its computing resources without conceding that the resulting service is usable by the customers to whom it is advertised. A free API whose authentication cannot be completed is not an inexpensive service; for the affected customer, it is no service at all. ModelScope joined OpenRouter and the tested Google route at the bottom of our operational ranking.

Kilo Gateway: A Successful Test, After an Unnecessary Search

By this stage, enthusiasm for the remaining providers had diminished considerably. Kilo Gateway had already been downgraded during our literature review because its free-model routing depended on shared upstream capacity, its documentation was less straightforward than desirable, and users had reported assorted compatibility and rate-limit difficulties.

The actual test, however, produced a substantially more favorable result. After establishing a Kilo account, I obtained an API key, entered it into OpenCode 2, selected Nemotron 3.5 Super VL, and ran the model successfully without incident. Authentication worked, inference proceeded, and the session required none of the repeated troubleshooting that had characterized several competitors.

Kilo nevertheless deserved a deduction for its user interface and documentation. I spent approximately 20 minutes locating the API key, eventually discovering it at app.kilo.ai, under Your Profile, at the very bottom of the page. There is no obvious reason why obtaining the credential essential to using an API should require a scavenger hunt through a web interface. The problem was not technical complexity but inadequate presentation of an elementary function.

The distinction, however, is that Kilo’s inconvenience was ultimately surmountable, whereas the failures encountered elsewhere prevented or seriously disrupted the intended work. Kilo’s published gateway terms provide access to qualifying free models without inference charges and advertise a ceiling of 200 free requests per hour per IP address, although upstream restrictions may reduce actual capacity. Its paid offerings also provide a path to broader model access, with provider-based token pricing and a separate credit-purchase fee.

One successful session cannot establish long-term reliability, nor can a published gateway limit establish the number of requests that will actually succeed. Kilo’s free routes may also depend upon upstream providers whose data-handling policies permit retention or training on submitted content, making the suitability of those routes for confidential source code a separate concern.

Nevertheless, the operational evidence was favorable, and Kilo’s score rose from 52 to 70 out of 100. It became the highest-ranked provider among those tested primarily for free inference.

CommandCode: The Provider Our Original Inquiry Overlooked

The investigation would have remained incomplete had we stopped with Kilo, for there was another service whose omission illustrated a different defect in our reasoning.

I had already been using CommandCode’s API successfully through OpenCode, yet CommandCode was absent from our original comparison. The exclusion was understandable in the narrow sense that the initial inquiry concerned free providers, whereas CommandCode’s useful third-party API access is chiefly associated with paid plans. But it was indefensible once the investigation expanded to examine the actual cost of obtaining dependable coding inference.

CommandCode’s official Provider API supports OpenAI-compatible and Anthropic-compatible requests and can be used directly from third-party clients, including OpenCode. Its registered model catalog encompasses numerous model families, including DeepSeek, Qwen, GLM, MiniMax, GPT, Gemini, and Claude, although availability depends upon the customer’s plan and selected endpoint.

The service does not provide unrestricted free API access merely because its entry-level subscription is inexpensive. The $1 monthly Go plan excludes official third-party API access. The $10 monthly GOAT plan includes it, as do higher subscriptions. A separate Provider plan starts at $15 plus a processing fee and includes $15 in API credits, with subsequent usage billed at model-specific rates. Promotional models may be temporarily free, but those offers are neither permanent entitlements nor substitutes for understanding the account’s actual billing conditions.

CommandCode’s pricing is especially interesting because its coding subscriptions assign model-dependent usage allowances rather than merely selling a fixed number of tokens. The GOAT plan, for example, currently advertises up to $100 of model-specific usage value, subject to shared allowance accounting and rolling five-hour and weekly limits. These amounts must not be mistaken for cash-equivalent credits available independently for every model, nor can the value advertised for several models be added together to obtain a larger entitlement.

The commercial terms are potentially attractive, but they are not altogether simple. Indeed, the company’s usage-limit documentation contains differing numerical descriptions in its tables and explanatory prose, a defect that deserves correction in any service whose economics depend so heavily upon understanding available allowances.

Independent user reports reinforce both sides of this assessment. A September comparison in the OpenCode community found CommandCode competitively priced and responsive for DeepSeek workloads, while other developers have reported difficulties with cache accounting, unexpectedly rapid consumption of subscription allowances, and intermittent upstream failures.

A September discussion of usage accounting described substantial discrepancies between expected and observed consumption in an agentic workflow, with poor cache utilization identified as a possible contributing factor. An August GitHub report documented a customer whose account continued to be denied API access after upgrading to an eligible plan; that issue was subsequently closed, but it establishes that CommandCode has not been immune to the authentication difficulties encountered elsewhere.

Perhaps most relevant to this investigation, a November 4 comparison reported substantially higher output speed using CommandCode’s own CLI than through its Provider API in OpenCode, with approximate measurements of 509 and 124 tokens per second, respectively. The sample was too small and the environments too different to support a general conclusion about systematic throttling, but the result illustrates why performance through a provider’s own coding client cannot be assumed to represent performance through an independent harness.

These reservations are material, but they must be weighed against the favorable direct evidence in our own installation. CommandCode has successfully provided usable inference through OpenCode, and its official API removes the need to rely upon unofficial authentication workarounds. The fact that its models are not generally free imposes a substantial deduction under our original scoring system; it does not erase the practical value of an accessible, functioning service.

CommandCode therefore enters the revised ranking at 72 out of 100, narrowly ahead of Kilo Gateway. It is the leading provider on our combined operational and economic assessment, while Kilo retains the advantage for developers whose principal requirement is avoiding additional inference expenditure.

Reconstructing the Scoring System

The accumulated failures made clear that the original evaluation assigned altogether too much importance to theoretical benefits and too little to the expense of obtaining and maintaining a usable connection.

We therefore revised the scoring system to assign 100 possible points across seven criteria, giving operational compatibility, onboarding, sustained inference capacity, and coding capability substantially greater weight than the number of models advertised.

Evaluation criterion	Maximum points
Authentication and OpenCode compatibility	20
Account setup and onboarding complexity	15
Sustained free inference capacity	20
Coding capability and tool support	20
Reliability and service stability	15
Variety of genuinely free models	5
Economics of paid usage	5
Total	100

A further rule proved necessary. A provider that repeatedly fails authentication or cannot support the intended coding workload receives an operational disqualification, regardless of the excellence of its catalog or the generosity of its published prices.

The result is a field assessment, not a statistical survey of service uptime. Providers that have not been tested directly in my installation retain provisional scores; operational disqualifications refer to the account, model, and route examined, rather than to every product offered by the company.

The latest ranking is as follows:

Rank	Provider	Score	Assessment
1	CommandCode	72	API works in OpenCode; attractive paid access with usage-accounting qualifications
2	Kilo Gateway	70	API works; Nemotron 3.5 Super VL completed an initial run
3	OpenCode Console	64	Provisional; unresolved reports of free-tier quota difficulties
4	Cloudflare Workers AI	62	Provisional; more elaborate configuration
5	NVIDIA Build	56	Provisional; evaluation and trial-use restrictions
6	Z.AI	52	GLM-4.7-Flash usable after repeated overload retries
7	Groq	48	Provisional; restrictive free token-throughput allowances
8	UnoRouter	43	Provisional; extensive catalog but substantial throttling concerns
9	Mistral API	25	Limited straightforward free API availability
10	ModelScope	0	Authentication and account-linking failure
11	Google AI Studio	0	Tested Gemma route failed our sustained-use quota requirement
12	OpenRouter	0	Persistent authentication failures in OpenCode 2

CommandCode’s score requires particular explanation because its favorable result does not arise from generous free inference. It receives full credit for demonstrated authentication and strong credit for coding capability, onboarding, and paid economics, but only four of twenty possible points for sustained free capacity and two of five for free-model diversity. Those deductions prevent a subscription service from being evaluated as though it were an unrestricted source of free computation.

Its 72-point total is therefore a meaningful result under the same criteria applied to Kilo, not the product of giving a paid provider a separate and more favorable standard.

Nor should the two-point difference between CommandCode and Kilo be invested with greater precision than the evidence warrants. We have not conducted sufficiently extensive identical workloads to establish that CommandCode possesses a statistically significant advantage in reliability or completed coding work. What the results establish is narrower but useful: both have worked in OpenCode, while several initially higher-ranked competitors have not.

Methodology note: This analysis was conducted in November 2026 using OpenCode 2, individual provider accounts, published documentation, public issue reports, and developer experiences. The scores are weighted operational judgments rather than measured uptime percentages or controlled model-intelligence benchmarks. Pricing, promotional allowances, model availability, and provider policies may change. No provider paid for or sponsored this assessment.

Enholm Heuristics