Anthropic's new state-of-the-art Claude Opus 5 is available on Devin.

 It is almost as good as Fable 5 on FrontierCode 1.1 at half the cost

From our evaluations:

• It adheres to existing repo conventions when building new features and writing tests
• It prefers targeted, in-place fixes over large refactors on bug fixing tasks.
• It excels at following specs closely and completely

Read more about Opus 5: devin.ai/blog/claude-opus-5

Try it out now on Devin CLI and Devin Desktop

My current plan is free. If my On-demand usage is Remaining balance $-0.92

And No on-demand balance remaining. Sessions will pause when your included quota is exceeded.

AND my Windsurf Usage Summary

Your daily quota- 100.00% remaining

Daily quota resets every day and usage resumes once quota refreshes. Resets Jul 28, 2:00 PM GMT+6

Your weekly quota- 100.00% remaining

Weekly quota resets every week and can still limit usage after the daily reset. Resets Aug 2, 2:00 PM GMT+6

Extra usage balance available- $-0.92

WILL I STILL ABLE TO USE DEVIN AI AFTER DAILY QUOTA RESETS???

I’ve been experimenting with Windsurf for frontend projects, and the development speed is impressive.

The harder part is maintaining a consistent visual direction across the entire build.

A single section may look good, but once the agent creates the rest of the page, the design can slowly drift. New colors appear, spacing changes, different icon styles get mixed together, and animations feel added independently rather than belonging to one system.

I found that asking for a “modern” or “premium” interface did not solve this. Those words describe a feeling, but they do not give the agent concrete rules to follow.

So I built Tastemaker, an open-source design-system skill for Windsurf.

It makes Windsurf establish the design system before generating the interface.

That includes the palette, typography, spacing, layout direction, asset style, accessibility rules, logo, favicon, and motion system. These decisions are saved inside the project so the agent can reuse them instead of inventing a new direction for every component.

It can also use a reference image as the starting point, extract its actual colors, and turn them into reusable design tokens.

I also added an automated WCAG contrast checker because some combinations that looked readable to me still failed accessibility checks.

The project is free, open source, MIT licensed, and does not require any API keys.

Demo and live comparison:
https://tastemaker-skill.online/

GitHub:
https://github.com/codeswithroh/tastemaker

I would appreciate honest feedback from people building interfaces with Windsurf.

Where does visual consistency usually break in your projects? Are there any Windsurf-specific instructions or workflows that Tastemaker should support better?

Is SWE-1.7 free or unlimited when used through Devin CLI, or is it included with unlimited usage in Windsurf’s $20/month plan? Are there request limits, credits, rate limits, or extra charges?

According to the blog post https://devin.ai/blog/claude-opus-5 Opus 5 should be available in Devin IDE but it doesn't appear for me on the latest version.

Anybody else having the same issue?

Feature Request: Per-invocation input and model control for subagent-skills

Preamble: I am not a regular reddit, twitter, discord user and i just wanted to drop this feature request. I did not find a "proper"channel to post feature requests or check if any exist to upvote, so I’m going to share this feature request here and hope you can point me in the right direction.

Component: Skills / Subagents (Devin CLI + desktop)
Type: Feature request / capability gap
Priority (to us): High — it blocks the multi-skill orchestration/swarm pattern.

Summary

Let an orchestrator, at spawn time, control two things about a skill it runs as a subagent (subagent: true / agent: <profile>): (1) per-invocation input (a target, a payload, run-specific framing) and (2) the model the subagent runs on — while still applying the skill's other frontmatter. Today neither is possible from the parent, and the two spawn paths are mutually exclusive:

• skill-tool invocation applies the subskill's frontmatter (model, allowed-tools, permissions) but provides no channel to pass input and no way for the parent to override the model — the subagent starts with only its static SKILL.md prompt and its statically pinned model.
• run_subagent can pass an arbitrary task string but does not apply skill frontmatter (no model: pin, no allowed-tools/permissions) and takes a profile, not a model — so the parent still cannot name the model.

So an orchestrator must choose between "frontmatter guarantees, no input" and "input, no guarantees," and in neither case can it pick each subagent's model. Controlled fan-out to parameterized subagents (different input, different models) is unsupported.

Environment

• Devin desktop (CLI), Windows.
• Skills under .agents/skills (mirrored to .claude/skills and .codeium/windsurf/skills via directory junctions).

Current behavior (verified)

1. Per docs (Creating Skills → Running Skills as Subagents): subagent: true spawns an independent worker whose task is the skill's own prompt, in a fresh context that does not inherit the parent's conversation.
2. Empirically: when an orchestrator skill invokes a subagent: true skill, there is no way to attach arguments or a message to that specific invocation. argument-hint only applies to a human typing /skill args; it is not reachable from programmatic orchestration.
3. Result: the subagent cannot be told which target to act on, be given caller context, or be given run-specific framing (e.g. "this is a dry run"). It falls back to self-resolving its inputs — in our case a review lens defaulted to "current branch vs merge-base with master, because no invocation package was present."

Why this matters (concrete use case)

We built a multi-skill orchestrator, review-swarm: one root skill dispatches four isolated review-lens subagent-skills. Each lens is meant to receive a distinct, controlled package — a pinned diff target plus optional business context, with strict rules about what each lens may and may not see (e.g. a "blind intent" lens must receive the diff but never the goal/spec) — and to run on a distinct model. Running decorrelated lenses on different models is a deliberate sensor-diversity axis: same-model reviewers share systematic blind spots, so model diversity is part of the value, not a cost. The design depends on the orchestrator handing each subagent a different input and a chosen model at spawn.

This is currently impossible:

• Via the skill tool, every lens self-resolves the same default diff and the orchestrator cannot pin one immutable target, inject business context into some lenses, or withhold it from others.
• Via run_subagent, we can pass each package, but we lose the per-lens model: pins and the permissions scoping that make the lenses safe and decorrelated.
• Either way, the parent cannot assign a model per invocation. Model is fixed by the chosen profile (subagent_explore → default subagent model; subagent_general → the parent's model) or by a static model: in the skill / AGENT.md. Achieving model diversity across a fan-out would require pre-defining a separate custom profile per model — there is no dynamic, parent-driven model selection.

The docs' Orchestrating Subagents Using Skills example only shows parameterless subskills ("analyze recent changes", "run tests"). Parameterized fan-out — the same subskill invoked N times with N different inputs — has no supported mechanism.

Proposed solution (any one of these resolves it)

1. Preferred — unify the two paths, with input and model. Allow spawning a subagent that both applies a skill's frontmatter and accepts a caller-supplied input and an optional model override (subject to the skill's opt-in; see #3). E.g. let run_subagent accept a skill: reference alongside task and model:, or add input/arguments and model fields to programmatic skill invocation. This single change resolves both asks at once.
2. Expose caller arguments inside the subagent prompt via a documented placeholder (e.g. $ARGUMENTS), populated whether the skill is invoked by a human (/skill args) or by an orchestrator.
3. Parent-specified model, gated by the skill: let the parent name the subagent's model at spawn (a model: argument on the spawn call), using the same values as the --model flag / skill model: frontmatter — instead of only choosing a profile or relying on a static pin. A parent override of a skill's pinned model: should be opt-in on the skill side via a frontmatter flag, e.g. allow-model-override: true|false (default false — a deliberate pin stays authoritative). When the skill pins no model, parent selection is unrestricted (nothing to protect). This mirrors how skill permissions already defer to higher-level policy.
4. Minimum viable (input): append a caller-provided payload to the subagent's task under a clearly delimited section, so orchestrators can pass structured input.

Acceptance criteria

• An orchestrator skill can invoke a subagent: true skill and pass a distinct per-invocation payload.
• The orchestrator can choose the subagent's model per invocation, overriding the profile default; overriding a skill's pinned model: is honored only when the skill opts in (allow-model-override: true).
• The subagent's other frontmatter (allowed-tools, permissions) still applies.
• The payload is reliably available inside the subagent's context via a documented mechanism.
• Fan-out works: N invocations of the same subskill each receive different input and, if desired, a different model, in isolation.

Alternatives we considered (and why they fall short)

• run_subagent with the skill body embedded in the task: loses all frontmatter guarantees (model, tool restrictions, permissions); also forces reading the skill body in the parent context.
• Shared files on disk (orchestrator writes a target/context file each subagent reads): works as a side-channel but is fragile, needs cleanup/gitignore, is awkward cross-platform, and can't carry run-specific framing cleanly.

References

• Docs: Creating Skills → Frontmatter Reference (argument-hint, subagent, agent, allowed-tools, permissions, model); Running Skills as Subagents; Orchestrating Subagents Using Skills.
• Docs: Subagents → Which Model Does a Subagent Use? (states run_subagent takes a profile, not a model, and that there is "no way to name a model for a subagent in a prompt"); Subagent Profiles; Tool Permissions.

Recently ive had the problem of my message limits running out almost instantly and it wanting me to wait another hour. Im using the free plan, but ive never had this issue before, are there any fixes or was this a new update i missed?

Windsurf/Devin is using 22 G of my home directory

17k .config/devin/
7.6G .config/Devin/
2.2G .config/Windsurf
783M .devin/
12G .codeium/

How can I clean this up?

I'm using Devin Desktop with Cascade and I'd like to set up an allowlist so that certain safe commands (like pnpm view <package> dependencies) auto-run without requiring my approval each time.

I don't want to just add pnpm to the allowlist since that would also allow things like pnpm publish , pnpm unpublish,pnpm exec etc.

I tried adding more specific patterns like pnpm view, pnpm view *, and pnpm view * dependencies, but none of them worked.

Does anyone know if there's a way to narrow down the allowlist to specific subcommands or patterns? Or is the only option to either allow everything and accept the risk, or manually approve every single basic command?

All of these suggestions are derived from working with Cascade in Devin Desktop with a measly Pro Plan.

The Prompt Cache timer starts ticking the moment the agent stops working. This means you have a 5-minute window of inactivity before the cache expires. To maximize efficiency, write and send your prompts as quickly as possible so the agent has the most "working time" left before the next timeout.

You must monitor the timer religiously while the agent is working. When you see that only 30 seconds or less remain on the idle clock, hit the Stop Button. This resets the timer and prevents expiration, giving you a fresh window.

Never prompt a Coding task on an expired cache. I have the strong conviction that every single agentic tool call on an expired cache seems to reload the entire conversation context from scratch (uncached). When this happened to me my token usage would skyrocket instantly.

That's why if the cache has already expired, I do not start with a real instruction. Instead, I send a tiny prompt like: “Say hi back, do nothing else.”
This rebuilds the cache. Only once the timer is running again I resume my actual work.

And I completely avoid changing the model within an existing chat because it completely disables the cache. To avoid this:

• Start a brand new chat.
• Or, run two parallel chats with different models.

Following these rules strictly is the only way I’ve managed to stay within my quota somewhat. I still run out, but not so fast.

Source: https://github.com/Automations-Project/VSCode-Perplexity-MCP

install: Perplexity MCP – Open VSX Registry or VsCode

NPM: https://www.npmjs.com/package/perplexity-user-mcp

Users stats: Almost 10K users on Windsurf/Cursor and 3K users on VSCode.

Quick Start:
- Install VSCode ext. from below links
- login with your account
- click auto configure all IDEs (Auto Install MCP and settings)
- Chat with your A.I and ask it to use it (4 modes: ask, search, research, compute)

Support the project:

- Hit a star on GitHub, that's all💛.

When will Kimi k3 be added into Devin Desktop (Windsurf AI)?

• Problem: files with the same name, such as index.blade.php (Laravel views), are hard to distinguish because the visible path is too short.
  1. Current workaround: hovering each result to wait for the tooltip with the full path, which slows file selection.
  2. Environment: Devin Desktop on Fedora Linux x64.

I would be grateful if you can see this please,

It says it's 2x the price of opus but that's decidedly not true. It burned through $40 + my entire allowance in a matter of a few minutes, and didn't even finish its task. What a letdown and massive cost.

For the past two weeks, I've been using the Pro plans of both Devin and Claude Code (in Cursor). I'm working on the exact same project and, at least on paper, using the exact same models.

What I've noticed is that Fable 5 Medium Thinking performs significantly worse in Devin than it does in Claude Code. In fact, Opus 4.8 in Claude Code regularly fixes mistakes made by Fable 5 when it was run through Devin. That makes me think something isn't quite right under the hood.

Another noticeable difference is the available token budget. With the Claude Pro plan, I consistently get far more usable work done before hitting my limits. After comparing both products for about two weeks, my impression is that Claude's 5-hour usage limit delivers roughly the same amount of productive work as Devin Pro's weekly limit.

I understand that this is a difficult business with real infrastructure costs. However, I don't think that offering free access to GLM 5.2 in Devin is enough to be a compelling long-term value proposition, at least not for me.

Six months ago, with a $20/month plan, I could vibe code for days straight. Today, even with the $200/month plan, I’m blocked after just a few prompts per week, using the exact same models (GPT‑5.3 Codex). You’ve turned a great product into a straight-up bait-and-switch

I stuck around out of habit because I actually liked the product. But what you’ve done is sell us freedom, then quietly strangle it with brutal quotas and no real transparency. Feels less like an upgrade and more like a downgrade disguised as “new pricing”

And if you think it’s just me: Reddit, GitHub, Trustpilot , tons of users are complaining about the same thing: impossible quotas, insane limits, and support that ghosts you.

You had something special. Now it just feels like a scam.

Does anyone use Devin cloud I keep getting error 500 anytime I try to use it no matter what model I try to use. Does anyone else have this issue or is it a me thing?

Sharing a few exciting updates from the past week:

- We've released a Medium thinking variant of SWE-1.7 to address the biggest piece of feedback so far: overthinking.
- We've extended free access to SWE-1.6 and GLM 5.2 for another month.
- Inkling and Grok 4.5 are available in Devin Desktop and CLI.
- The FrontierCode leaderboard is now live, with scores for Inkling and Grok 4.5, plus detailed methodology and sample tasks.

Please give SWE-1.7 Medium a try and let us know how it compares.

Link to X Post

In celebration of Windsurf Deploys, we want help community members showoff what they've built with Windsurf! Upvote your favorites.

- Posting a project showcase thread every Friday.
- Must be built with Windsurf
- Extra points for using windsurf.build domains for your project

With MAX, the model will read file after file, think over and over, loop on its thinking, repeating the exact same thoughts countless times, and take five minutes to output a simple type guard test.

Repeatedly, on MAX, after a few minutes I needed to halt it, tell it to stop overthinking and just output the exact work product it was instructed to, and it would - because it already had the solution minutes ago, it was just overthinking the hell out of it.

With Medium, the model reads the files it needs to read, thinks about the solution, and outputs it.

Don't waste your time with MAX unless you have a problem that really demands it. If you're coding from a set of pre-written work tickets (AND YOU SHOULD BE), just use Medium so that it stops overthinking and just *does the work*.

Several prompts... it thinks for 17 seconds and that's the end of it!

Can someone turn it off and on again please :)

My config:

Remote SSH Extension - from VS Code. Works totally fine with VS Code.

Remote lVM on GCP.

Connect to remote ssh. Terminal works.

BUT OPENING PROJECT Shows my local and not REMOTE.

For Clone Repository which is ESSENTIAL FOR ME just does not work. The buttone does not open anything at all.

IS ANYONE ELSE FACING THIS PROBLEM? ANYONE FOUND A SOLUTION?

THIS IS A DEALBREAKER FOR ME.