While most AI coding tools default to cloud-hosted models, local model runtimes have become a viable alternative for developers who want to keep code on their own machines, avoid per-request API costs, or have to work without an internet connection.

Tools such as Cline, Continue, and Aider can already be pointed at runtimes like Ollama or LM Studio. At the same time, GitHub added local-model support to Copilot CLI in April, including an offline mode for fully air-gapped setups.

The catch is that “local” generally still leaves much of the assembly to the developer. You have to choose a model and a suitable quantization for your hardware, configure the runtime and context settings, and work out which combination performs well with the agent.

And that last part really does matter: models small enough to run comfortably on a laptop can still struggle with the tool use, reasoning, and longer-running tasks that coding agents demand.

This is why JetBrains has now built Junie Local, a free version of its coding agent designed to run entirely on the developer’s own machine.

Local market

By way of a brief recap, JetBrains — the developer tools company behind IntelliJ IDEA, PyCharm and WebStorm — launched Junie in January 2025 as an AI coding agent embedded in its IDEs, capable of planning tasks, modifying code, running tests and inspections, and working with the context of a developer’s project. It has since expanded into a standalone CLI.

Junie itself isn’t exactly new to local models. In a blog post published on Monday, JetBrains’ head of marketing Dmitry Savelev notes that developers have been able to connect the agent to runtimes such as Ollama and LM Studio for some time, load whichever model they want, and have Junie run against it locally.

However, with Junie Local, JetBrains has picked the model, quantized it, and tuned its inference engine and agent harness around that specific combination. Setup is handled from inside Junie itself: running /local downloads the model and inference engine, starts a local server, and switches the agent over automatically. There is no separate Ollama or LM Studio installation, endpoint to configure, or model profile to write.

The first step is simply choosing Junie Local from the model selector, where it appears alongside the usual array of cloud-hosted models.

Once the download and setup are complete, Junie switches to the local Qwen model, which then appears in the CLI like any other model option.

From that point on, inference happens entirely on the developer’s machine.

Under the hood: Why Qwen3.6 — and why an M5 Mac

It’s worth noting that JetBrains has been very specific about its model choice and hasn’t opted for the latest, shiniest open-weight version. Junie Local uses Qwen3.6-27B, a 27-billion-parameter open-weight model released in April, even though the newer Qwen3.8-27B arrived earlier in August with improvements.

“On today’s Macs, [Qwen] 3.6 wins.”

Savelev notes that the choice came down to how the two models behaved inside Junie on current Macs, with Qwen3.8 requiring its reasoning mode to be enabled to work reliably with the agent; with reasoning switched on, tasks took roughly four times longer. For Junie Local right now, Qwen 3.6 offers the better balance of reliability and speed.

“On today’s Macs, 3.6 wins,” Savelev writes.

JetBrains runs Qwen3.6-27B at 4-bit using an inference engine based on mlx-vlm, which in turn uses MLX, Apple’s machine-learning framework for Apple Silicon. It’s a similar underlying approach to the one Ollama adopted in March, when it moved its Apple Silicon engine onto MLX to take advantage of the chips’ unified-memory architecture.

There is a fairly substantial hardware floor, though: JetBrains confirms that Junie Local involves about 20 GB of downloads, and requires macOS 26, at least 64 GB of unified memory, and an Apple M5 chip or newer. In real terms, that 64 GB requirement puts MacBook Pro users into M5 Pro or M5 Max territory — in other words, this is firmly a high-end Mac proposition.

JetBrains acknowledges that those requirements will put Junie Local beyond the reach of plenty of developers who might otherwise be interested in running it.

“We know that an M5 Mac with 64 GB of RAM is a big ask,” Savelev writes. “We are not going to pretend otherwise. That is simply what it costs to run a 27B model well today, and it is the number we are working hardest to bring down.”

“We know that an M5 Mac with 64 GB of RAM is a big ask. We are not going to pretend otherwise.”

The intention is to reduce memory requirements, support a wider range of hardware, and continue optimizing the underlying stack.

“If the lofty requirements are the reason you cannot try Junie Local, rest assured that we are working to bring them down,” Savelev adds.

Where local pays off

Ultimately, the hardware requirement is closely tied to where JetBrains identifies the real performance bottleneck for a local coding agent. The tokens-per-second metric measures how quickly a model generates output, but an agent can spend much of its time first ingesting source files, prompts and other context — the prefill stage — before it starts producing an answer.

“Everyone benchmarks generation speed,” Savelev writes. “For a coding agent, that turns out to be the wrong number to chase because most of the time is spent on prefill, while the model reads files to work out what is going on. Optimizing for prefill is where the real gains were.”

Being free and unmetered also changes the kinds of jobs developers might be willing to hand over. JetBrains positions Junie Local as particularly well-suited to long, repetitive, and mechanical work — multi-file refactors and renames, filling test-coverage gaps, dependency upgrades, and framework migrations — where the agent can keep working and iterating without the developer having to think about how many tokens it’s burning through.

“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance,” Savelev writes.

“Long, repetitive, mechanical work is exactly what an agent is for, and exactly what you stop asking for when you are keeping an eye on your balance.”

For everyday development work, Savelev reckons users are unlikely to notice much of a gap compared with stronger cloud models. However, he does concede that more complex architectural reasoning remains better suited to those models.

And then, of course, there is arguably the biggest reason developers have been interested in local models in the first place: privacy. Running the entire agent locally means that no external model provider sits between the developer and their code, and that no source, prompts, or generated changes need to leave the machine. For developers working on proprietary code, under client NDAs, or in environments where sending source to a third party is simply off the table, that is a substantial part of the appeal.

“Everything after the download happens on your hardware, so your prompts, source, and diffs stay put,” Savelev writes.

The post JetBrains’ Junie now runs entirely offline. Can you spare a 64 GB M5 Mac? appeared first on The New Stack.

At WordCamp US last week, we unveiled a completely reimagined WordPress Studio desktop app, rebuilt from the ground up around Studio Code, our AI WordPress expert. 

With this new Studio desktop experience, you can describe what you want to the expert WordPress agent, watch it come together in a live preview, point at anything that’s off, and ship it to production when it’s ready, all in one window.

You’re left with a full WordPress build you own and can maintain, not throwaway code.

Today, it’s available in beta for everyone to try.

How to access the beta and what to expect

You can try this new desktop UI in just four steps:

1. Download the WordPress Studio desktop app on macOS, Windows, or Linux
2. Sign in with your WordPress.com account
3. Enable the New Studio Experience option under Studio → Beta Features
4. Add a payment method on file to verify you’re a real account (you won’t be charged)

And if you’re a brand-new Studio user — welcome! You’ll see the new agentic UI as default, so there’s no need to opt into the beta.

The Studio interface has been reimagined to focus on agentic development, with three panels next to each other in a single window:

• Your Sites on the left
• A chat with Studio Code in the middle
• A live preview of your site on the right

Switch on the new UI without losing a thing

If you’re an existing Studio user, you won’t lose your current sites when you switch the new experience on; every local site from the old experience carries over automatically. Nothing to migrate, re-import, or rebuild.

Pick a site to jump back into it, start or stop it, or open its settings.

Chat with Studio Code to make it happen

The agent in the middle panel is Studio Code, our coding agent built for WordPress that knows blocks, themes, and WP-CLI natively.

In fact, this is what WordPress developer Olivier Gobet said about his experience building with Studio Code:

I’ve been building WordPress sites for almost 20 years, and Studio Code has genuinely changed the way I work. For the first time in a long while, I feel like I’m no longer limited by the technical barriers of implementation. Instead of asking myself, Is this possible?, I can focus on, What do I want to build?

You describe what you want in plain language, and Studio Code builds it on a real local WordPress install where you can build, vibe, and experiment. Chat history is stored so you can easily stop and restart a work in progress, and you can always spin up a new chat for each site when you want to start fresh:

If you want to give Studio Code standing instructions it follows on every task, set them under Settings → AI.

That same screen is where you can also toggle agentic features off entirely if you’d rather build WordPress the classic way.

Watch it build in real time

Changes render live in the in-app preview as Studio Code works. You see the site take shape with every ask, so there’s no switching between browser and UI to check whether an edit landed.

It’s a working preview of your local site, too: click any link to move to other pages, just as a visitor would, and watch them update as Studio Code makes changes. You can even access the admin dashboard to manage posts, pages, products, and everything else you’re used to.

One of your favorite tools is still available, too, just in a different spot. Use the Annotate button to send specific, targeted requests to Studio Code.

Click the elements you want changed, stack up your notes, submit them with one click, and Studio Code makes every edit in one pass. It’s the client-feedback loop, built into the tool, and it’s a natural fit for your workflow of reviewing, marking up, and revising a site fast.

Build locally, ship when you’re ready

The core functionality of Studio remains too: you’re able to spin up a real, local WordPress site in seconds by clicking the + button in the toolbar.

Because everything you build happens locally, you can try things, break things, and start over with zero risk to a live site. Nothing goes live until you say so.

When it’s ready, you ship to fast, managed hosting on a paid WordPress.com or Pressable plan in a few clicks with Studio Sync.

What you build in Studio is real WordPress: portable, dependable and yours to maintain.

Meet the new WordPress Studio

Give the new Studio desktop beta a real workout. Point it at an actual project, a brief, some images, a vibe, and see how far it gets, where it shines, and where it falls short.

During this beta period, you’ll get a one-time credit gift from us to try it out. Once you hit your limit, top-ups are available for just $10.

And we want to know how it goes. Open a GitHub issue with your feedback, bug reports, and ideas. Your input shapes what comes next.

You can now manage your WordPress.com site from ChatGPT using the new WordPress.com ChatGPT plugin.

Set it up once, then talk to your site to publish posts, moderate comments, check traffic, update media, and handle the small jobs that start after the writing ends.

After you add the plugin, type @WordPress.com in any chat and hand off those chores to ChatGPT.

Publish your words without the busywork

You wrote the post, maybe in your notes app, maybe in a doc, maybe in a voice note. Getting it live on your blog can be time-consuming, but with the ChatGPT plugin, you just need to ask. 

Try running some of these prompts directly in ChatGPT:

• @WordPress.com here’s my draft. Can you clean up the formatting and make a draft for me on my site?
• @WordPress.com schedule my recent draft to go out on Monday.
• @WordPress.com can you add a featured image of a hand holding a pencil in the style of a black and white editorial vintage illustration with visible stipple and crosshatch texture.
• @WordPress.com review my draft and suggest links to related posts already on my blog. 

Your content stays yours, and ChatGPT helps with the formatting, scheduling, and the clicking around. 

Run your site by asking

Once connected, ChatGPT can read your stats, your comments, your media library, and your site’s activity log, so questions about your site get answered where you asked them.

Here are a few prompts you can use:

• @WordPress.com how did my traffic this month compare to last month?
• @WordPress.com show me the comments actually worth replying to, and clear out the spam
• @WordPress.com find images missing alt text and help me update them
• @WordPress.com what changed on my site in the last two weeks?
• @WordPress.com trash any post that’s been sitting in draft for over a year

Alt text deserves a special mention here. It’s the accessibility task everyone means to do and almost nobody does, because doing it means setting the alt text one image at a time.

Now you can set alt text through a conversation with ChatGPT, and your readers who use screen readers get a better experience for it.

Change your site, conversationally

The plugin can make changes across your site, from adding pages and updating site settings to working with your existing design.

Try prompts like:

• @WordPress.com add a page for my workshop schedule, I attached a draft here.
• @WordPress.com my site is still in coming soon mode. Can you make it public?

You stay in control

The WordPress.com ChatGPT plugin is optional and off by default. When it’s enabled, ChatGPT has to ask you before making changes to your site.

If it’s about to publish or edit content, launch your site, change settings, or delete something, you’ll see what it plans to do before anything changes.

New posts and pages start as drafts by default, and for anything that publishes, edits, launches, or trashes something, ChatGPT describes exactly what it’s about to do and waits for your confirmation. 

Connect your site to ChatGPT

Getting started only takes a few steps and after that, WordPress.com is available whenever you type @WordPress.com in ChatGPT.

First, you’ll need to enable MCP access on your WordPress.com account. This enables AI agents like ChatGPT to use the WordPress.com tools you choose to enable.

Then, open WordPress.com in ChatGPT, select “Install plugin,” sign in with your WordPress.com account, and approve the connection. Then type @WordPress.com and hand off the first chore.

The full setup guide is in our support docs, and if you’d rather connect Claude or another AI assistant, that works too.

MCP access is included with every paid WordPress.com plan, and Free sites also get this during the first 30 days after creation.

Your writing stays yours, and now you can work with your site without having to go to it. Writing was always the fun part anyway.

If you want to hold costs down, efficient resource management is paramount. One of the critical resources in AI applications is token usage. Tokens are the basic units of text that models process, and managing them effectively can lead to significant cost savings and improved performance. This post explores various techniques for measuring and minimizing token usage within the Microsoft Agent Framework.

Understanding Token Usage

Before diving into the techniques, it’s essential to understand what token usage entails. In the context of AI models, a token can represent a word, part of a word, or even punctuation. Each interaction with the model consumes tokens, both for the input provided and the output generated. Therefore, optimizing token usage is crucial for maintaining efficiency and controlling costs, especially in applications with high interaction volumes, such as chatbots and multi-agent systems.

Key Techniques for Minimizing Token Usage

1. Token Management

One of the most straightforward methods to control token usage is through effective token management. By setting a maximum number of tokens for responses, developers can prevent excessive consumption and ensure that outputs remain concise and relevant.

Example in C#:

var response = await agent.GenerateResponseAsync(input, maxTokens: 100);

In this example, the response is limited to 100 tokens, which helps maintain brevity and relevance.

2. Context Management

Context management is another critical area where developers can minimize token usage. Instead of sending the entire conversation history to the model, it is more efficient to retain only the most relevant exchanges. Typicallly this comes down to retaining only the most recent exchanges. This approach not only reduces the number of tokens sent but also enhances the model’s focus on pertinent information.

Example in Python:

context = [message for message in conversation_history[-5:]]  # Keep last 5 messages
response = agent.generate_response(input, context=context)

By limiting the context to the last five messages, developers can significantly reduce token consumption while still providing the model with enough information to generate a relevant response.

3. Efficient History Management

When interacting with the model, it is essential to avoid resending large outputs or logs with every API call. Instead, developers should focus on sending only the essential context. Utilizing new threads for stateless interactions can also help prevent the unnecessary transmission of long histories.

Example in C#:

var newThreadId = Guid.NewGuid().ToString();
var response = await agent.GenerateResponseAsync(input, threadId: newThreadId);

This method ensures that each interaction is treated independently, minimizing the amount of historical data sent with each request.

4. Lightweight Summarization

To maintain continuity in conversations while reducing payload size, developers can implement lightweight summarization techniques. By periodically summarizing previous interactions, the summary can be sent as context, which helps keep the conversation relevant without inflating token usage.

5. Token-Optimized Object Notation (TOON)

Token-Optimized Object Notation (TOON) is a powerful technique for structuring data in a way that achieves high compression ratios. By using TOON, developers can significantly reduce token usage, with some reports indicating reductions of up to 98% for certain payloads. This method is particularly useful for applications that require the transmission of structured data.

6. Server-Side Computation

Another effective strategy for minimizing token usage is to move computation tasks to the server rather than performing them within the context of the model. By offloading these tasks, developers can reduce the amount of data sent to the model, thereby lowering token consumption.

Measuring Token Usage

To effectively manage token usage, developers must also implement robust measurement techniques. Here are some strategies for measuring token usage within the Microsoft Agent Framework:

Metrics Integration

Utilizing built-in metrics from the Microsoft Agent Framework allows developers to monitor input and output tokens, estimated costs, and latency. This data is invaluable for optimizing performance and identifying areas for improvement.

Breakdown Analysis

Conducting a breakdown analysis of token usage across different stages—such as retrieval, planning, and execution—can help developers pinpoint where savings can be made. By understanding which stages consume the most tokens, developers can focus their optimization efforts more effectively.

Real-World Use Cases

The techniques discussed above can be applied across various real-world scenarios, leading to significant improvements in efficiency and cost-effectiveness.

Chatbots

In chatbot applications, implementing these techniques can lead to substantial cost savings and enhanced performance, particularly in high-traffic environments. By managing token usage effectively, chatbots can handle more interactions without incurring excessive costs.

Multi-Agent Systems

In systems with multiple agents, distributing tasks among specialized agents can reduce redundant context passing and lower latency. This approach not only minimizes token usage but also enhances the overall responsiveness of the system.

Conclusion

In conclusion, managing and minimizing token usage in the Microsoft Agent Framework is essential for developing efficient AI applications. By implementing techniques such as token management, context management, efficient history management, lightweight summarization, TOON, and server-side computation, developers can significantly reduce token consumption. Additionally, measuring token usage through metrics integration and breakdown analysis allows for continuous optimization and improvement.

As the demand for AI applications continues to grow, adopting these strategies will not only enhance performance but also lead to substantial cost savings. By prioritizing token efficiency, developers can ensure that their applications remain competitive and effective in an increasingly crowded marketplace.

========== TOKEN USAGE FOR FIRST DRAFT OF THIS BLOG POST ==========
Input tokens: 4180
Output tokens: 1838
Reasoning tokens: 0
Total tokens: 6018

Shiny Controls 1.0 is here. One control suite, two renderers — native .NET MAUI and real Blazor components — sharing a Material 3 style token contract so a ShinyButton on iOS and a ShinyButton in the browser are the same control with the same API, not two lookalikes maintained in parallel.

The whole Blazor gallery is deployed and live. Every control below has a page in it, with the knobs wired up so you can drive the thing rather than read about it:

It is the same Sample.Blazor project that lives in the repo, published to WebAssembly. The theme selector in the header is not a demo affordance — it swaps the real theme pack stylesheet, and every control on every page restyles itself from the tokens.

There are too many controls to introduce one at a time, so here is the whole suite as a table. Each one links to its own docs, which is where the properties, templates and platform notes live.

Below are the three worth stopping on.

A full chat surface — bubbles, grouping, avatars, reactions, read receipts, typing indicators, attachments, optimistic send with retry, cursor-based paging that stays stable while messages arrive.

The thing that makes it different from a CollectionView with a bubble template is that it does not bind a Messages collection. You implement an IChatSessionProvider that hands the control a session-scoped IChatSession, and the control subscribes to that session’s live events on attach and disposes it on detach. Paging, live inserts, send verdicts and typing all flow through that one seam, so the control owns the hard part instead of leaving it in your view model.

<shiny:ChatView Provider="{Binding Provider}"
                SessionId="{Binding SessionId}"
                MyBubbleColor="#DCF8C6"
                OtherBubbleColor="White" />

public partial class ChatViewModel(IChatSessionProvider provider) : ObservableObject
{
    public IChatSessionProvider Provider { get; } = provider;
    public string SessionId { get; } = "demo";
}

That is the whole integration. Permissions drive what the UI offers — PermittedEmojis decides whether the reaction row appears at all, BodyPermissions gates the markdown toolbar — so the control never shows an affordance your backend will reject.

MAUI	MAUI — custom templates	Blazor

→ ChatView docs

Dim the page, cut an animated spotlight around one control at a time, say what it does. Onboarding, feature announcements, and the workflow someone only does once a quarter.

The design decision worth calling out: the steps live together on the walkthrough, in order — they are not attached properties on the controls they describe. On a real screen, with nested layouts and templated cells and a panel that is only sometimes there, attached ordering scatters the sequence across the markup where nothing can see it as a whole. Reordering becomes a hunt, and a step whose control is conditionally hidden silently derails everything after it. Here, reordering is moving a line, and IsVisible="False" drops a step out of the run and re-numbers the counter.

<shiny:Walkthrough RememberRunKey="home-v1" AutoStart="True" OverlayOpacity="0.8">

    <!-- No target: a centred welcome card, no cut-out. -->
    <shiny:WalkthroughStep Title="Welcome"
                           Text="Here is what is new in this release."
                           AnimationIn="Pop" />

    <shiny:WalkthroughStep Target="{x:Reference SearchBox}"
                           Title="Find anything"
                           Text="Search across every project you can see."
                           Placement="Bottom" />

    <!-- No card at all; the cut-out does the pointing. -->
    <shiny:WalkthroughStep Target="{x:Reference Avatar}"
                           Title="Your profile"
                           Text="Settings and sign-out live here."
                           Display="Spotlight"
                           Highlight="Circle" />

    <!-- Live control: the tap reaches it through the hole, and using it advances. -->
    <shiny:WalkthroughStep Target="{x:Reference SaveButton}"
                           Text="Press Save to finish."
                           AllowTargetInteraction="True"
                           AdvanceOnTargetTap="True" />
</shiny:Walkthrough>

RememberRunKey is what makes onboarding run once — it is backed by a replaceable IWalkthroughStore (Preferences on MAUI, localStorage on Blazor), and Restart() clears it. The tour paints into a layer above the page content, so a target inside a scroll view or a card gets highlighted where it actually is instead of being clipped by its container.

Welcome	Popover on a target	Circular spotlight	Live target

Top row MAUI (iOS), bottom row Blazor — same four steps, same XAML-shaped markup.

→ Walkthrough docs

Three views — a monthly calendar grid, a day/multi-day agenda timeline, and a vertically scrolling event list — over one data interface. You write the data layer once and pick the view per screen.

public class MyEventProvider : ISchedulerEventProvider
{
    public async Task<IReadOnlyList<SchedulerEvent>> GetEvents(
        DateTimeOffset start, DateTimeOffset end)
        => await myService.GetEventsAsync(start, end);

    public void OnEventSelected(SchedulerEvent selectedEvent) { /* navigate, show a sheet… */ }

    public bool CanCalendarSelect(DateOnly date) => true;
    public void OnCalendarDateSelected(DateOnly date) { }
    public void OnAgendaTimeSelected(DateTimeOffset time) { }
    public bool CanSelectAgendaTime(DateTimeOffset time) => true;
}

<scheduler:SchedulerCalendarView Provider="{Binding Provider}"
                                 SelectedDate="{Binding SelectedDate}" />

Multi-day events span correctly across all three views, the agenda draws a live current-time marker and supports extra timezone columns with sticky headers, the event list scrolls infinitely in both directions, and every visual element — events, headers, loaders, day pickers — is replaceable with a DataTemplate. Bindings use the static lambda overloads throughout, so it is AOT-safe with no string-based reflection.

Calendar	Agenda	Event list	Agenda + picker

→ Scheduler docs

Screenshots of a camera control are famously useless — a picture of a preview is just a picture — so here is what it actually does instead.

CameraView is a cross-platform camera for MAUI (AVFoundation on iOS / Mac Catalyst / macOS, CameraX on Android, Media Capture on Windows) with a matching Blazor WebAssembly control over getUserMedia. Live preview, lens and device selection, pinch-to-zoom, torch, flash, photo capture and video recording with quality/bitrate/frame-rate control are the table stakes.

The two things that set it apart are pluggable pipelines, and they compose with each other:

The frame-analysis pipeline. Assign a single IFrameAnalyzer — declared right in XAML, since the analyzer is the content property of CameraView — and frames stream to it off the UI thread with drop-on-busy back-pressure. Bounding boxes draw continuously via CameraOverlayView, but results are delivered on a gated scan trigger: arm with Scan() and the next confirmed detection fires once. An optional ScanWindow restricts detection to a region and draws an aim reticle. Built-in analyzers cover barcode/QR (native Vision and MLKit, restrictable by symbology), face detection with landmarks, motion clustered into debounced regions, OCR with scan-window crop and upscale for small text, and structured documents — invoices with order lines, receipts with line items and per-tax breakdowns, business cards, AAMVA driver’s licences, province-aware Canadian health cards, credit cards and passport MRZ — each a strong record with nullable fields. When the document is free-form, AiDocumentAnalyzer<T> detects presence cheaply on every frame and sends exactly one frame to a Microsoft.Extensions.AI IChatClient for structured extraction.

The effects pipeline. Effects is an ordered, live collection applied to the preview, captured stills and — on Apple — recorded video. Mutate it while the camera runs and the change lands on the next frame. Eleven colour grades, five spatial GPU looks (comic, sketch, posterize, pixelate, blur), compositing draw effects for watermarks and face masks anchored to tracked facial landmarks, and slow post-capture transforms such as AI photo stylization through an MEAI IImageGenerator. Four extension points let you add your own at the right layer. And because per-platform coverage is genuinely uneven, GetEffectSupport(effect) reports Full / ColorOnly / StillOnly / Unsupported so your UI can grey out what would otherwise silently do nothing.

Two more that are easy to miss: you can record and analyse at the same time on every platform — a dash-cam app reading signs off its own live feed while recording — and VideoRecordingOptions.Overlay burns a watermark, timestamp or telemetry into every encoded frame, drawn with Microsoft.Maui.Graphics so one implementation covers every platform.

→ CameraView docs

None of the above is styled by hand. Colour roles, surfaces, shape, elevation, typography, density, borders, state and spacing are a token contract the controls read — SetDynamicResource on MAUI, var(--shiny-*) on Blazor. The core packages define the contract and a built-in Basic theme; Ocean, Material, Terminal and Aurora install as separate NuGet packs and swap the whole app’s look without touching a page.

Basic	Ocean	Material	Terminal	Aurora

Want your own? The Theme Creator takes a few seed colours and exports the theme JSON, the Blazor CSS, or the MAUI C#.

dotnet add package Shiny.Maui.Controls     # .NET MAUI
dotnet add package Shiny.Blazor.Controls   # Blazor

Then go press things in the playground, and see the controls documentation for the rest.