ReviewPhin

@Zain Sheikh I never tested it totally airgapped, but by default database is sqlite file, and model can be configured to point at self hosted api. As long as you can host your model, it has no reason to reach to the Internet (unless there is something in GitHub Copilot SDK/CLI that I don't know about). Just manage your expectations - unless you are able to host quite larger models on your own, results will be limited to the quality of what model can give you. There is some middle ground - run it in private network on azure (or any other cloud that gives you model hosting options) and configure it to work on models that azure hosts for you - e.g. gpt-5.6-terra on high. In such case you both have a smart model and your data stays in "your" network, just not on your machines.

Self-hosted agentic review with your own model choice is a great fit for teams that can't ship code to a SaaS. Can it run fully against a local model for air-gapped setups?

@Zain Sheikh There is a bit of prompt composition that makes sure ReviewPhin does not focus on small things and pays more attention to higher importance findings. But in the end that depends on model you chose to use. From using it, I can tell that both GPT-5.4 and GPT-5.5 work great with that, chosing mostly the things that are more impactful. Qwen-27b has tendency to focus more on smaller things, that are less important. And yes, it works with GitLab CE edition. It does not rely on any paid features, nor on GitLab Duo - it's simple webhook + clone + api calls combination on GL platform. I am using it on self-hosted GitLab CE right now and it works perfectly.

Bring-your-own-model plus self-hosting is the combo that makes agentic review viable for teams that cannot ship their diffs to a third party. How do you keep the reviewer agent from flooding a large MR with low-signal nits?

Pay per review rather than per seat is the detail that matters here, since review load spikes independently of headcount. Does the self-hosted deploy work against GitLab CE?

The "findings as native, bot-owned review comments you fully control" call is the right one. A separate SaaS dashboard for review output always turns into a second place nobody looks — keeping findings in the MR/PR thread, where the diff already lives, is what gets them acted on. Pay-per-review over per-seat also matches how bursty review load actually is rather than taxing headcount.

@Richard Anderson Optimization at the moment is mostly me trying stuff and playing with context. At the moment it relies only on model knowledge about given language which is perfectly fine if you use smarter models like gpt-5.5. They are still efficient enough to cover team of 5-10 devs with just one GH license (although mileage will vary depending on CR size, repo size etc). There is built-in command that summarizes all run metrics and storage table to record those from past runs. I could share some numbers with you, but tbh they span so wide range, I don't think it will give you much info. Right now I was focusing mostly on efficiency, features and correctness. I didn't have to touch token optimization yet, so I am sure once I do, there will be a lot to cut out. But so far my original strategy worked well: Get what you can programmatically from code review platform, pass that info to reviewer, give it basic tools to find details in code. You are able to specify different model profiles. Each profile has two models at the moment - reviewer and chatter. Context is gathered by platform provider which is not a model at the moment, but a json that gathers MR discussions etc. Beyond that, model has access to checked out branch and has tools to read into the code as it wishes during review. Each model profile can use different models, or different model hosting altogether. That depends on how you configure it. I am thinking on exposing more roles - router to start with to better discover if review is needed (sometimes general comment response, memory or web search will be enough). When it comes to tools per language there are two paths I am planning to explore, once I find time for it: 1. Give reviewer access to CI/CD pipeline summary and allow it to read logs, statuses etc. This will help it understand the state of the branch 2. Preinstal some tools for languages or extract job queue to dedicated workers - While both may be needed, I am simply not there yet. ReviewPhin is barely couple months old and mostly growing on my spare time, so the majority of my focus went into interacting with developers - review, summarize, respond to mentions etc.

@Zain Sheikh At the moment GitLab (including self-hosted) and GitHub are the only supported platforms. However, the server allows you to load custom platform provider as js module as long as it conforms to provider API I prepared. That API is still a bit messy, so until I clean it up, there will probably not be many platforms added. But tbh that depends mostly on how many people are interested in other platforms. If enough people ask e.g. for BitBucket, I'll take the time to model this connection as well.

@Thomas Jankowski I spent a lot of time tuning the prompt fragments for that, but in the end the signal to noise ratio depends highly on the models you've used. E.g. When I used qwen-27b for reviews (we have it in our company network), the findings were rather small things and most of them were accurate. I had to then use ReviewPhin memory to fine tune what is reported in given project. But when gpt-5.4 or 5.5 are used for review, findings are 99% accurate, larger scale issues that are missed and I had to finetune only few details. E.g. it detected that sqlite index was no longer needed after storage provider got different API. Or that one of the cli options, that was required is unnecessary, because in the end I refresh given data every webhook received. I ended up using gpt-5.4 for most of reviews and trusting them to highlight important stuff. And even then, I can respond to comments that are innacurate and either tell ReviewPhin to remember some misunderstood fact for future reference, or simply tell him to resolve given finding.

Self-hosted is the real unlock here — what kills SaaS code-review bots for most teams is that you can't ship proprietary diffs to someone else's endpoint, so it never clears security review. Running it where the code already lives sidesteps that entirely. The harder problem I'd be curious about is signal-to-noise: agentic reviewers tend to over-flag style nits and miss the one load-bearing logic bug, and trust erodes fast once people start skimming past it. How are you tuning what it stays silent on?

Pay-per-review instead of per-seat is a smart angle for teams with lots of occasional contributors. Which self-hosted git platforms beyond GitLab and GitHub are on the roadmap?

This is really interesting. What steps have you taken to ensure that agents are token efficient? Do you have any stats for token usage per language/LOC per discovered issue? Does the system have tools specific to certain programming language to increase efficiency and accuracy, or are you just relying on the LLMs ability to understand the provided code and context? Are you able to specify different models for the context-analyst + review-author roles in the code review?