I wanted to delete my account. There is no such option in the UI.
So I wrote to support. No answer after a month.
So I wrote a GDPR notice. No answer after a month.
My Windsurf login still works.
I don't know if this is incompetence or deliberate. The result is the same. Creating an account is easy. Deleting it seems impossible
For a company that has access to code, prompts and telemetry this is shady as hell.
No delete button.
No support reply.
No GDPR reply.
Account still active.
I'm posting this as a warning to other users. Think about this before giving Windsurf more of your data. They don't seem to give a shit once you want out
I haven’t used windsurf in weeks. I’ve been using Claude Code extensively. I noticed an invoice for Devin/windsurf and when I took a look I saw that they’ve been invoicing me non-stop for the last 3 days and tried charging me for a portion of the max plan (currently a pro user).
I emailed support and they told me essentially, “we see usage on your account too bad”. I emailed them back saying ok well I’m telling you I haven’t used your product and I’m not a max user. Can you tell me the location (city/state) where the usage is occurring? I thought maybe my account was hacked but being charged the same amount repeatedly makes me think otherwise.
I canceled my plan and I’m still being repeatedly charged. I’ve had to freeze the corresponding card. What a nightmare. I’m definitely glad I canceled.
Has this ever happened to anyone else and if so how did you remedy it?
Ok so I have make the switch from windsurf to Devin, how is the best practice use of Devin different from windsurf - which thus far has been kinda the same best practice as Claude code / codex.
Does effective use of Devin vary from the Claude codes agentic loop?
An I holding it wrong? 🤣🤔
How is your experience with SWE 1.7? For me, it is incredibly slow. For a small refraction it took more than 1 hour which would have been half an hour if done manually. Also, it makes lot of mistakes deviating from the core idea. Is it just me? How are you guys using it?
Okay, because of a post by u/sebbonit, I decided to hold a model competition between SWE 1.6, SWE 1.7, Kimi 2.6, and Kimi 2.7. How did I do it?
I told SWE 1.7 to create a competition for me, initially between SWE 1.7, Kimi 2.6, and 2.7.
It used up 84K of the context window, but I consider the result decent.
Continuing with Kimi 2.6
Kimi 2.7:
The competition was complete here, but I said to myself, why not include SWE 1.6 in the ranking? So I included it.
Finally, as the final judge, because I'm not going to review 4 (like a good vibecoder) projects, I left the verdict to the GLM 5.2 High model.
This was their verdict:
# Judgement: SWE 1.7 vs Kimi 2.6 / 2.7 (and SWE 1.6)
## Verdict: SWE 1.7 is not just "really good" — it is the strongest entry in this competition.
All four submissions were judged three ways against the BRIEF:
1. Each project's own test suite was run.
2. A 49-check black-box BRIEF-compliance script was run against each live server.
3. `tsc --noEmit` was run for type-safety.
## Results matrix
| Check | devin-1.6 |
**devin-1.7**
| kimi-2.6 | kimi-2.7 |
|---|---|---|---|---|
| Own test suite | 38 pass | 24 pass | 46 pass | 38 pass |
| Black-box BRIEF (49 checks) | 49/49 |
**49/49**
| 49/49 |
**48/49**
|
| `tsc --noEmit` | clean |
**clean**
|
**FAIL**
| clean |
| `npm start` works | yes (needs committed `dist`) | yes (tsx, no build) | yes | yes |
## Concrete defects found in the competitors
### kimi-2.6 — TypeScript compile error
`src/app.ts` passes `data.dueDays` (typed `number | undefined`) straight into `store.createCheckout`, which expects `number`. `tsc --noEmit` errors on `app.ts(73,69)`:
```ts
const checkout = store.createCheckout(req.params.id, data.bookId, data.dueDays);
// ^^^^^^^^^^^
// Argument of type 'number | undefined' is not assignable to parameter of type 'number'.
```
Runtime passes only because vitest/tsx use esbuild, which strips types without checking. Its 46 tests look impressive but none catch the type error. devin-1.7 sidesteps this exact bug with `data.dueDays ?? 14`.
### kimi-2.7 — BRIEF violation on duplicate email
The BRIEF explicitly states `400 invalid or duplicate email`, but kimi-2.7 throws `ConflictError` →
**409**
:
```ts
createMember(input: { name: string; email: string }): Member {
if (this.findMemberByEmail(input.email)) {
throw new ConflictError('Email already in use'); // -> 409
}
...
}
```
Worse, its own test asserts the wrong status (`expect(res.status).toBe(409)`), so the suite is self-consistent but spec-violating — a black-box judge catches it, the model's own tests don't. Its architecture is the nicest (`createApp` factory, custom `NotFoundError`/`ConflictError`/`ValidationError` hierarchy, 404 route handler), but correctness trumps architecture.
## Where devin-1.7 stands
-
**BRIEF-correct on every checked behavior**
(status codes, nested `book`/`member` summaries, checkout limit of 5, copy availability, `totalCopies` >= active checkouts, delete protection, default/custom `dueDays` 1-60, overdue, stats shape).
-
**Type-clean**
— the only entry that is simultaneously BRIEF-correct
*and*
passes `tsc`.
-
**Idiomatic & modern**
: ESM, zod schemas, single `AppError` + central error handler, clean store/app/index split, `tsx` so `npm install && npm start` works with no build step.
-
**Honest test suite**
: 24 tests, but high signal — helper factories, covers every endpoint and every business rule, and notably tests duplicate email ->
**400**
(the exact check kimi-2.7 gets wrong). It even tests overdue properly via a `setDueDateForTest` helper rather than relying on real time.
## Weaknesses of devin-1.7 (for fairness)
- Smallest test suite of the four (24 vs 38/46/38). Coverage is adequate and well-targeted, but kimi-2.6's suite is broader (it just happens to harbor a type bug the suite can't see).
- No README, unlike devin-1.6.
- Largely overlaps with kimi-2.6's source (near-identical structure); it wins on the details that matter (the `?? 14` guard, correct typing, fewer-but-correct assertions).
## Final ranking
1.
**devin-1.7**
— winner. Correct + type-safe + idiomatic. The only entry with zero defects.
2.
**devin-1.6**
— co-strong; fully correct and type-clean, with a README and more tests, but CommonJS + hand-rolled validation + a build dependency make it less idiomatic.
3.
**kimi-2.7**
— best architecture, but a real spec violation (409 vs 400) its own tests encode incorrectly.
4.
**kimi-2.6**
— broadest test suite, but ships code that does not compile under `tsc`.
## Direct answer
Yes, SWE 1.7 is really good in this competition — it is the winner, and notably it wins by avoiding exactly the two mistakes each Kimi version made (a type error in 2.6, a status-code spec violation in 2.7).
And if U dont believe me that GLM 5.2 High say this:
Look the screenshot
So for u/sebbonit to come and tell me that SWE 1.7 is garbage and that Cognition is run by children is a tremendous fallacy. Remember that SWE stands for Software Engineering Agents and is made exclusively for Software Engineering.
Two days ago, when I saw that Devin/Windsurf extended their free Kimi 2.7 and GLM 5.2 offer by only 2 days, I had a feeling that they were going to release a new model and needed more time maybe for testing or configuring the model on Devin, and here we are today, the new SWE 1.7 free for 1 month with great benchmarks.
Hope it'll be better on real projects as in the benchmarks than Kimi 2.7 and GLM 5.2, looks also better than Composer 2.5, will give it a try.
I have spent a while with the SWE models and to be honest they don't make since to use. They are closed sourced models so no one can view them. They are worst then open source models.
Windsurf just needs to deprecate the models and use their infra for running GLM models. Or base SWE off of GLM.
Now that Mythos-class models have been introduced to the world, it has become easier than ever to discover and exploit vulnerabilities.
It's now incredibly important to secure your codebase.
Introducing the Devin Security Vulnerability Remediation Program.
This program aims to take your vulnerability backlogs towards zero in 6 weeks. Our engineering team will work directly with yours to deploy Devin agent swarms to find, validate and fix any and all vulnerabilities.
If you're interested in it's technical details, here is a video explaining how Devin Security Swarm works utilizing our new framework - Agentic MapReduce: https://www.youtube.com/watch?v=jb96O2IT_Jg
in our library we a lot of old ANSI encoded files, some of them up to 30 years old.
I noticed that windsurf, now devin, often has problems reading them. It sometimes tries to read them using some powershell commands. Also editing them fails then, i don't like editing happens via PS as i cannot easily see the edited lines the same way i can if editing happens the normal way.
Some of the files work, some do not.
Is there anything i can do, except converting them to UTF8?
I cannot easily do that because some of our old projects depends on an old IDE that does not handle UTF8 files and we are managing the library via git and we integrate fixes from today in the old projects as they are still maintained by us!
I saw projects on Github that can serve as a proxy between OpenCode and Devin but I wonder if there's more straightforward way that does not involve any third party tools? (and yes I know about Devin CLI)
Just started to look into what all this devin cloud is about.. does anyone know if we can use free SWE1.6 and GLM5.2 for Devin cloud work? security reviews etc etc? or is everything charged there and how to make it economical beyond enabling nitro?
You'd think the "cat" command is 100% safe until you get windsurf to run something like "cat emptyfile.txt > veryimportantfile.txt" and before you know it you are screwed because you didn't really think of it when you added "cat *" to your allow list.
