The GitHub Copilot Harness in Copilot Studio, Explained

The short version: Copilot Studio now runs agents on one of three “harnesses” — the engine behind your agent. The new GitHub Copilot harness is the most capable: you describe an agent in plain language and it plans, reasons, works with files, and calls tools to get a job done end to end. The trade-off is billing — it’s usage-based (Copilot Credits) from the moment you start building, and the “free with Microsoft 365 Copilot” treatment that applies to the other harnesses doesn’t apply here.

🧩 One thing to get straight first: the GitHub Copilot harness (a runtime inside Copilot Studio) is not the same as GitHub Copilot (the coding assistant developers buy per seat). Same family name, different products, different bills. Jump to why ↓

This is the new experience (turn on “New experience” if you don’t see it). Instead of drawing out topics and flows, you describe the agent in plain language. (Lab tenant.)

Wait — what’s a “harness”?

I’ll be honest: the first time I saw the word “harness” I had to go and look it up too. Here’s the way I now think about it.

When you build an agent, three things are in play:

1. Your design — what you want the agent to do.
2. The model — the AI that does the reasoning and writing.
3. The bit in the middle — something has to decide when to call the model, what to send it, how to read the answer, and which tools to call next.

That bit in the middle is the harness. In Microsoft’s own words:

“The harness is a runtime that exists between the two: it determines when to call the model, what components to send it, interprets what comes back, and calls the right tools.” — Microsoft Learn, Choose a harness

The new part in 2026 is that Microsoft’s documentation now describes three harnesses — and which one you build on changes what your agent can do and how you’re billed.

The three harnesses at a glance

Here’s the plain-English comparison, straight from Microsoft’s Choose a harness guidance:

The “GitHub Copilot” tags and the “Uses Copilot Credits” pill are the tell — this is the metered harness. “Other ways to build” at the bottom is where the standard, rule-based agents and flows still live. (Lab tenant.)

The one-line summary I keep in my head: standard = follows your rules, GitHub Copilot = works out the steps, Copilot chat = grounds Microsoft 365 Copilot in your knowledge.

When should you use which harness?

So which one do you reach for?

• GitHub Copilot harness — when the agent needs to reason through a longer task, work across several tools, handle files, or run a real business process end to end. (Onboarding, accounts payable, triage-and-route, “read these and decide” work.)
• Standard harness — when the scenario is well-defined and rule-based and you want consistent, predictable answers. (FAQ bots, structured intake, “always do exactly this” flows.)
• Copilot chat harness — when you just want to extend Microsoft 365 Copilot Chat with your organisation’s knowledge so people get grounded answers without leaving Copilot.

Or follow the tree:

flowchart TD
    A["What are you building?"] --> B{"Just surfacing your knowledge inside Microsoft 365 Copilot Chat?"}
    B -- Yes --> C["Copilot chat harness"]
    B -- No --> D{"Is the job well-defined and rule-based?"}
    D -- "Yes, predictable and scripted" --> E["Standard harness (free to build and test)"]
    D -- "No, needs judgement" --> F{"Multi-step, many tools, files, or a whole process end to end?"}
    F -- Yes --> G["GitHub Copilot harness (usage-based credits)"]
    F -- "Not really" --> E

(Choosing between build tools — Agent Builder vs Copilot Studio vs Foundry — rather than harnesses within Copilot Studio? That’s a different decision: see Agent Builder vs Copilot Studio vs Foundry.)

So what is the GitHub Copilot harness?

Microsoft describes it as a redesigned authoring and runtime environment with a natural-language-first approach. Instead of drawing out explicit topics, triggers, and branching flows (the standard-harness way), you describe your agent in plain language and the system builds the underlying configuration.

What that unlocks, out of the box:

• Enhanced orchestration — it takes a goal, breaks it into steps, and recovers when a step fails or the request changes.
• Files as first-class — it can create and edit Word, Excel, PowerPoint, and PDF natively, and reason over them.
• Tools, knowledge & MCP — it calls connectors, knowledge sources, MCP servers and connected agents, deciding when to use each.
• Skills — reusable, self-contained instruction packages you build once and add to many agents.
• Memory (preview) — per-user context so an agent remembers preferences across conversations (it’s private from makers, off in group chats and Teams channels, and cleared after ~28 days of inactivity).

Microsoft’s example scenario is a good “aha”: an accounts-payable agent that reads invoices, matches them to purchase orders, and routes the exceptions for approval — the kind of messy, multi-step, decision-heavy process that a rules-based flow struggles with.

What’s new — and why you’re suddenly hearing about it

A quick, honest timeline (from Microsoft’s public What’s new page — I’m sticking to what’s actually documented):

• June 2026 — the new experience shows up in Copilot Studio’s What’s new as a production-ready preview: “The GitHub Copilot harness uses an enhanced orchestration runtime for improved response quality and reasoning, available alongside the classic experience.” Memory, Skills, connected agents and Microsoft IQ grounding land around the same time.
• As of August 2026 — it’s the experience you’re guided into at copilotstudio.microsoft.com (toggle New experience on if you don’t see it). To build the older way, turn the toggle off or choose “Other ways to build.”

The new experience has its own left rail — note Workflows, the GitHub Copilot harness automation surface. It isn’t just a rename: the classic experience keeps Agents, Flows and Tools, and standard-harness agent flows still live there. That’s why the menu looks different depending on which experience you’re in. (Lab tenant.)

One distinction worth holding onto: the new experience has two build types, both on the GitHub Copilot harness. Agents reason dynamically — they plan, adapt, and recover. Workflows are deterministic: they follow the exact path you author, so the same input always produces the same output. And a nuance that’s specific to Workflows — testing them from the designer or an agent’s test chat doesn’t consume capacity; only their live, executed actions meter. (More in Workflows overview.)

A Workflow, mid-build. The palette mixes deterministic building blocks (If/Else, Loop, Function) with AI actions and a Human-review step — and every flow hangs off a trigger (here, Manual / on-demand). This is the “follows the path you author” half of the harness. (Lab tenant.)

⚠️ A small but important honesty note on status. You might see this referred to elsewhere as “generally available.” As of August 2026, Microsoft’s public documentation still labels it a production-ready preview — so that’s the wording I’m using here. It’s a good reminder to treat the specifics (especially pricing) as still settling, and to confirm on Learn before you quote anything to a customer.

Is this the same as GitHub Copilot (the coding one)? No.

This is the question I get asked most, so let’s clear it up.

The way I explain it: the name points to a shared lineage with GitHub Copilot’s agent tooling — but I’ll be honest, I couldn’t find an official statement spelling out exactly how the two relate under the hood. The part that matters in practice is simpler: you don’t buy GitHub Copilot seats to use it. Nothing in the Copilot Studio setup asks for one.

The part everyone asks about: credits & consumption

Here’s the single most important thing to understand, and the reason I wanted to write this down.

On the standard harness, the rule of thumb has always been: free to build and test, you pay once you publish and run at scale — and a lot of internal, licensed usage is zero-rated (see our Copilot Studio pricing guide and What are Copilot Credits?).

The GitHub Copilot harness changes that rule. In Microsoft’s own words:

“Unlike the standard harness, which starts billing after publish, the GitHub Copilot harness charges credits from the moment you start building. Experiences such as creating an automated solution with natural language, previewing and testing the agent, and generating and creating agent evaluations all consume credits.” — Microsoft Learn, usage-based billing overview

And crucially: the Microsoft 365 Copilot “no extra charge for licensed users” treatment does not apply here. On this harness, build, test, evaluate and run all consume credits — regardless of whether the person holds a Microsoft 365 Copilot licence.

Where the two models differ — side by side

Here’s the fuller version — the same at-a-glance matrix Microsoft ships in its public Copilot Studio Licensing Guide (August 2026), rebuilt here as a readable table so it’s the version you can put in front of a customer:

* “Not billed (fair use)” applies only to employee-facing use, by an authenticated Microsoft 365 Copilot–licensed user, on a Microsoft 365 surface (Copilot / Teams / SharePoint), within fair-use limits (which Microsoft can update as the product evolves). Outside those conditions the published rate card applies — see the full boundary here. On the GitHub Copilot harness, natural-language authoring, testing, evaluating and runtime all consume Copilot Credits regardless of licence.
† Only the LLM-powered maker steps (natural-language authoring, evaluations, preview) bill on the GitHub Copilot harness — purely manual, non-LLM configuration doesn’t. In practice you are using the LLM to build here, so budget as if it meters from the first build action.
‡ Dataverse for Copilot Studio ships with default capacity (15 GB database, 20 GB file, 2 GB log); more is purchasable in 1 GB increments.
§ Managed Environments is included for Copilot Studio–related features; see the guide for the licensing detail.

The row that changes everything is the “Users with a Microsoft 365 Copilot licence” one: on the other two harnesses an authenticated Microsoft 365 Copilot–licensed user on an eligible Microsoft 365 surface can be zero-rated (within fair-use limits) — on the GitHub Copilot harness that treatment doesn’t apply. The reassuring flip side: the whole Supporting features block (connectors, on-prem data movement, Dataverse, Managed Environments, admin-centre management) is not separately billed on any harness.

🧮 Want to model it before you build? Microsoft has a public Copilot Studio agent usage estimator — pick agent type, traffic, orchestration, knowledge and tools to forecast credit consumption.

What actually drives the credit burn

Microsoft describes GitHub-Copilot-harness billing as usage-based and complexity-tiered, covering three things: the model tokens, the tools it calls (knowledge, MCP, connectors), and the harness itself. So your burn goes up with:

• Task complexity — more reasoning steps and retries = more tokens.
• How much context the agent pulls in, and how much of your data it reaches into.
• The tools and actions it invokes to finish the job.

⚠️ One honest gap: for the standard harness Microsoft publishes a neat per-action rate card (a classic answer = 1 credit, a generative answer = 2, an agent action = 5, tenant graph grounding = 10 — full table in Copilot Credits explained). For the GitHub Copilot harness, I could not find an equivalent public per-action table — Microsoft describes it as token/complexity-based and shows ranges, not fixed per-feature prices. So don’t promise a customer a tidy “X credits per run.” Pilot it, watch the meter, then model it.

How you pay, set it up, and keep it capped

Two ways to pay:

• Pay-as-you-go — $0.01 per credit, billed through a linked Azure subscription. Best for pilots and unpredictable usage.
• Prepaid capacity — capacity packs, or pre-purchased Copilot Credit Commit Units (CCCUs) (a one-year pool bought in the Azure portal), for steady, predictable usage.

Setting up pay-as-you-go (the part people miss) — it’s an Azure-billed meter, so there’s a bit of setup:

1. You need an Azure subscription in the tenant, and someone with Owner/Contributor on it (to create the resource and register providers).
2. A Power Platform / Global / Dynamics 365 / Environment admin creates a billing policy in Power Platform admin centre → Licensing → Pay-as-you-go plans → New billing plan, points it at that Azure subscription + a resource group, and links the environment(s) (production or sandbox).
3. That quietly creates a “Power Platform account resource” in Azure — every Copilot Studio meter for those environments bills to it. Full steps: Set up pay-as-you-go.

This is the setup step people skip. One billing policy ties an Azure subscription + resource group to your environment(s) — and lists Copilot Studio among the metered products. That link is what routes your credit usage to an Azure bill. (Lab tenant — subscription redacted.)

Where the cost actually shows up — this is the bit I had wrong in my head at first:

So: PPAC tells you the credits; Azure tells you the money. The Microsoft 365 admin centre is for buying licences and prepaid packs — it doesn’t show your PAYG spend.

And here’s the part PPAC won’t show you: the actual dollars, in Azure Cost Management. Notice it surfaces under the Power Platform / Power Automate service family and your billing-plan resource group — there’s no line literally called “Copilot Studio.” (Lab tenant — subscription redacted; the figures are lab-tiny.)

Keeping it capped — the levers that actually work:

• Per-agent monthly limit (the real cap). In PPAC → Licensing → Copilot Studio → Manage Agents, set a monthly credit limit per agent — with notifications and an optional hard stop that turns the agent off when it hits the limit. This works whether the environment is prepaid or PAYG, so it’s your best guardrail against a runaway build/test agent.
• Azure budgets & cost alerts. On the Power Platform account resource in Azure Cost Management you can set budgets and alerts — but note they only notify; they don’t stop spend. Pair them with the per-agent hard stop.
• ⚠️ PAYG bypasses environment enforcement. If an environment has PAYG linked, running out of prepaid capacity doesn’t disable agents — the overage just flows to Azure. That’s convenient, and exactly why the per-agent limit matters.

The guardrail I’d set on anything experimental: a per-agent monthly limit plus the “turn off the agent at 100%” hard stop. Azure budgets only warn you — this actually stops the spend, and it works for pay-as-you-go too. (Lab tenant.)

The screen to bookmark for credits: Power Platform admin centre → Licensing → Copilot Studio — consumption by environment/agent, plus Manage Agents for per-agent limits. For the actual dollar spend, head to Azure Cost Management on the linked subscription. (Lab tenant — figures zeroed.)

Governance & keeping costs under control

Because the meter runs from the first build action, the questions I get from admins and CISOs are less “what can it do?” and more “who can spend, and how do we cap it?” Here’s what I’ve been able to confirm from Microsoft’s docs.

Who can build one. The tenant admin acquires the Copilot Studio tenant licence and assigns per-user Copilot Studio user licences to makers in the Microsoft 365 admin centre. You can further restrict who builds through the Copilot Studio authors setting in the Power Platform admin centre, which you point at an Entra security group. Two reassuring details: people who just use a published agent through a channel need no special licence, and guest users can’t access Copilot Studio at all.

Sharing has a catch worth knowing. When you share a GitHub-Copilot-harness agent from the new experience, you’re granting view-and-test rights only — and the people you share with need their own Copilot Studio per-user licence (or a trial). To let someone actually edit the agent, you switch it back to the classic experience and grant them environment security roles. So for multi-maker delivery teams, decide up front who builds where. (Share agents)

Turn the model on first. The natural-language creation experience runs on Anthropic models. An admin has to allow Anthropic in the Microsoft 365 admin centre and enable external models for the environment; without that, natural-language creation is unavailable (the classic build paths still work). Worth checking two gates and one compliance boundary before you switch it on: Anthropic must be allowed both in the Microsoft 365 admin centre and on the Power Platform environment (Settings → Product → Features) — miss either and the toggle stays greyed out. And per Microsoft’s current docs, Anthropic models in Copilot Studio are excluded from EU Data Boundary commitments, FedRAMP isn’t achieved, and PCI DSS isn’t applicable — so if you’re bound by any of those, review before enabling. (External models & exclusions)

Why the “describe your agent” box sometimes isn’t there: it needs both gates. Anthropic has to be allowed in the Microsoft 365 admin centre and ticked here on the environment. See Mistral right below it — greyed out precisely because it’s still off in the admin centre. That’s the dependency, made visible. (Lab tenant.)

Cap the spend. Copilot Credits are allocated to environments, but your most precise lever is the per-agent monthly limit in PPAC → Licensing → Copilot Studio → Manage Agents — set a cap per agent, with an optional hard stop that turns the agent off at the limit. Use it especially on experimental build/test agents, since PAYG overage just flows to Azure rather than disabling anything. Watch credit consumption in PPAC and the actual dollar spend in Azure Cost Management (Azure budgets there can alert you, but don’t stop spend). Full detail in How you pay, set it up, and keep it capped above.

Govern it like the rest of Power Platform. These agents live in Power Platform environments, so your existing environment strategy and data loss prevention (DLP) policies apply — DLP can restrict which connectors, knowledge sources and channels an agent may use — so keep dev / test / production separate, watch consumption in the admin centre, and download recent conversation transcripts from the agent’s Monitor tab for review (any window within the last 29 days; note the data can take up to an hour to appear). One reassurance for security teams: Microsoft says each GitHub-Copilot-harness task runs in a secure sandbox governed by Copilot Studio.

⚠️ Exact admin controls are still settling while the harness is in preview — confirm current behaviour in Microsoft’s enforcement policy and licensing & access docs before you design a rollout.

How to actually build one

The workflow’s friendlier than I expected — here’s the shape of it.

✅ Before you build — a 60-second pre-flight:

• Channel — is your target surface actually live on this harness yet? (Today: Microsoft Teams, Microsoft 365 Copilot, a demo website, or a web app.)
• Model — is Anthropic allowed in both the Microsoft 365 admin centre and the Power Platform environment?
• Compliance — are you OK with the current Anthropic caveats (excluded from EU Data Boundary, no FedRAMP, PCI not applicable)?
• Access — who needs view/test (needs a Copilot Studio licence) versus edit (classic experience + environment security roles)?
• Cost — have you set a per-agent hard stop before you start, since the meter runs from the first build action?

📋 Prerequisite worth knowing: the natural-language creation experience uses Anthropic models, and it’s only available in environments where access to Anthropic models is turned on. If the “describe your agent” box isn’t available, that’s one of the first things to check — ask your admin whether Anthropic models are enabled for your environment.

1. Go to copilotstudio.microsoft.com. The new (GitHub Copilot harness) experience is the one you’re steered into — if you don’t see it, turn on the New experience toggle. (Want the classic builder instead? Turn the toggle off, or choose “Other ways to build.”)
2. Describe what you want in plain language — e.g. “Answer employee questions about our leave and expense policies, and draft a short leave-request summary for a manager.”
3. Answer its clarifying questions. It analyses the request, decides whether you need a workflow, a conversational agent, or both, and builds it in real time while you watch the Steps and Artifacts.
4. Refine on the Build tab — set the agent’s instructions (plain-language/Markdown), knowledge, tools, skills, model, and memory.
5. Try it on the Preview tab — an interactive test chat with a chain-of-thought trace. (Remember: this consumes credits on this harness.)
6. Check quality on the Evaluate tab — build test cases (by hand, AI-generated, or CSV) and run them. (Also consumes credits.)
7. Publish — currently to Microsoft Teams, Microsoft 365 Copilot, a demo website, or an embedded web app. (SharePoint and the messaging / contact-centre channels aren’t available on this harness yet — check the current channel list before you promise one.)
8. Monitor — track tasks, files accessed, and usage after go-live.

Here’s what that looks like in practice — I spun up a simple Leave & Expense Assistant to walk through it.

The Build tab — you write instructions, not flowcharts:

Notice the model picker — you choose the model that powers the agent’s reasoning. My lab tenant showed Claude Opus 5, which wasn’t yet in public Microsoft Learn when I checked — the public model list currently shows Claude Sonnet 5 (GitHub-harness-only), plus Claude Opus 4.6 / 4.7 and the GPT‑5 family. Availability is regional and release-ring-specific, so trust your own picker over any list you read (mine included). (Separately, the natural-language creation step runs on Anthropic models — which is why an admin has to enable those.)

The picker, opened up. My lab ring was running Claude Opus 5 as the default and even a Claude Fable 5 (Experimental) — both ahead of what public Learn listed the day I checked. The lesson holds: trust your own picker, and mind the Experimental / Preview tags before you ship anything. (Lab tenant.)

The Preview tab — you can watch it reason:

A nice detail: with no company policy document loaded, it refused to invent a carry-over number and pointed to the HR service desk instead. In this test, refusing was safer than guessing — the behaviour you’d hope for in front of a customer.

The Evaluate tab — test at scale (and yes, it meters):

I let it auto-generate 10 test conversations and score them. It scored low on purpose — with no policy document connected, the honest “I can’t confirm that” answers count as low-quality for a real deployment. The point for this post: generating and running those evaluations consumed credits, before I ever published. On the standard harness, that authoring and testing would be free.

The Monitor tab — where live consumption lands once you publish:

Everything reads zero here because I only tested in Preview — the Monitor tab tracks published runtime. But this is the dashboard you’ll live in once the agent is real: conversation sessions, Copilot credits consumed, savings, and tool use, all in one place (and you can download recent conversation transcripts — any period within the last 29 days — for review).

Make it actually useful: give it knowledge

Remember how my demo agent refused to state a carry-over number? That wasn’t a bug — it’s the honest behaviour you want. But it also shows the flip side: an agent is only as useful as what you ground it in. Out of the box it reasons well and knows nothing about your organisation.

To make it genuinely helpful, add grounding on the Build tab:

• Knowledge — your own files, plus SharePoint sites and public websites.
• Microsoft IQ — connects the agent to your Microsoft 365 data (emails, files, Teams messages, calendar, people) so answers are grounded in your tenant.
• Foundry IQ — added from the Build tab’s Tools button (not Knowledge) — connects a knowledge base already built and tuned in Azure AI Foundry.

Beyond your own files, SharePoint and public websites, the Add knowledge dialog can also surface ServiceNow, Confluence, Jira, Azure DevOps Work Items, Dataverse, Azure AI Search and Copilot connectors — the exact list depends on your environment and licensing. (Keep one distinction straight: a knowledge source is something the maker wires in for everyone at design time; a file a user drops into a single chat is an attachment, not knowledge.)

Give the Leave & Expense Assistant the actual leave policy, and when the source contains the answer it can ground its reply in that content — often with a citation — instead of declining. Grounding doesn’t guarantee correctness, though — validate retrieval and answers in Preview and Evaluate. (Retrieval and tokens add credits — capability and cost move together.)

A few things that surprised me

Building the little agent made a few of the docs’ details finally click for me. The honest list:

• You can’t switch harnesses later. An agent built on the GitHub Copilot harness can’t be transferred to the standard harness (or vice versa) — changing harness means creating a new agent. So pick the harness deliberately up front.
• No Anthropic models, no describe-your-agent box. If the “describe your agent” experience isn’t there, the Anthropic-models setting is one prerequisite worth checking.
• Evaluations can look brutal — and that’s OK. My agent scored 20%. The general-quality check rates relevance and completeness (it doesn’t compare against expected answers), and an ungrounded agent that keeps saying “I can’t confirm that” scores low. Grounding usually moves it.
• “Honest refusal” is a feature. Declining to invent a number was safer than guessing here. Don’t mistake “I can’t confirm that” for failure.
• Monitor stays dark until you publish. All those zeros aren’t a bug — Preview and Evaluate don’t count as published runtime.
• It’s a preview. Names, screens and especially pricing detail are still moving. I’ll keep this post updated.

What I’d tell a customer today

If I had five minutes, this is the honest summary I’d give:

• It can be a real step up for the right work. Describe-it-and-it-plans is a different way to build — well suited to messy, multi-step processes.
• The billing model is the thing to get right. On this harness the meter starts when you start building, and a Microsoft 365 Copilot licence doesn’t zero-rate it. Budget for build/test, not just runtime — and remember credits show in PPAC, dollars show in Azure, so set a per-agent hard stop on anything experimental.
• It’s still a preview (publicly). Expect change — especially on pricing detail — and confirm on Learn before you quote numbers.
• It’s not GitHub Copilot. You don’t buy developer seats to use it.
• Pilot before you promise. There’s no tidy public per-action price yet, so run a small real workload, read the usage reports, then model the cost.

And if I’m with a customer, three questions usually sort out whether this harness even fits:

1. Is the work predictable, or does it need judgement? Scripted → standard harness. Judgement across steps → GitHub Copilot harness.
2. Who owns the build/test credit budget? Because the meter runs from the first build action, someone has to own that spend.
3. What approved knowledge and tools can it touch? That decides how useful — and how governable — it’ll be.

The simplest rule I’d leave them with: use it for judgement-heavy work, and budget from the first build session. I’m still learning this one as it evolves — if you spot something that’s moved on since I wrote this, I’d genuinely love to hear it.

Reference: plain-English glossary

The jargon, minus the jargon:

• Harness — the runtime “driver” between your design and the AI model; it decides when to call the model, what to send it, and which tools to use. Copilot Studio has three: GitHub Copilot, standard, and Copilot chat.
• Orchestration — the harness working out the steps to reach a goal: plan, call a tool, read the result, decide what’s next, and recover if something fails.
• Copilot Credits — Microsoft’s metering unit for agent work. The GitHub Copilot harness bills in credits for build, test, evaluate and run.
• Skills — reusable, self-contained sets of instructions you build once and add to many agents (exportable as Markdown or packages).
• Memory (preview) — lets an agent remember context and preferences across conversations, per user (private from makers; cleared after ~28 days of inactivity).
• Connected agents — other Copilot Studio agents your agent can hand work to, so a “front-door” agent routes to specialists (currently limited to other Copilot Studio agents).
• Tools — the connectors, APIs and actions an agent calls to do things, not just answer.
• MCP (Model Context Protocol) — an open standard for plugging external tools and data sources into an agent in a consistent way.
• Grounding / knowledge — the trusted content (files, SharePoint, Microsoft 365 data, a Foundry knowledge base) an agent draws on so its answers reflect your organisation.

Where to go next

• Is Copilot Studio Free? Pricing, Credits & PAYG Explained — the money side, in full (this post’s companion).
• What Are Copilot Credits? — the meter, the rate card, and what’s zero-rated.
• Agent Builder vs Copilot Studio vs Foundry — which build tool to pick in the first place.
• Microsoft Learn: Choose a harness · Usage-based billing overview · Standard harness licensing