Sona: a League of Legends client plugin built on the Pengu loader

What Sona is

Sona is a League of Legends client enhancement plugin built on the Pengu loader, described as usable on all servers, and the project presents it as a client assistant with a panel you bring up with a key.

The mechanism is a loader, not a patch. The Pengu loader injects the plugin into the running client, and the plugin itself is a TypeScript and React application that talks to the client's own interface, the LCU API, and to external data sources.

The feature list in the readme is organised into groups, and the first group is the largest, the in-match enhancements. There is automatic match acceptance with a configurable random delay. There is instant pick and automatic ban with a configurable candidate list ordered by priority, skipping champions that are unavailable, and a choice between locking in or only preselecting. There is removing the swap cooldown in the game mode where the champion pool is shared. There is a side indicator that tells the team chat which side you are on during champion select. There is a teammate analysis feature that queries recent games and computes a win rate, a KDA and a composite score on a scale from 3.0 to 16.0, and sends the results ranked within the team.

The rest of that group is cosmetic and informational, particle effects on teammate portraits by win rate, OP.GG tier badges on the champion grid, a global power analysis popup, a quick exit button during champion select, automatic return to the lobby after a game, balance change hints on hovering a champion, an automatic like to teammates at the end of a match, and clickable member portraits in the party screen.

So the plugin is best understood as a front end for data, and a set of automations on top of the client's own screens.

The rest of the feature surface

Six more groups follow the match enhancements, and it is worth naming what each one is for.

The smart itemization group configures runes and summoner spells automatically, remembering per champion and per mode what you saved manually. It writes OP.GG recommended item sets into the client, and the project says plainly that this is not recommended and may cause the item set to be wrong, which is an unusually honest warning to find in a feature list. It suggests a lane, using the assigned position in ranked and the most common lane for a champion otherwise, and it shows matchup advantages and disadvantages in the recommendation panel. Where the recommended data is missing for a mode, it falls back to whatever data is available.

The match history group takes a summoner name with a tag and pulls roughly the last hundred games, with a filter by mode using the SGP interface to filter by queue. Each game shows champion, KDA, items, runes, summoner spells, last hits, gold and damage, and a button copies the game identifier for use with the replay feature.

The social group is the most unusual, and it is entirely about the parts of the interface the official client restricts. It removes the restriction on editing your own signature, adds online states including appearing offline, lets you pick a career background from every skin rather than only the ones you own, and does the same for challenge banners. It marks friends in the same game with the same colour, shows the mode and the current game length for friends in game, and can disguise the rank shown in the friends list, with a one click restore of the real rank. There is also a button to remove the frame around your avatar and one to restore the default avatar.

The beautification group covers a new section in the sidebar for the visual options, custom homepage wallpaper from your own image or video files, adjustable blur and framing, random wallpapers applied at start, a blurred friends bar, a customisable top navigation, multiple avatars with switching, a gradient animated summoner name, and an asset manager that accepts relative paths.

The tools group includes replay viewing from a game identifier, settings backup and restore with named slots, selective claiming of pass rewards, window effects such as frosted glass, acrylic and the Windows 11 mica, a global particle background, a version check at start with release notes, and a developer panel exposing the LCU API for chat, replays, item sets and match analysis simulation.

The interface layer and the self-healing problem

The last group is the interface, and it contains the detail that tells you how this kind of plugin actually works.

There is a launcher entry next to the client's Play button, a hotkey that brings the panel up and closes it, configurable across a range of function keys. There is a quick lobby mode that skips the mode selection and goes straight to a preset queue, queue filtering in the player versus page, and an interface slimming option that hides several parts of the home screen. There is a tab to restore a page the official client hid, a multi-language interface offering Simplified Chinese, English and following the client language automatically.

And then there is DOM self-healing. The description says that after the client refreshes its DOM with Ember.js, all the injected features are put back automatically.

That is the load-bearing engineering in the whole plugin, and it explains the architecture. The League client is a single page application built on Ember.js, and it rebuilds large parts of its own DOM when you navigate between screens. Any injected feature is therefore attached to a node that the framework may destroy and recreate at any moment. A naive plugin works until the user opens a menu, and then silently stops working.

So the plugin has to detect that its injections have gone and reapply them. That is a maintenance tax of running inside somebody else's front end, and the fact that the project handles it automatically rather than telling users to restart the client is the difference between a tool people keep and one they uninstall.

The build, and the unusual parts of the stack

The package manifest is small and it explains how the plugin is put together.

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
    "update-balance": "tsx scripts/update-champion-balance.ts"
  },
  "dependencies": {
    "react": "^19.1.0",
    "react-dom": "^19.1.0"
  },

The runtime dependencies are React and React DOM, which tells you the panel is a React application rendered into the client, and nothing else. The build is the TypeScript compiler followed by a Vite build, and there is a script that updates the champion balance data, which is how the balance change hints stay current.

Two development dependencies are more revealing than the rest. The luaparse library, with its type definitions, is there because the League client interface is described in Lua, so the plugin parses it. And the Vite plugin for mkcert is there because a plugin that talks to the client over a secure connection needs a local certificate authority, which is the sort of detail that a project discovers the hard way.

The rest of the tooling is the modern default, with Vite 6, TypeScript 5.8, the React plugin for Vite, tsx for running the TypeScript scripts, and undici for the HTTP calls the data features make.

The repository layout matches that. There is an index.js and an index.css at the root as the entry points the loader loads, a src directory with the source, an assets directory for the images and videos the customisation features use, a markdown directory for the documentation and the example screenshots, a scripts directory, a type definition for the Pengu loader API, and a manifest for the loader in a YAML file, plus the changelog, the English readme and the licence.

The licence, the releases and the community

The project is licensed AGPL-3.0, and the releases are frequent. The three most recent listed are 1.9.0 from 2026-08-28, 1.8.0 from 2026-08-03 and 1.7.0 from 2026-07-22, and the last push to the repository was on 2026-10-11.

That cadence is the interesting part, because it is a client plugin against a service that changes. A plugin that hooks the interface of a live application has to be updated when the application changes, and a monthly release cycle says the author is doing that work.

The readme is structured for a Chinese audience, with a simplified Chinese version and an English one linked, and the table of contents covers the introduction, the features, the screenshots, installation, usage, the technical architecture, the project structure, the notes, the community group, a to-do list, the licence and the acknowledgements. The final section is an important notice, and the presence of a to-do list and a set of notes is a sign of a project that expects the client to move underneath it.

The community is a chat group, and the screenshots in the readme are organised by feature group rather than as a single gallery, which is the presentation a project uses when the features are the selling point.

There is also a plugin panel sample image at the top of the introduction, showing the entry point next to the Play button, and the project links a video.

The honest summary is that this is a large, well-maintained client modification whose value is entirely in the data and the automations, and whose cost is that you are running a third party injection into a game client that could change at any time.

Editorial conclusion

Adopt Sona if you want the client to do more for you during champion select and outside it, because the plugin covers match acceptance, item recommendations, history lookup and a large set of visual customisations from one panel. Do not adopt it if you need the client untouched, since every feature is a modification of a game client you do not control. Before you install, read the notices section of the readme and the to-do list, and be aware that the plugin depends on the client continuing to expose the interface it hooks into, which is why the project includes a self-healing mechanism for the interface being rebuilt.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. WJZ-P/sona on GitHub