Skip to main content

​
Models and Modes Reference

Stable selection guidance for Exa search types and compatibility-layer model routing.
  • Base docs URL: https://exa.ai/docs
  • Search reference: /reference/search
  • OpenAI SDK compatibility: /reference/openai-sdk

​
Search Types

Exa’s primary search modes for new work:

​
How Output Controls Affect Behavior

  • outputSchema adds synthesis work and therefore adds latency across search types
  • systemPrompt guides synthesis behavior but does not replace schema control
  • maxAgeHours: 0 forces fresh crawling and can increase latency substantially
Do not choose a deep variant only because you want structured output. Choose it when the retrieval task itself needs more reasoning or multi-step synthesis. If you are optimizing for responsiveness, start with:
  • type: "fast" when latency matters more than maximum quality, type: "instant" for real-time UX, or no type at all (default auto) otherwise
  • no outputSchema
  • default freshness behavior
Then add deeper reasoning or stronger freshness only when the use case requires it.

​
Answer and Compatibility Models

In OpenAI-compatible flows, current model routing is: These are compatibility-layer names. Native Exa endpoint choice remains the more important design decision. Use deep-reasoning when:
  • the task needs multi-step synthesized retrieval
  • you want a current Exa-first path instead of the legacy research surface
  • you need a replacement for legacy /research/v1 structured output flows

​
Practical Defaults

auto is almost always the right type, including for coding and agent workflows. Deviate only for a real latency or reasoning requirement:
  • General retrieval: omit type; the server defaults to auto
  • Latency-sensitive path: type: "fast" with highlights
  • Real-time UX: type: "instant" and minimal synthesis
Last modified on August 13, 2026