Which model should drive your Object Pascal edits
Arraydeck does not ship one fixed brain. You connect a cloud AI provider through a standard API endpoint, run a model on your own PC, or use the built-in model, and you can change the choice whenever a task needs something else.
Three ways to connect a model
A cloud AI provider
A cloud AI provider is reached through a standard API endpoint that you enter in the app, together with your API key. It suits large units, long refactors and tasks where a bigger model reasons better. The privacy consequence is plain. The prompt goes to the provider, including text from any file the agent reads, and it is handled under that provider's terms. Your API key stays on your PC, and secrets in tool output are redacted before they reach the model. Billing for the provider's service is between you and the provider.
A model running locally on your PC
A model running locally on your PC answers requests from your own machine. It suits private code, quick small edits and work where nothing may leave the computer. With a local model nothing leaves the machine, and chats, working folders and API keys stay on the PC as well. The limit is hardware. A small local model has a smaller context window and may need shorter units or clearer instructions, so read each diff with extra care.
The built-in model
The built-in model is ready to use without an endpoint of your own. Choose it when you want to try Arraydeck on a first project, read a unit or ask for a small change. Quality varies with the task like every model, so review the diff before you accept it, run your build command and keep Ask first switched on. You can connect a cloud provider or a local model later in the same settings.
What the Test button tells you
Press Test after you enter an endpoint, a key or a model name. The button checks the endpoint and shows the response time and the context window. The response time tells you how long a reply takes from this connection, which helps when you compare two models on the same task. The context window shows how much text the model can take at once, which matters for a long unit with many procedures. A failed test usually means a wrong address or key, so fix the settings before you start a task.
Choosing a model for the job
Use a bigger model for refactors, long units and complex logic, and a smaller one for small edits such as adding try ... finally or renaming a procedure. You can mix them in one chat. run_on_model sends a single hard step to a bigger model while the rest of the work stays on the model you picked, and task starts sub-agents when parts of the work can run in parallel. Match the model to the step, and check the context window with the Test button before you paste in a large unit.
Quality differs between models and between tasks, and no model gets every task right. Read each diff, build the project and run your tests before you accept a change. Ask first pauses before actions that change something, so a weak answer from any model costs you a few seconds of reading instead of a broken unit. Reject the diff and rephrase the request when it does not fit.
