Skip to main content
A model generates the agent’s responses and tool requests. Your project and tools supply the working context; the selected model uses that context to decide what to do next. Start with a model from your configured MKA1 gateway. Add a separate provider only when your organization supplies another compatible endpoint for local Code sessions.

​
Select a model for a task

Open the model picker beside the composer before sending a request. The gateway catalog determines which models your account can select. For a code investigation, choose a model suited to reading code and working through tool results. For screenshots or browser checks, the model and endpoint must accept image input. Some models expose reasoning-effort choices. Use the levels offered by the selected model; availability varies by endpoint. Choose a task with a result you can verify when comparing models, such as explaining a function with file references or fixing a failing regression test. Compare the correctness of the result and the verification performed, not only the length of the answer. If the picker is empty, check account access and Settings → Connection → Test connection. Refresh the catalog after correcting the connection. Do not substitute a guessed model identifier for a missing catalog entry.

Select a model before sending a request. The catalog shown here belongs to the local demonstration gateway.

​
Set the connection default

In Settings → Connection, choose the default Model for new conversations and agent runs. Use the catalog when available. If your organization supplies an exact ID absent from the list, Type manually lets you enter it; Pick from list returns to the catalog. Choose Save to apply connection changes. Test connection checks gateway access and the available models but does not save the form. Keep the default server address unless your installation requires a different gateway. Changing the server origin removes its active credential, so sign in again after saving. The connection default is a starting choice for new work. Check the model displayed in the active session before sending a request, especially when returning to an earlier conversation.

​
Add a model provider

Settings → Model providers registers additional models for the local Code engine. Use the endpoint operator’s documented protocol, limits, and capabilities. The form’s initial numeric values are suggestions, not evidence that the endpoint supports them.
  1. Choose New provider and enter a recognizable name.
  2. Select OpenAI Responses, OpenAI Chat Completions, or Anthropic Messages, according to the endpoint’s API.
  3. Enter the base URL and required API key. A local endpoint may omit the key if it does not require authentication.
  4. Add at least one model using the endpoint’s exact model ID and a readable display name.
  5. Set its context and output limits, image support, and supported reasoning levels from the operator’s specifications.
  6. Save the provider and try a small local Code task with the configured model.
For a first check, ask the model to read the project’s README and identify the test command without editing files. Inspect the file-read result and answer. If text works but images or tool calls fail, check those endpoint capabilities before attempting a larger task.

​
Update or remove a provider

Open a saved provider to edit its configuration. Stored keys do not reappear in the form: leaving the key field empty retains the saved key; Remove saved key removes it. Deleting a provider requires confirmation. Custom-provider requests go to the configured endpoint. Use an endpoint authorized for the project data you will send, including relevant file contents and tool output. For remote work, provider configuration and credentials require the separate transfer choices described in Remote development.