# sunnypilot: an openpilot fork where the settings are the product > comma.ai's openpilot steers the car; sunnypilot keeps the same safety policy and changes what the driver can adjust. That means the fork's substance lives in a settings UI and a release cadence, not in the driving model. **sunnypilot/sunnypilot** — sunnypilot is an open source driver assistance system. sunnypilot offers the user a unique driving experience for over 350 supported car makes and models with modified behaviors of driving assist engagements. sunnypilot complies with the safety policy from comma.ai's openpilot as accurately as possible. - Repository: https://github.com/sunnypilot/sunnypilot - Website: https://www.sunnypilot.ai - Stars: 2,135 · Forks: 1,589 - Language: Python - License: MIT - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/sunnypilot-sunnypilot ## A fork that changes behaviour, not safety sunnypilot is a fork of comma.ai's openpilot, and both projects describe the result in careful language. openpilot is a driver assistance system, not autonomy. sunnypilot is described as offering a unique driving experience across supported cars with modified behaviors of driving assist engagements, and states that it complies with comma's safety policy as accurately as possible. That safety clause is the load-bearing sentence. Everything the fork does is framed as changing how the assistance feels and behaves while keeping the constraints that determine when the car disengages. Reading it as a tuning layer rather than a safety layer explains the whole shape of the project: there are no new models to train, no new perception stack to validate, and no claim about capability. What there is, is a large surface of user-facing settings and a great deal of work making those settings behave predictably across very different cars. The car list is where the fork's practical scope lives. The topic tags name twenty brands: Acura, Audi, Chrysler, Ford-era Hyundai and Kia, Genesis, Honda, Jeep, Lexus, Mazda, Nissan, Ram, Tesla, Toyota and Volkswagen among them, with FSD and comma as topical references. Supporting twenty brands means supporting quite different hardware: different cameras, different steering torque interfaces, different body controllers, and upstream behaviour that does not always stay put. Two numbers are quoted in the project's own metadata and they do not match. The repository description says over 350 supported car makes and models. The README body says over 300+. Same project, same claim, two counts, and neither is verifiable from the repository itself since the authoritative list lives on the community forum. Treat the count as marketing and the forum list as the fact. One more small inconsistency worth noting because it affects where you look for things: the README's own link points at the sunnyhaibin/sunnypilot path rather than the sunnypilot/sunnypilot path where the repository now lives. Documentation written early in a project's life tends to keep old URLs. ## What the release notes reveal about the actual work The release history is the most informative document in the repository, because a fork's identity lives in its diff against upstream. Three releases in mid-2026 are enough to show the pattern. The 2026.002.002 release, dated 2026-08-06, contains two changes: a fix so mapd is ignored in the plannerd health check, and work in plannerd and selfdriveStateSP to poll modelV2 and relay button state through a bitmask. Neither is a driving improvement. The first stops a health check from reporting a problem that does not exist. The second is plumbing between processes that tells the system which model is loaded and which buttons are pressed. The 2026.002.001 release, dated 2026-06-28, is a single change and it lives in a different repository, sunnypilot/opendbc: safety ignores the frequency check for Toyota UNSUPPORTED_DSU cars. This is the clearest single illustration of what fork maintenance involves. Upstream openpilot added a frequency safety check that does not apply to a particular class of Toyota, and the fork's job was to scope it out without weakening the check for everyone else. That is a small, specific, unglamorous change, and it is the kind of change that appears several times a month in a project tracking twenty car brands. The 2026.002.000 release, dated the same day, is longer and reads like a maintenance sweep. It updates UI gates for certain toggles, which means controlling which settings appear under which conditions. It disables a DEVELOPMENT_ONLY reset in the manager. It fixes maximum time offroad values in sunnylink and adds a CarParams fallback for brand-specific capabilities. It surfaces the default model name in the UI. It adds safe model validation in modeld_v2. It reverts a Lancia Delta Integrale model and reverts a deprecation of carState.brake for a Honda Gas Interceptor. Read that list as a description of the product. Offroad time limits are safety-adjacent settings that need per-brand values. Model validation is a guard against loading something the system cannot drive with. Toggles that appear conditionally are the visible face of a large settings matrix. Two reverts in a single release, one for a car model and one for a specific Honda variant, show how many brand-specific exceptions accumulate. The version scheme is also worth reading. These are date-based release numbers, 2026.002.002 meaning the second release of February 2026, so the cadence is roughly monthly rather than per-feature. ## Data terms: the part to read twice The README's user data section is unusually explicit, and it deserves a careful reading rather than a skim. By default, sunnypilot uploads driving data to comma servers, and users can access that data through comma connect. The data collected is listed precisely: the road-facing camera, CAN bus, GPS, IMU, magnetometer, thermal sensors, crash data, and operating system logs. The driver-facing camera and the microphone are logged only on explicit opt-in through settings. That split is the meaningful design choice here. The road-facing camera and CAN data are what the system needs to drive and to debug itself. The driver-facing camera and microphone are not, so they are gated behind opt-in. Users can also disable data collection entirely, since the project is open source software. The legal sentence that follows is the one to read slowly. Using the software or its related services generates user data which may be logged and stored at the sole discretion of comma, and by accepting the agreement the user grants comma an irrevocable, perpetual, worldwide right to use that data. Irrevocable and perpetual are doing real work in that sentence, and they sit in tension with the sentence right before it about being free to disable collection. The way to read both is that disabling collection stops new data from being sent rather than releasing what has already been sent, but the README does not say so explicitly and it is worth asking on the forum if the distinction matters to you. The licensing section is equally frank about lineage. sunnypilot is MIT, and the repository states it includes original work along with significant portions derived from openpilot, which is MIT with additional disclaimers. The original openpilot notice is reproduced in full, including comma's indemnification clause covering its directors, officers, employees, agents, stockholders, affiliates, subcontractors and customers, and the alpha quality notice stating that this is research software and not a product, that the user is responsible for complying with local laws and regulations, and that there is no warranty expressed or implied. Two license files exist in the tree, LICENSE and LICENSE.md, alongside a SECURITY.md and a CHANGELOG.md and a RELEASES.md. That disclaimer is not boilerplate to skim past. A system that steers a car, running on hardware you installed yourself, with a stated compliance responsibility on the user, is a different proposition from a self-driving product with a manufacturer behind it. ## Installing: the fork's handoff to documentation The README is short on installation instructions, and that is a deliberate handoff rather than an omission. Three destinations cover everything: a getting-started checklist for the hardware you need to run sunnypilot in a car, a read-before-installing post for the procedure itself, and a recommended branch installations page. That third link carries more weight than it appears to. sunnypilot uses branches, and the recommended list tells you which branch to install for a given car or situation. This is the mechanism by which a single codebase supports twenty brands: a stable branch for most cars, and specific branches for the ones that need something different. The 2026.002.000 release mentions ignoring upstream's IsReleaseBranch, which means branch selection is actively managed rather than incidental. For contributors, the README asks for pull requests against the most current master branch, and says bug fixes are encouraged. The preference for bug fixes over features is a reasonable signal about where a maintainer wants help on a safety-adjacent codebase. The repository structure explains the rest. Beyond the usual openpilot layout, the tree contains several git submodule pointers, each with its own repository variable: msgq_repo, opendbc_repo, rednose_repo, teleoprtc_repo, and tinygrad_repo. opendbc is the CAN bus database, which is exactly what a twenty-brand fork needs to carry, and the fact that it is a separate repository under the sunnypilot organisation explains the 2026.002.001 release landing its safety fix there rather than in the main tree. There is also a panda directory for the hardware that interfaces with the car, a release directory, a system directory, and a Jenkinsfile alongside the GitHub workflows. The Python configuration in the tree is inherited from openpilot and still carries its identity, which is worth noting when you read it. The project name in pyproject.toml is openpilot rather than sunnypilot, the description is an open source driver assistance system, the author entry credits comma.ai, and the version reads 0.1.0 even though releases are date-numbered. Nothing is broken by this; it just means the fork does not rename its upstream, so any file you inspect will identify itself as openpilot. Dependency pinning here is unusually conservative, and the comments explain why. The list carries pinned versions with reasons attached: scons is held at 4.10.1 because a later version removed a Qt3 tool still used to build Cabana, and pycapnp is held at 2.1.0 because a later version introduces a memory leak through cyclic references. Several packages are marked as candidates for removal, including zstandard with a note that it can go once the project is on Python 3.14. The Python floor is 3.12.3 with a ceiling below 3.13, a narrow range that reflects real compatibility constraints rather than caution. ## Conclusion sunnypilot's contribution is best understood as an interface decision rather than a driving one. The fork keeps openpilot's safety policy and changes what the driver is allowed to configure, which moves the work from the model into the settings, the branches and the release notes. Read the release notes and you can see exactly where the effort goes: brand-specific capability fallbacks, safe model validation, gate rules for which toggles appear when, a default model name surfaced in the UI, and a fix for maximum-time-offroad values. None of that is self-driving research and all of it is what makes a shared codebase usable across twenty car brands with different hardware and different upstream behaviour. Three things to settle before installing. The support count is quoted two ways in the project's own metadata, 300-plus in the README against 350-plus in the repository description, so verify your exact car and model against the supported list rather than the headline. The data terms are the part worth reading twice: driving data uploads to comma servers by default, the driver-facing camera and microphone only with explicit opt-in, and accepting the agreement grants comma an irrevocable perpetual worldwide right to the data you generate. And the upstream disclaimer reproduced in the README still applies, including the alpha software notice and the compliance responsibility. Branch choice is the fourth, and the community forum rather than the repository is where that decision gets documented. ## FAQ ### What is Sunnypilot? sunnypilot is an MIT-licensed fork of comma.ai's openpilot, an open source driver assistance system. The fork modifies the behaviors of driving assist engagements while stating that it complies with comma's safety policy as accurately as possible. It is not a self-driving product: the upstream notice reproduced in the README describes it as alpha quality software for research purposes only and not a product. ### What are the main differences between Frogpilot and Sunnypilot? The README does not mention Frogpilot, so a line-by-line comparison has to come from elsewhere. What this repository does support: sunnypilot is a fork of comma.ai's openpilot that keeps the upstream safety policy while changing user-facing driving behavior, ships date-numbered monthly releases such as 2026.002.002, and maintains its own CAN database in a separate sunnypilot/opendbc repository. Both projects are forks of openpilot, so the meaningful comparison is which settings each exposes and how each tracks upstream changes. ### Which cars are compatible with Sunnypilot? The repository quotes the supported count two ways: over 350 makes and models in the repository description and over 300+ in the README body, so the headline number is not authoritative. The topic tags name twenty brands including Toyota, Honda, Lexus, Nissan, Mazda, Hyundai, Kia, Genesis, Audi, Volkswagen, Jeep, Ram, Chrysler, Acura and Tesla. The README defers to the community forum for the getting-started checklist and the recommended branch installations list, which is where the exact car, model and year combinations are documented. ### How to use Sunnypilot? The README points to documentation at docs.sunnypilot.ai and to the community forum rather than giving inline steps. The documented path is three links: a getting-started list of the hardware needed to run sunnypilot in a supported car, a read-before-installing post for the procedure, and a recommended branch installations page listing which branch to install for a given car. Branch choice matters because the project uses separate branches to support cars with different hardware and different upstream behavior. ## Sources - [License: MIT](https://github.com/sunnypilot/sunnypilot/blob/master/LICENSE) - [Project website](https://www.sunnypilot.ai) - [README](https://github.com/sunnypilot/sunnypilot/blob/master/README.md) - [Releases](https://github.com/sunnypilot/sunnypilot/releases) - [sunnypilot/sunnypilot on GitHub](https://github.com/sunnypilot/sunnypilot) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sunnypilot-sunnypilot