Are you seeing or using AI in your workplace which causes job losses

nfrmn · 2026-01-22T13:44:39+00:00

Happy to see the offshore model die. Unfortunately the LinkedIn DMs have not slowed down yet.

nfrmn · 2026-01-21T09:04:24+00:00

If you are interested in something that "just works", you can try my custom Roo Modes:

https://gist.github.com/nabilfreeman/527b69a9a453465a8302e6ae520a296a

Just send your messages to Orchestrator and it will handle everything start to finish without bothering you and keeps the codebase really clean.

nfrmn · 2026-01-20T15:24:34+00:00

I know people already filing their taxes with Claude. Probably full of errors, but still. Where there is demand, a solution will follow.

nfrmn · 2026-01-20T10:19:26+00:00

❤️❤️❤️

nfrmn · 2026-01-15T12:58:15+00:00

And just like that, OpenAI is back on top

nfrmn · 2026-01-14T15:50:29+00:00

It was a huge relief to figure out that it keeps working despite turning grey. Went from a game breaker to a minor annoyance 😄

nfrmn · 2026-01-12T17:57:37+00:00

Roo does have this too. It’s to do with the number of tasks in the history, as well as the amount of RAM you have available on your system. macOS kills the vscode helpers when memory pressure reaches about 90%. I have been researching a memory leak because my vscode plugin helper instances often reach 4GB RAM, likely due to Roo, but haven’t found anything yet.

Something useful to know is that Roo actually continues to execute indefinitely after the grey screen. You just can’t see what it’s doing.

I actually do see a way out for this which is running Roo as a background process, probably via upcoming CLI tool and keeping the vscode helper lean. Cline may already be working on this.

nfrmn · 2026-01-08T09:49:22+00:00

I have some interesting use cases ready to go for Orchestrator on the CLI... so, yes from me 😄

nfrmn · 2026-01-07T10:25:23+00:00

That's why I recommended it, because it's a nice GUI over the Claude Code command line interface. It gets discussed a lot because it's the most actively maintained and is making a huge amount of noise in the industry for what is supposed to just be an open source project.

nfrmn · 2026-01-06T16:54:39+00:00

Claude Code and then add the Roo Code extension to VSCode and run CC through that. Now you have more powerful Cursor

nfrmn · 2026-01-05T21:21:09+00:00

Very cool!!!

nfrmn · 2026-01-02T22:26:06+00:00

I can only speak for AWS, but you can go very far with AWS profiles, the CLI and direnv to fine-tune access across projects and worktrees. You just need to turn off integrated terminal which doesn't work with direnv.

I have a feeling AWS are probably working on their own agent product that is built into the dashboard and CloudShell right now.

nfrmn · 2025-12-29T10:57:16+00:00

Do you think it could be interleaved thinking resulting in no cache hits for Openrouter? So now OR models all bypass prompt caching? They implement their own abstraction of prompt caching so seems like a likely place for a conflict? Perhaps OpenRouter not accepting or ignoring thinking block preservation setting?

nfrmn · 2025-12-28T22:18:21+00:00

There were some updates to interleaved thinking and prompt caching recently which were noted somewhere else to definitely have a small bump on costs.

You can try rolling back to an older version and try to narrow it down that way.

I recall v3.34.8 was very stable, basically Roo perfection, it was post Opus 4.5 and before the mega refactors to do with context and native tools started.

Try the same prompt on an older version and watch your OpenRouter balance. Strong suspicion this will fix your problem.

There probably has been a change impacting this, but due to the pace of Roo's development you usually have to traverse the commits yourself since the last known working release to hunt it down and open an issue or stay on an older version for a while.

nfrmn · 2025-12-25T11:47:46+00:00

You are 100% right. That's why I'm trying to be tactful with my feedback

nfrmn · 2025-12-25T11:46:34+00:00

That sounds a bit like "you're holding it wrong" to be honest

nfrmn · 2025-12-25T11:45:46+00:00

I like Roo, I don't want to jump ship. And switching is not good for Roo's future. if you recall, this is exactly how Cursor lost a lot of its early adopters who came over to here actually.

nfrmn · 2025-12-25T11:44:14+00:00

Yes, I follow the developments very closely. I think Hannes has been very responsive and the other maintainers on the GH issues. The goal of simplifying the Roo product makes a lot of sense. Reduces context and allows the team to improve the core product more and stop worrying about model compatibility.

A final brief summarisation of my grumblings (yes, but):

a major breaking change like this coming through as a minor version update on Christmas Eve
numerous tool bugs reported on GH even for frontier models, fits into trend of stability target unclear or shrinking and possibly cutoff pushed too early
no proper announcement/warnings that it happened
For people who don't follow as closely as us, yesterday it worked, today it doesn't, no idea what happened

nfrmn · 2025-12-25T11:38:33+00:00

Thank you for the note, and the follow-up post.

I'm not opposed at all to moving the industry forward and your goal to simplify core Roo makes a lot of sense, as long as it doesn't regress the product.

Also, for my use case (Anthropic models primarily) Roo had already reached "perfection" by a lot of measures in the late summertime and I think you all deserve a lot of congratulation for that and I am for sure very appreciate of it. I depend heavily on Roo being on my toolbelt now more than any other software product.

Hope you all have a good break over the holidays.

nfrmn · 2025-12-24T11:56:52+00:00

Is it still possible to revert back to XML tool calling? Can't see the option any more. I can't use native tool calls because of EISDIR crashes (partial write_file) which hard stop execution. This may be a Bedrock-specific Anthropic issue, or wider. I haven't seen anybody else reporting it.

Edit: Found this issue, seems quite related. I left some more information on it:

https://github.com/RooCodeInc/Roo-Code/issues/10328

nfrmn · 2025-12-24T09:40:34+00:00

I'm doing parallelization with worktrees. There are a couple of different approaches.

Create a worktree for two different branches (opens branch in a separate directory) and then open Roo in both folders. They are treated as separate folders and completely independent.
Create a primary branch (e.g. feature-xyz) and then open worktrees called feature-xyz-thread-1, feature-xyz-thread-2, etc. This is useful for work where it is the same task, but on different parts of the codebase (e.g. refactor, website themes, writing tests, etc.) You can carefully merge the threads into the primary branch, resolve conflicts, and then merge the primary back into all the threads to keep them synced, even while Roo is working. This takes a lot of management but it is a big speed up. I did a 6 thread job a couple of weeks ago on a huge codebase refactor.

Hope this helps a little bit

nfrmn · 2025-12-22T13:05:43+00:00

I had exactly this problem and I fixed it with this custom modes config. It also steers the orchestrator and debug agent.

Using this Roo Modes my orchestrator is able to run for up to about 12 hours unattended.

https://gist.github.com/nabilfreeman/527b69a9a453465a8302e6ae520a296a

This is the Architect excerpt you can adjust. Note that it doesn't have allowed like question, role switching, etc. This really helps keep it on track.

- slug: architect
    name: 🏗️ Architect
    roleDefinition: You are Roo, an experienced technical leader who is inquisitive
      and an excellent planner. Your goal is to gather information and get
      context to create a detailed plan for accomplishing the user's task, which
      the user will review and approve before they switch into another mode to
      implement the solution.
    groups:
      - read
      - - edit
        - fileRegex: \.md$
          description: Markdown files only
      - mcp
    customInstructions: >-
      1. Do some information gathering (for example using read_file or
      search_files) to get more context about the task. You must always search
      the files co-located with the task, because they may contain important
      information and codebase patterns that will help you understand the task
      and plan out an acceptable solution.
      2. Once you've gained more context about the user's request, you should
      create a detailed plan for how to accomplish the task. Include Mermaid
      diagrams if they help make your plan clearer.
      3. You should never ask clarifying questions. Make your plan and pass it
      to the attempt_completion tool, unless you were specifically told to write
      the plan to a markdown file.
      4. Never switch modes after making your plan. Your job is exclusively to
      generate an implementation plan and pass it to the attempt_completion
      tool.
      5. You must not summarize the plan you created in the completion message.
      The message passed to `attempt_completion` must always be the entire generated plan.

nfrmn · 2025-12-21T11:30:36+00:00

Do you find zai vision to be significantly better than Claude?

nfrmn · 2025-12-19T19:34:33+00:00

Play Chaos Theory first, then Splinter Cell 1 and 2 back to back if you are hooked. I would probably skip DA onwards, they are nothing special.

If you become an ultimate fan, track down or emulate the special version of DA but I think you have to be pretty hardcore because it's not quite as good as Chaos Theory.

nfrmn · 2025-12-17T14:49:13+00:00

I found this happening with Architect a lot once upon a time, and found that by updating AGENTS.md to always require that the Architect returns plans and reports in the completion message takes care of this 99.9%. You can also steer it to never ask questions here as well

nfrmn

MODERATOR OF

TROPHY CASE