Pick the model that drives your dApp agent
AlphaWeft needs a model to plan steps and write code. You can connect a cloud AI provider through a standard API endpoint, run a model on your own PC, or use the built-in model, which is ready to use without an endpoint of your own. Press Test to check any endpoint before the first task.
Three ways to connect a model
Cloud AI provider
A cloud AI provider is the usual choice for large refactors and for projects where the model has to keep many files in mind. You enter the provider's API endpoint and your key in AlphaWeft, and the key stays on your PC. The consequence is plain: every prompt goes to that provider, including the text of any file the agent reads for the task. Use it for code you are comfortable sharing and keep secrets out of the working folder. The provider may charge for its model separately, and AlphaWeft itself needs no account.
A model on your own PC
A model running locally on your PC suits private projects, such as a front end for a contract you have not published. You run the model yourself and connect AlphaWeft to it. With a local model nothing leaves the machine, so the file text the agent reads stays on your PC. The trade-off is hardware. A smaller local model can handle small edits and explanations but may struggle with a large refactor, so read its diffs carefully. The Test button shows you its response time and context window.
The built-in model
The built-in model is ready to use without an endpoint of your own. Choose it to try AlphaWeft right after installing, on a first task such as mapping a folder, reading an ABI file or explaining a build error. Read its diffs as you would read any other model's, because every model can make mistakes. Later you can connect a cloud AI provider or a local model for harder steps, by connecting it in the app.
Check the connection with Test
After you enter an endpoint, press the Test button. AlphaWeft checks the endpoint, shows its response time and shows the context window, which is how much text the model can take in at once. A slow response time tells you that every card will take a while to appear. A small context window warns you that a long ABI file plus several components may not fit in one request. Test does not judge the quality of the answers, only the connection. Run one small task, such as reading balance-abi.json, and look at the diff before you give the model anything larger.
Match the model to the task
Use a bigger model for refactors that touch many files and for tricky logic, such as the handling of a transaction that stays pending or fails after a wrong-network error. Small edits rarely need one: renaming a variable, adding a loading state or fixing an import can go to a smaller, cheaper or local model. The run_on_model tool lets the agent send one hard step to a bigger model while the rest of the chat stays on the model you picked. If a step fails twice, change the model for that step instead of repeating the same prompt a third time.
The quality of the output varies from model to model, and no model is always right. In Ask first mode each change waits as a diff, so you see exactly which lines the model wants to add or remove. Read them, accept the ones that match your intent and reject the rest. Then run your test command and read its output before you move on.
