Models

The AI Models tab is where you configure the default model used across your project and explore all available models for agent execution.

Every task, chat session, repository analysis, and code generation request runs through a model. The selection you make here directly impacts:

• reasoning depth,
• code quality and completeness,
• document handling capability,
• response speed,
• token consumption and cost.

Teams typically configure this page early when setting up a project, then revisit it when workflows evolve, for example, when moving from simple refactors to document-heavy feature development.

Default Model

At the top of the page, you can select a Default Model for the project.

This model will be used automatically when:

• starting new chat sessions,
• executing tasks,
• generating or modifying code,
• reasoning over repository context,
• processing project documents (if supported).

Changing the default model does not affect past sessions or completed tasks. It only applies to future executions.

Example

If your team is working on routine backend fixes and incremental refactors, you might choose a fast, text-focused model as the default to keep latency and cost low.

If you begin working with large product requirement documents (PRDs), diagrams, or uploaded PDFs, you may switch the default to a multimodal model that supports documents and broader context.

This ensures that the model aligns with the type of work your project is currently performing.

Model Discovery and Selection

The right side of the interface provides:

• A searchable list of available models.
• Clear provider grouping (e.g., Anthropic, Alibaba, others).
• Capability tags such as Text, Vision, or Multimodal.
• A detailed information panel for the selected model.

This layout allows you to compare models based on:

• input capabilities,
• reasoning strength,
• cost profile,
• supported modalities.

Model Capability Types

Each model is labeled according to the type of input it accepts. These labels are critical when aligning model choice with workflow needs.

Text Models

Text models accept text input and produce text output.

They are best suited for:

• code generation and refactoring,
• debugging and test fixes,
• reasoning over repository files,
• writing documentation,
• task-based development workflows.

Text models are typically faster and more cost-efficient. For most code-centric projects, they serve as a practical default.

Vision Models

Vision models accept both text and images as input.

They are useful when workflows include:

• analyzing UI screenshots,
• reviewing design mockups,
• interpreting diagrams,
• combining visual artifacts with textual instructions.

For example, if you upload a screenshot of a UI bug and ask the agent to identify layout inconsistencies, a vision-capable model is required.

Vision models are not optimized for large document ingestion.

Multimodal Models

Multimodal models accept:

• Text
• Images
• Documents (such as PDFs)

They are designed for complex, document-heavy workflows, including:

• reviewing PRDs or architecture documents,
• cross-referencing large specs with repository code,
• combining screenshots, documentation, and code context in a single task.

Because multimodal models process broader context, they typically consume more tokens and may incur higher cost. Teams often enable them intentionally for feature design phases or specification-driven development.

Model Details Panel

When you select a model from the list, a detailed panel appears with technical information to support informed selection.

Model Overview

The overview describes:

• the model’s intended strengths,
• reasoning characteristics,
• typical use cases (e.g., complex reasoning, agentic workflows, coding tasks).

This information helps determine whether the model is appropriate for lightweight tasks or deeper reasoning scenarios.

Accepted Inputs

Each model clearly lists the input types it supports:

• Text
• Images
• Documents

This determines whether the model can be used with uploaded PDFs, screenshots, or multimodal context inside Origin.

If your workflow includes uploading a requirements document for analysis, you must select a model that supports document input.

Token Pricing

The panel also displays:

• Input cost (per million tokens),
• Output cost (per million tokens).

This pricing information helps teams estimate:

• cost per task,
• impact of large document ingestion,
• trade-offs between speed and depth.

For example, a model with higher output token pricing may be ideal for complex reasoning tasks but may not be necessary for simple formatting changes.

Actual usage trends can be reviewed separately in the project’s usage analytics, while this page helps you evaluate pricing at selection time.

How Model Selection Affects the Project

The selected default model influences:

• response quality and reasoning depth,
• execution speed,
• cost profile,
• compatibility with images and documents in context.

Model selection does not:

• change repository access,
• alter permissions,
• modify security boundaries,
• affect workspace configuration.

It strictly determines how agents process input and generate output within the project’s existing constraints.

Practical Scenarios

Teams commonly revisit the AI Models tab when:

• scaling up usage and monitoring cost,
• introducing document-driven development,
• debugging complex multi-file architectural issues,
• aligning defaults across multiple projects,
• experimenting with higher-reasoning models for critical tasks.

For example:

• During early experimentation, a team may use a cost-efficient text model.
• During a major refactor guided by a detailed design document, they may switch to a multimodal model.
• After stabilization, they may revert to a faster model for routine iteration.

This flexibility allows you to adapt the project’s intelligence layer without changing repository configuration or workflow structure.