# Six Months of Reddit Developer Sentiment on AI Coding > Source: > Published: 2026-09-03 18:16:53+00:00 We went through 6,876 Reddit posts and comments across 266 subreddits, six months of developers talking about AI coding tools, looking for their favorite. What we found instead was routing: developers assigning different models to different parts of the job, mostly because the alternatives kept costing them money or time. **Methodology** The dataset isn’t a survey, but an engagement corpus, so it tells us what developers were really talking about. Sentiment is based on explicit positive, negative, and mixed language in the text rather than a rating scale, so read it as directional. Some threads we pulled in started before the six-month window and stayed active into it. First, we looked at models. We measured how they showed up in the data three different ways, and each one uses a different total as its base, so a percentage from one isn’t directly comparable to a percentage from another: Here's the full shape of the corpus before we unpack each theme. We applied one consistent set of multi-label topic rules across every item, so a single comment about Copilot's new limits could get tagged under pricing, workflow, and multi-tool switching at once. The shares below therefore overlap on purpose: Switching, comparing, and combining models beat every other theme, including pricing and reliability, which tells you a lot about the speed of the industry. **Which models got talked about** Claude got more than three times Gemini’s mentions. Items can name several models at once, so this measures how much a model came up in conversation. It says nothing about who’s actually running which model in production. For real usage share instead of talk share, [kilo.ai/leaderboard/race](https://kilo.ai/leaderboard/race) tracks actual token volume across labs, segmented by open weight and closed models. **Workflow argued louder than model quality** Workflow covered repository context, integrations, and the day-to-day coding experience. Model quality mattered, but it was rarely the only reason someone stuck with a tool. Developers were judging what happened between the prompt and the final diff: How much of the repository can the agent inspect? Can it edit several files without losing the task? Does it run commands and recover from errors? Can the developer review the change before it lands? Does switching models require switching tools? What happens on a larger codebase? The same complaint shows up whether the code that comes back is correct or not: a model can nail the diff and still lose the developer if it eats five minutes gathering context first, or if using it means giving up the editor they already know. A stronger model can sometimes recover from a weak prompt. It can’t recover from missing context, a stalled editor, or a tool that interrupts the developer every few minutes. Models get the attention. Workflow decides what stays installed. **The subscription price wasn’t the real number** Pricing discussion covered credits, quotas, token burn, reset windows, multipliers. The monthly subscription was only the first number. Developers were also comparing: Included usage Premium-request allowances Token-based billing Daily and weekly limits Reset windows Model-specific multipliers The cost of failed attempts The work required to clean up an incomplete result Other developers were lowering the bill by separating expensive reasoning from routine edits: “I don’t trust cli agents in deciding which files to read to build context. I want to build the conext myself so that I’m sure the model knows everything it needs to know. Also Claude Code is way too expensive. With my method (using SOTA models in openrouter + free models for applyng edits) I spend around 10$/month. Also I don’t like to be limited in using just anthropic models.” The math developers kept running: a cheap request that needs three attempts costs more than an expensive one that finishes on the first try. The subscription number on the pricing page doesn’t include the rework, the context rebuilding, or the second model you had to switch to when the first one stalled. GitHub’s own billing overhaul, tighter limits, then a June switch to token-based Credits, was the case study Reddit returned to most; we covered the fallout in [The GitHub Copilot Bill Came Due](https://blog.kilo.ai/p/the-github-copilot-bill-came-due). The trigger wasn’t only the price going up, but also not being able to see the cost coming. The teams handling this best weren’t spending the most, they were [routing each task to the model that fit it](https://blog.kilo.ai/p/we-predicted-the-100kyr-per-dev-ai) instead of defaulting to the most expensive one every time. **Reliability was the most negative theme, and the most specific one** Reliability covered failed edits, regressions, rework. 434 of those items, 31.8%, carried explicitly negative language, making this the only major theme where negative sentiment crossed 30%. The complaints didn’t blur together into one grievance. They split into distinct failure types: A model can write good code and still be frustrating to use inside a specific tool. An agent can finish a task while burning enough context that the next task gets harder. Compressing autocomplete quality, agent execution, and editor performance into a single score is how you end up with a benchmark that doesn’t match the work. **Planning and execution split into separate jobs** Developers explicitly divided roles between models rather than picking one for everything. When we manually reviewed the subset of posts that described actual model use, rather than questions, hypotheticals, or benchmark talk, the split held up and got sharper. 213 items passed that bar. Stages overlap and each row uses its own denominator, so don’t add the columns across. Claude carried the reviewed planning workload, and the open-weight models clustered hard around implementation. That describes what showed up in this corpus. It isn’t a general capability ranking. We ran the split ourselves in a [test that put Kimi K3 on planning and Grok 4.5 on implementation against Claude Opus 5 doing both jobs alone](https://blog.kilo.ai/p/kimi-k3-grok-45-built-the-same-database): the budget combo landed within a small margin, at roughly 4% of the cost. A planning model doesn’t have to write the final patch. It has to get the dependencies, the sequence, and the risks right. An execution model doesn’t have to rediscover the architecture on every turn. It has to follow the plan and stay in scope. The expensive model, in this split, is usually the one doing the work where a mistake compounds. **Humans stayed in the loop** Human review, checking or verifying agent output, was a recurring theme in its own right. One developer’s framing stuck with us: it’s like managing a junior engineer, you’re the senior who checks the work before it ships. AI-generated code still had to survive existing architecture, tests that don’t cover every path, auth boundaries, data migrations, and whatever production does to it. Teams that treated review as part of the process, not cleanup after the process failed, came off better in the threads. **Provider flexibility was a fallback, not a preference** Provider flexibility comes down to one thing: not needing a migration just because a vendor made a decision for you. BYOK, local models, leaving a provider when they change the rules, that’s the whole idea. A dropdown of models a vendor picked for you isn’t the same thing as model freedom: “fwiw, I moved away from these locked-in IDE tools for similar reasons. Using Kilo Code now partly because I can just swap between Claude, GPT, Gemini or local models through Ollama or whatever’s working at the moment. If one provider has issues or weird quota stuff, I just switch. Way less stressful than being locked into one ecosystem.” And just days ago it became clear to the wider market why this matters: OpenAI cut off Cursor’s access to its models after SpaceX acquired the company, a decision that had nothing to do with anything Cursor did. It’s exactly why we’ve argued [your coding tool shouldn’t choose your models for you](https://blog.kilo.ai/p/your-coding-tool-should-not-choose). Strong open-weight models keep landing, but the real lesson developers already took from that is not to bet the whole workflow on one model or provider, availability can change regardless of how good a model is. Models like Qwen, GLM, DeepSeek, MiniMax, and Kimi had far smaller conversation volumes than Claude in this dataset, but the discussion around them was often concrete questions around deployment, local inference, implementation work, and token cost. Also, as we’ve seen in [our own usage data](https://blog.kilo.ai/p/open-weights-is-all-you-need), the use of open models has exploded over the past months, which leads us to believe the share will look very different if we run a similar analysis a few months from now. ## Kilo sits at the intersection of every theme here Kilo Code itself showed up in 1,324 items, 19.3% of the full corpus. What’s notable isn’t the volume, it’s that Kilo mentions touch every theme this article covers: multi-tool switching, workflow, pricing, planning and execution and provider control. Kilo Code came up most often where developers wanted to keep the coding workflow they already had and change what ran underneath it: several models through one interface, provider flexibility, routing, and separate modes for architecture, implementation, and debugging. The live version of this planning-vs-implementation split, updated daily, is on [kilo.ai/leaderboard](https://kilo.ai/leaderboard). **What to take from this** Developers assembled a model stack because no single model held up across every job. Model quality got the mentions, but workflow, context, and tool reliability decided which tools they kept using. The subscription price was a bad indicator of what a tool would actually cost once rate limits, quotas, cost per task, and failed attempts entered the picture. Provider flexibility gave developers somewhere to go the moment they hit a pricing change or a model availability problem. If you’re deciding what to build on: test on work that requires context across your repo, across a planning task, a scoped implementation task, and a debugging task. Track completion, cost, time, cleanup, and what happens when the first model fails. Assign roles on purpose, pick a model for planning and one for implementation, line up a fallback before you need one, and if you’re running a team, keep that flexibility inside an approved provider and model list. If you’d rather not do that assignment by hand every time, [Kilo Auto Model](https://kilo.ai/auto-model) does it for you: it reads the task and routes it to the right model automatically, so you get the planning/implementation split this article describes without picking a model per prompt. **Use Kilo to get the benefits of model freedom: model choice per task, cost optimization through routing, but governed for enterprise at the org level.** *Data covers 6,876 Reddit posts and comments across 266 subreddits, January through June 2026. This is an engagement dataset, not a randomized developer survey, it measures what people talked about, not market share or a representative sample of all developers.*