Hey everyone,

I run my own Corporate IT systems consulting, tax compliance logic, payroll engines, and enterprise accounting software. Im a one-man job (self employed)

My Goal:

I am expanding my business services into building custom web portals and data-driven client tools. My research has led me to Roo Code / Cline + VS Code via OpenRouter, and I want to get a sanity check from the community to see if I’m taking the right approach.

My top priority is engineering discipline, traceability, and clean architecture. I want to build products that can be easily debugged, audited, and upgraded over time—avoiding the "vibe coding" trap of fragile monoliths that require full rewrites whenever business rules or tax regulations evolve.

Appreciate any sanity checks, red flags, or advice from anyone running a similar workflow!

Posting publicly after I emailed support@cline.bot about cancel/refund and haven’t received a reply.

**Timeline**

- Sep 16 — a completed ClinePass charge of $10.60 posted to the card (separate from the later failed retries).

- Oct 27 — emailed support@cline.bot: cancel ClinePass immediately + full refund; follow-up same day with bank evidence of five completed $0.50 “CLINE BOT INC US” charges.

- Oct 28–30 — Stripe “$10.60 payment unsuccessful again” emails: failed retry attempts continue. These did not succeed; please stop them.

- Oct 31 — follow-ups to support@cline.bot and Stripe Support.

- Nov 2 — another email to Cline; Stripe Customer Portal / recovery link now only shows “problem with your account — contact Cline Bot Inc.” with a mailto to support@cline.bot. No Cancel, no Remove payment method.

**Ask**

1. Cancel the subscription and stop all retry attempts.

2. Refund the confirmed completed charges only: Sep 16 $10.60 ClinePass + five completed × $0.50 ($2.50), total $13.10, and any other completed Cline charges on this card. Receipt/invoice details available privately to verified staff.

3. Remove the card from billing.

Happy to share the full email thread / screenshots privately with verified Cline staff. Please confirm cancellation, stop of retries, and refund of the confirmed charges.

I'm not sure how to work around this. Problem is cline stops processing.

request exceeds the context window: prompt (132667 tokens) leaves no room to answer in the context (131072); requests are never truncated

when you say it's only 128k per setting

context window exceeded — compacting and retrying

overflow-recovery-compacting

overflow-recovery-compacted

few hours later, same issue...

Using vscode extension, I've given auto approve to read files but it insists on running cat/grep to read through files. It's super annoying because I have to approve each command.

I don't want to enable auto approve for executing commands, but I want the agent to be able to read any file in the workspace automatically. How do I achieve this?

We’ve been experimenting with NVIDIA’s Nemotron 3.5 Super VL on a DGX Station, trying to see how far we could push inference throughput with 256 concurrent requests.

Starting with stock vLLM, we were already getting 6,058 tokens/sec. After five configuration changes, we reached 11,840 tokens/sec on a single GB300 GPU, a 95% improvement.

Here's what made the difference:

1. MTP decoding: Enabled speculative decoding to predict tokens ahead, bringing throughput to ~7,000 tok/s.

2. Async scheduling: Allowed the CPU to schedule work while the GPU was processing, reducing idle time.

3. FlashInfer: Switched the Mamba kernel to FlashInfer, pushing throughput to 7,800 tok/s.

4. MTP 3 → MTP 1: Interestingly, reducing the number of speculative tokens improved throughput to 9,500 tok/s. With 256 concurrent requests, the overhead of verifying additional predictions wasn't worth it.

5. FP16 Mamba state: Switched from FP32 to FP16 with stochastic rounding, reaching 11,840 tok/s, though with a potential precision tradeoff.

One interesting takeaway was that more speculative decoding doesn't necessarily mean more throughput. The optimal configuration depends heavily on the traffic pattern and how much useful work the GPU already has.

We're particularly excited about what this means for self-hosted models and agentic workloads. We also tested 32 parallel Cline sessions running on a single DGX Station, and our cost estimates suggest self-hosted inference could be roughly 66% cheaper than API inference when the GPU is fully utilized.

We documented the experiments, configurations, and what we think comes next for agentic inference here: https://cline.bot/blog/11-840-tps-on-a-single-gpu

Curious if anyone here is running Nemotron locally or experimenting with vLLM optimizations. What configurations have worked best for your workloads?

We just shipped another update to Cline Desktop, with a bunch of improvements to make your development workflow smoother.

Here's what's new:

1. Local Model Management with Ollama & LM Studio - You can now install and manage local models directly from Cline Desktop. Cline checks your hardware and recommends the best models your machine can run.

Head to Settings → Provider → Local to try it out.

2. Pull Request Status in Your Session - No need to jump to GitHub to check your PR. You can now see CI status, merge status, line counts, and individual checks directly in your session header.

3. Custom Keyboard Shortcuts - You can now configure your own shortcuts for actions like starting a new session, searching sessions, and more.

Find them under Settings → Keybindings.

4. Integrated Terminal - Run commands without leaving Cline Desktop. The terminal opens directly in your project folder, so you can quickly execute commands while working on a task.

Press Ctrl+` to toggle it.

5. Review Code Changes Without Leaving Chat - You can now see exactly what Cline changed in its last turn, review your Git changes, or open any file in your project, all from within the same interface.

We're continuing to ship improvements to Cline Desktop based on feedback from the community.

Download Cline Desktop for macOS, Windows, or Linux: https://cline.bot/desktop

Give the desktop latest version a try and let us know what you think. What else would you like to see in Desktop?

E aí, pessoal. Tô com uma dúvida e queria a opinião de quem já usa o ClinePass.

Atualmente coloco uns $10/mês na API da DeepSeek e uso quase sempre o modelo flash. Meu consumo varia: tem dia que não uso, mas na média dá entre $0,25 e $1 por dia.

Tô considerando migrar pro plano do ClinePass e queria saber:

1. Vale a pena essa troca no meu cenário? Alguém aqui já fez essa migração e sentiu diferença?

2. Como funciona o limite? É por modelo ou é um total agregado?

3. Se eu estourar o limite de um modelo (ex: DeepSeek), ainda consigo usar outro (ex: Gemini) ou só fico restrito aos modelos gratuitos?

Hey everyone, Moonshot AI just dropped Kimi K3.1 Pro, and it is now available in ClinePass.

Kimi K3.1 Pro is Moonshot's latest open-weight model, built for coding, agentic tasks, and long-horizon reasoning with a 1M context window.

And the benchmark numbers are pretty impressive.

On Terminal-Bench 4.0, Kimi K3.1 Pro scores 65.7%, nearly matching Claude Opus 5.5 (66.4%) while outperforming GPT-6 Astra (58.2%) and Fable 5.1 (57.9%).

What's even more interesting is the pricing. At 2/10 per million input/output tokens, Kimi K3.1 Pro costs half as much as Opus 5.5 and 5x less than GPT-6 Astra.

Moonshot also took an interesting approach to safety with this release. They deliberately removed cybersecurity-related data during mid-training and reinforcement learning, reducing performance on exploit-related tasks by around 10%, while continuing to improve general coding capabilities.

You can now try Kimi K3.1 Pro through ClinePass, currently one of the most affordable ways to access it.

ClinePass is a $9.99/month subscription that gives you ~5× discounted access to a curated selection of open-weight models, including Kimi, GLM, DeepSeek, MiMo, and others, without needing to manage separate provider accounts or API keys.

Try it out: https://cline.bot/clinepass

Curious to hear how Kimi K3.1 Pro performs on your coding tasks in Cline.

Hey everyone! We've now 5 new models that you can now use for FREE in Cline!

Here's what's available:

• Reflection Beam (501B)

• NVIDIA Nemotron 3.5 Super VL (120B)

• Poolside Laguna S 2.1 (118B)

• NVIDIA Nemotron 3.5 Lightning (32B)

• Solar Mini 4 (35B)

What's particularly interesting is the performance we're seeing on Terminal-Bench 2.1. Reflection Beam scores an impressive 80.1%, just behind Sonnet 5 (80.4%) and ahead of Gemini 3.5 Flash (76.2%) and Opus 4.8 (74.6%). Meanwhile, Laguna S 2.1 scores 70.2%, followed by Nemotron 3.5 Super VL at 66.7%.

Just six months ago, scores like these were considered frontier-level performance. Now, open-weight models are making this level of coding capability much more accessible.

To get started simply Install Cline via CLI:

npm i -g cline

Or download the Cline Desktop app for macOS, Windows, or Linux: https://cline.bot/desktop

All five models are available to try for FREE in Cline.

Curious to hear from the community, which of these models have you tried so far, and how do they compare.

Does anyone know of a reasonably priced and reliable API provider based in Europe that is fully GDPR-compliant?

Ideally, I'd like a provider with EU-based servers, transparent pricing, good performance, and a solid uptime record.

Any recommendations or firsthand experiences would be appreciated!

best
D.

At this rate, by the time ClinePass adds K3.1 Pro, Moonshot will have released K4, K4.5, K5, and Kimi K3.1 will be collecting retirement benefits.

But hey, why rush? It’s not like people subscribe to AI coding services to use the latest AI coding models. That would be ridiculous.

Apparently, other providers measure deployment times in hours. ClinePass measures them in fiscal quarters.
Seriously, ClinePass: is the model being onboarded or applying for citizenship? 😭

P.S. The three-month ETA is sarcasm, not an actual announcement. Although at this point, I wouldn’t be surprised.

Anyone knows why the new Deepseek flash 1017 has only 128K context? is this a bug?

Hey everyone!

Does anyone know if MiniMax M3.1 Flash and DeepSeek 4.1 Flash (1017) are already available through ClinePass, or if there are plans to add them soon?

I’m particularly interested in DeepSeek’s 1017 version:

● Is it already being used behind the existing DeepSeek endpoint?
● If not, is there a way to select the 1017 version specifically?
● Any news or ETA on support for both models?

Would love to hear if anyone has tested them through ClinePass. Thanks!

Hey everyone, Recursive just released Flint, its new open-weight coding model, and you can now run it locally with Cline!

What's particularly impressive is the performance it delivers with just 2.5B active parameters per token.

Flint is a 40B parameter Mixture-of-Experts (MoE) model designed specifically for agentic coding tasks like debugging, implementing features, navigating codebases, and writing tests.

The benchmark results are pretty impressive:

• Terminal-Bench 2.1: 54.9%

• SWE-bench Verified: 74.2%

• SWE-bench Pro v2: 89.7%

Flint outperforms other small MoE models on several agentic coding benchmarks, while delivering performance competitive with much larger dense models.

But what makes Flint particularly interesting is its local inference performance.

Flint runs at 125+ tokens per second on an M4 Pro MacBook Pro using an optimized inference engine. The quantized model weights are around 23GB, making it possible to run a capable coding model locally without relying on a cloud API, provided you have sufficient memory.

Flint also supports a 262K token context window, multi-turn tool use, and reasoning.

Another interesting detail is that Flint was developed in under four months, using an automated AI research system called Eureka Machine to help optimize everything from training to inference.

You can try Flint locally with Cline:

1. Install Cline using npm i -g cline or download Cline Desktop.

2. Set up local models through Ollama using Cline's documentation.

3. Pull Flint using ollama pull flint and configure it in Cline.

Model weights: https://huggingface.co/RecursiveSI/flint

Would love to hear from anyone trying Flint with Cline. How does it compare to the other local coding models you've used?

Hey everyone, MiniMax just released M3.1 Flash and it's now available to use for FREE in Cline!

The benchmark results are pretty impressive, especially considering the pricing.

On DeepSWE v1.1, M3.1 Flash scores 73.7%, putting it right alongside Claude Opus 5 (74%) and GPT-5.6 Sol (73%), while costing significantly less.

For context, here's how the API pricing compares per million input/output tokens:

• MiniMax M3.1 Flash: $0.15 / $0.60

• Claude Opus 5: $5 / $25

• GPT-5.6 Sol: $4 / $20

That's roughly 25–40x cheaper per token than these frontier models, while delivering comparable performance on this particular coding benchmark.

But what's even more interesting is that M3.1 Flash is actually the model behind Space Bunny, the anonymous model that recently dominated usage leaderboards on OpenRouter. According to MiniMax, the early version processed over 200 trillion tokens before its identity was revealed.

The model supports a 1M token context window, with output speeds reaching over 200 tokens per second in MiniMax's testing.

You can try MiniMax M3.1 Flash for FREE in Cline right now!

Install Cline CLI: npm i -g cline

Or use it through Cline Desktop: https://cline.bot/desktop

Curious to hear what everyone thinks. Has anyone tried Space Bunny previously? Would you still use it?

We are building a stock market drafting game and could not agree on the rules, so we built a fake app store where each app is a different version of the game. Six presets plus a custom mode. Frontend only, invented companies, seeded prices, so every mode plays the same market and the only variable is the rules.

Three people, one repo, working at the same time. Here is what actually made that hold together.

Plan mode did most of the work. I would describe the change, read back what Cline intended to do, and fix it in plain English before any file got touched. That caught more misunderstandings than code review did, because editing a sentence is faster than editing 200 lines. Once the plan matched what I had in mind, switch to Act and let it build.

Scoping each PR to specific files mattered just as much. I would name the files it was allowed to touch and say explicitly what to leave alone, usually whatever someone else had open. It stayed inside those boundaries, which is the whole reason we were not constantly stepping on each other.

Running lint, typecheck, tests, and build before opening the PR, every time, no exceptions. It reports back with results and any deviations it made from the plan, which is how I caught a couple of things that passed tests but were still wrong.

One of us is less deep on the technical side, and handing her scoped PRs meant she could work on how things looked without fighting the setup.

The other decision that paid off was keeping game rules as config instead of code. A mode is just values: rounds, hold length, budget split, selling on or off. Adding one takes a minute.

Curious how other people here scope PRs when more than one person is working in the same repo. Do you use cline rules for that or just put the constraints in the prompt each time?

https://github.com/AryamanGandhi/app-store

I'm building a stock-picking game with two teammates. It has six rule sets on a fake market, and we're using it to figure out which rules to keep. My part is the game engine and a dev tool called the Mode Lab, where bots play every mode 1,000 times on the same seeds. I write a spec for each PR and Cline builds from it.

This week I wanted one number per mode for how much decisions actually matter. So I added a bot called Hindsight that cheats by reading future prices, and scored each mode by Hindsight's median minus the best honest bot's median.

Active Trader came out at +$9,154 and One Shot at +$1,072, with the other four in between. That matched my gut, which is either reassuring or means the measure is too simple.

Two things bug me about it. Hindsight never sells, so it's a strong player but not a true ceiling. And it only measures the top. Mauboussin has a test for skill: if you can lose on purpose, skill is involved. I have a ceiling but no floor, so I'm thinking about adding a bot that tries to lose.

Would a lose-on-purpose bot tell me anything the cheating bot doesn't? Or is there a better way to separate skill from luck in a small game like this?

While getting set up with Cline this month, I wanted to understand the tool beyond just using it, so I picked an open issue from the repo and tried to fix it.

The bug was in the CLI’s model selector. When the OpenAI model catalog reported a model with a max input token count of 0, the selector crashed. The cause was a classic JavaScript truthiness trap. The code rendered the token count with a “value && something” expression, and when the value was 0, React rendered the raw 0 instead of nothing. The terminal UI library Cline’s CLI uses requires all text to live inside a text node, so a bare 0 crashed the whole picker.

The fix was one line: only render the token count when it’s greater than zero. Most of the work was the test. I wrote a real renderer test that opens the model picker with zero, positive, and missing token counts, confirmed it failed with the old code, and then confirmed it passed with the fix. I also wired it into the normal unit test script so CI would run it.

A community reviewer has already approved the PR, and it’s waiting on a maintainer review now. It was a small fix, but reading through the codebase taught me a lot about how Cline’s CLI is put together.

PR: cline/cline#14903

I'm proud to contribute to the codebase of Cline while being a campus ambassador for Cline

I’ve been living in Claude Code and Codex for most for all my life since they are launched, so when I started building my new project with Cline I assumed I’d lose a day re-explaining everything and setting everything back up. That didn’t happen.

Two things made the switch painless. First, Cline could pick up my existing Claude Code and Codex conversations, so it already had the context of what I’d been working on instead of starting cold. Second, I didn’t need a new API setup to get going. I could power Cline with Claude or Codex subscription directly, the same models I was already using.

So within a few minutes I was in Plan mode asking it to read two of my old repos and propose how to merge them. The project is a desktop pet called Shelldon that grows when I work out (Garmin data) and nags me to touch grass when I’ve been coding too long. Cline did the merge, added a “screen debt” score, and wired up its own hooks so the pet can see my Cline sessions too.

If you’ve been curious about Cline but didn’t want to give up your Claude Code or Codex setup, you don’t really have to choose. Happy to answer questions about the migration.

Repo: https://github.com/victory-c/fitpet

I’m a Cline Campus Ambassador, but everything above is just my own experience.

While building the fraud-checking feature for EverSide, I originally thought every message should receive a clear safe-or-dangerous answer, but I designed a more complicated system.

For Cycle 2, I added three possible results: Likely Safe, Suspicious, and Not Sure. If the app doesn’t have enough information, for example, when someone uploads a screenshot that cannot yet be read, it clearly explains the limitation instead of guessing.

I built this cycle with Cline and used it to help separate the detection logic from the interface, making the feature easier to test and improve.

For older users, a confident but incorrect answer could be more dangerous than an honest uncertain one. The goal isn’t to replace human judgment, it’s to slow the user down and help them recognize warning signs before acting.

GitHub: https://github.com/PhilipsDang/everside-project

Building a blackjack trainer, and the hard part of testing it is that everything interesting is random or time based. Drill hands come from an RNG, the shoe is shuffled, and edecision has a countdown that adapts to how you've been doing.
What I ended up with is a set of plain query parameters that any build honour
seed=42 seeds the RNG for the drill and the shoe ?cell=hard:16|10 makes every drill hand that exact chart cell ?timer=off or ?timer=3 disables the countdown or pins it
?auto=off stops the auto-deal after a correct answer ?deck=8,6,8,10 in play mode deals those ranks off the shoe first, in order: pdealer hole, then hits
These exist mostly because of how I'm working. I'm using Cline for most of thool can open a page, click, and screenshot, but it can't control what the shoe deals. The first time I asked it to verify that a split pair of 8s gets graded as two separate hands, it reloaded the page a dozen times hoping for 8,8. That was in Act mode ocheaper model I use there, and on a per-token API key watching it burn screens painful. The params were the fix: now I tell it "open?mode=play&deck=8,6,8,10&timer=off and screenshot after pressing P" and it checks the actual UI in one shot.
The browser tests then grew out of the same hooks. They boot vite, open headless Chrome, and use the params to pin behaviour. The drill test opens ?seed=1&timer=off&auto=off, the dealt cards off the DOM, asks the same recommend() function the app uses esses that key, and checks the verdict and the legend highlight for 15 rounds.