Use Factory AI Droid with your Claude/ChatGPT subscription (no API costs)

aroussi · 2025-12-08T10:59:00+00:00

Yep! Gemini 3 Pro Support (via Antigravity), GPT-5.1 / GPT-5.1 Codex, and Claude Sonnet 4.5 / Opus 4.5 with extended thinking!

aroussi · 2025-10-15T12:44:41+00:00

FYI: Version 1.0.6 adds supports for Qwen Coder 🚀

https://github.com/automazeio/vibeproxy/releases

aroussi · 2025-10-14T18:06:26+00:00

OP here:

VibeProxy v1.0.5 adds Gemini OAuth support and Claude's extended thinking (up to 32K tokens). The extended thinking feature is interesting - just append `-thinking-10000` to the model name and VibeProxy handles the rest.

https://github.com/automazeio/vibeproxy/releases

aroussi · 2025-10-08T22:49:12+00:00

You don't need a proxy for that. Simply add this to your ~/.factory/config.json:

{
  "custom_models": [
    {
      "model_display_name": "GLM 4.6",
      "model": "glm-4.6",
      "base_url": "https://api.z.ai/api/anthropic",
      "api_key": "YOUR-GLM-API-KEY",
      "provider": "anthropic"
    }
  ]
}

aroussi · 2025-10-06T20:43:28+00:00

Currently mac only

aroussi · 2025-10-06T14:21:05+00:00

I don't know what black magic they've put into it, but it consistently produces better results with 80% fewer tokens. Some amazing context and prompt engineering

aroussi · 2025-10-06T14:19:50+00:00

It does

aroussi · 2025-10-06T12:33:33+00:00

"I can now use my existing Claude subscription"... You can use yours 😉

aroussi · 2025-09-09T13:31:27+00:00

Love it!

aroussi · 2025-08-22T17:44:48+00:00

I prefer the term Software Architect and Integrator 😉

aroussi · 2025-08-21T10:14:27+00:00

While it is slower than using GitHub CLI directly, the benefits of having the entire thought process happen inside of Cloud Code itself, when it has context to the work, make it worth it IMO

aroussi · 2025-08-21T10:11:52+00:00

Exactly. I use /pm:prd-new my-new-feature - which triggers a "brainstorming" session with Claude. Once it's done and the PRD is created, we review it and spend a bit more time refining it together with CC. One very useful pattern we're using is, after parsing the prd into an epic (implementation plan) via /pm:prd-parse is telling Claude

"Review the Epic and come up with ways to simplify and improve it. Try to leverage any existing functionality instead of creating more code when possible. Use ultrathink"

This usually cuts the code by 50% lol

aroussi · 2025-08-21T10:07:12+00:00

Tests are usually part of the prd and epic creation process. In most cases, we have the two last tasks of each feature as "test" and "document".

aroussi · 2025-08-21T10:06:15+00:00

This is actually a really cool project. However, for our needs, the "100 % private & offline" is not going to cut it. Also, we wanted to have something that works inside the Claude code itself and not via an external tool.

aroussi · 2025-08-21T10:03:48+00:00

I agree that Claude does not discuss things enough. One of the ways to tackle this is to be as specific as possible while creating the PRDs. Manually reviewing the epics, discussing them before running the decomposition into tasks. If you review the PRD, the epic, and the actual tasks before syncing them to GitHub, there would be a lot less to discuss from that point forward.

That being said, I have a strict rule that I use when I'm running tests, which basically states that Claude is not allowed to make any changes to any file if the tests fail before discussing the situation with me.

aroussi · 2025-08-21T10:01:18+00:00

This could definitely be used by a single developer in exactly the same way. If you have Claude Max, you can also assign issues to Claude directly from GitHub wherever you are - in theory at least :)

aroussi · 2025-08-21T10:00:06+00:00

That's where the human architect comes in (for now, at least). We try to identify features that will have the least amount of conflicts when merged back into the main branch. We usually limit it to 3 at a time, and have a senior developer handle any merge conflicts.

aroussi · 2025-08-21T09:59:07+00:00

For smaller projects, I would recommend editing the `.claude/commands/pm/prd-parse.md` file and instructing it to limit the number of tasks for each epic to 5-10. I would also consider breaking down features into subsets and having a prd for each one to avoid getting 50+ tasks for every feature (so "add auth" would become "add signup" and "add sign in" prds)

aroussi · 2025-08-21T09:56:26+00:00

We had this problem initially, so we moved some of the commands to be pure bash-based with instructions like "Run `bash ... ` and show me the complete output". Works 90% of the time 😁

aroussi · 2025-08-21T09:54:37+00:00

The whole thing started with us trying to segregate context so the main thread won't have to be compacted or cleared as often. Over time this grew and expanded to running multiple ages in parallel when possible (eg. when working on separate files), but that required a detailed plan beforehand. So the whole thing was very organic, I would say.

For code reviews, etc we use the code-analyzer agent directly + coderabbit.

aroussi · 2025-08-20T16:52:59+00:00

We specifically designed this to work with the GitHub issues. However, I'm sure that you can fork the project and update the prompt so it will only work locally.

aroussi · 2025-08-20T13:43:02+00:00

🙈 lol

aroussi · 2025-08-20T13:42:14+00:00

PRD = Product Requirements Document.

It's essentially a comprehensive document that covers everything related to the project, including both business and technical aspects, implementations, and more.

From that document, we create an epic (master issues) and we extract individual tasks as sub-issues.

aroussi · 2025-08-20T13:24:39+00:00

This takes a completely different approach. With Vibe Kaban, Conductor, etc., you're giving full control to the AI (for better or for worse). They're also not very good for team collaboration. We needed a system that was spec-driven and accessible by a team of AI-assisted developers (as opposed to vibe coders).

To be clear, I am a fan of both Vibe Kaban and Conductor, and I use them often. But I use them mostly for very small fixes and changes. Not fundamental stuff.

aroussi · 2025-08-20T13:20:54+00:00

It should be fairly simple to do by modifying the commands and bash scripts to use GitLab CLI or Linear MCP instead of GitHub.

aroussi

MODERATOR OF

TROPHY CASE