Authentication
The provider controls how
AI Manager signs in
AI Manager signs in
Connect an AI Provider
Wappler Options setup for AI providers, GitHub Copilot as the preferred default, and request-based versus token-based usage in AI Manager.
Start with the provider layer before you judge the AI Manager
Use this tour when AI Manager is ready but the account and provider choice is still fuzzy. In Wappler, provider setup is a foundation choice: it decides how the manager authenticates, which models can be listed, and how usage is accounted for before you even send the first serious prompt.
Model access
The provider determines what
models can be listed
models can be listed
Usage shape
The provider changes how
usage is metered
usage is metered
Workflow fit
The best provider is the one
that fits the team
that fits the team
The provider is chosen in Wappler Options, not inside each task
AI Manager reads the configured chat provider from Wappler Options. The important model is that provider setup does not live inside each AI task. It lives in the global Options dialog, under AI Settings, and that single choice affects model availability, account behavior, and how the manager reconnects after options change.
Set the provider once in Wappler Options, then let AI Manager reload around that choice.
Provider changes affect model listing and account behavior, not just branding.
Treat provider setup as workflow plumbing, not a one-off click.
AI Settings is where provider setup actually lives
This Options dialog is where Wappler keeps the global AI configuration surface. The AI Settings section inside it is the place you revisit when you need to connect a provider, switch providers, or confirm which provider family AI Manager should use.
Prefer GitHub Copilot for the smoothest default path
For most users, GitHub Copilot is the easiest default because the provider choice is straightforward, the sign-in and entitlement flow is simpler, and the transition into AI-assisted Wappler work is low friction. In practice, this is the provider you will usually pick first in the AI Chat Provider option before deciding whether another provider is worth the extra setup.
Fastest start
Usually the least
setup friction
setup friction
Strong coding help
Fits naturally with
Wappler build work
Wappler build work
Good default
A reliable first choice
before deeper tuning
before deeper tuning
Understand requests, tokens, and why Wappler keeps usage tighter
GitHub Copilot is often experienced as a request-based service, while other providers are commonly consumed through API tokens and metered model usage. That line is getting blurrier because GitHub is also moving toward token-based accounting in more places. The useful habit is not to optimize for billing jargon alone. Optimize for the workflow where Wappler can keep requests focused, reduce wasted context, and use the provider efficiently for the actual task.
Copilot today
Often feels request-led
from the user side
from the user side
Other providers
More obviously token- or
usage-metered
usage-metered
Wappler advantage
Tighter context and better
request shaping
request shaping
Use other providers when model access, policy, or privacy matters more
Copilot is the preferred starting point, but Wappler should still show the wider provider landscape clearly. Some teams need a specific Claude or GPT family, some need direct API ownership, and some need provider policies that match company rules. The right move is to pick the provider that fits the team, then keep Wappler as the place that optimizes how that provider is used.
Choose Copilot when ease of setup and broad usefulness matter most.
Choose another provider when access to a specific model family or policy matters more.
Keep Wappler as the orchestration layer that reduces wasted usage either way.
Close the Options dialog
Advance once to close the Options dialog so the tour can return to AI Manager for the next handoff step.
After the provider is connected, choose the model for the kind of work
Provider setup gets the AI Manager online. The next decision is model choice inside the manager itself: which model is best for design judgment, which is best for programming and orchestration, and when it makes sense to switch between them within one feature workflow.
