Models

DebateTalk supports models from Anthropic (Claude family), OpenAI (GPT family), Google (Gemini family), Mistral, DeepSeek, Groq (fast inference), and others via OpenRouter. Each model is characterized by its strengths across six domains and assigned to one of three roles in a debate: debater, synthesizer, or adjudicator.

You can configure models manually or let Auto mode select the best panel for your question. The two approaches can be mixed: you might fix the synthesizer to a specific model while letting Auto mode choose the debaters, or you might specify a preferred debater set and let Auto mode fill the adjudicator slot.

Every model has a performance profile across six question domains. These scores drive Auto mode selection and are updated continuously using real debate performance data. A model that consistently produces high-accuracy answers on prediction questions will score higher in the Prediction domain over time. Auto mode uses these profiles to assemble panels where each debater is strong in the relevant domain.

The six domains are:

When auto_mode is set to true in your model configuration, DebateTalk classifies the question at the start of the debate and selects the highest-scoring models for that domain. The classification step is fast and runs before the first debater round begins.

The selection algorithm enforces provider diversity: it limits how many models from the same provider can appear in a single panel. This ensures the debate benefits from genuinely different training backgrounds rather than minor variations of the same base model. A panel composed entirely of GPT variants, for example, would produce less productive disagreement than a mixed panel.

You can preview which models Auto mode would select for a given question before committing to a debate. Send a request to the model recommendation endpoint (POST /v1/models/recommend) with your question text and optional domain override. The response includes the recommended panel with per-model domain scores for the detected domain.

Debaters are the primary reasoning models in a debate. They answer the question independently in the first (blind) round, revise their positions during deliberation rounds after seeing each other's arguments, and continue arguing until the adjudicator detects consensus or the maximum round limit is reached.

When selecting debaters manually, consider the question type and choose models with complementary strengths. For a normative question about AI regulation, pairing a model strong in Normative reasoning with one strong in Business gives the debate both ethical depth and practical grounding. For a prediction question about macroeconomic trends, pairing a Prediction-strong model with a Factual-strong one ensures the debate covers both probabilistic forecasting and empirical grounding.

The number of debaters you can configure depends on your plan (see Plans and Limits). More debaters produce richer debates with more perspectives represented, but each additional debater increases both latency and cost proportionally.

The synthesizer writes the final answer once the adjudicator determines that consensus has been reached. It receives the full debate transcript, including all blind-round answers, deliberation arguments, and the adjudicator's consensus assessment, then distills the debate into a single clear, well-structured response.

Because the synthesizer reads all positions before writing, it tends to produce more balanced and complete answers than any individual debater would. It is not simply averaging the debaters' outputs. It is identifying where positions converged, where they remained in tension, and how to represent both honestly in the final answer.

A good synthesizer should be strong at following complex instructions, integrating information from long contexts, and writing clearly. Models like Claude Sonnet and GPT models in the analytical family are well suited to this role. The synthesizer is fully configurable and defaults to a strong general-purpose model when auto_mode is enabled.

The adjudicator evaluates consensus after each deliberation round and scores debater accuracy at the end of the debate. It does not participate in the debate itself. Its two responsibilities are separate: during the debate it decides whether the debaters have reached sufficient agreement to proceed to synthesis, and after synthesis it assigns per-debater accuracy scores based on how well each debater's positions held up against the synthesized answer.

On Free accounts, consensus evaluation uses an algorithmic approach based on response similarity metrics rather than a model. Accuracy scores are not available on the Free plan. On Pro and Enterprise accounts, you can configure any supported model as the adjudicator. A model adjudicator produces richer consensus assessments with per-dimension scores and qualitative feedback explaining why it judged consensus as reached or not.

The adjudicator should be a model with strong analytical and evaluative capabilities, particularly strong instruction-following and judgment. Gemini 2.5 Flash is the default adjudicator in Auto mode. Claude Opus and GPT-4o are also well suited to the adjudicator role.

The table below lists the models currently available on DebateTalk. Context window sizes refer to the combined input context the model can process, which affects how many debate rounds the adjudicator and synthesizer can handle before hitting limits. The Min Plan column indicates the minimum subscription tier required to use the model.

The table above covers the main models available at the time of writing. New models are added regularly. For the complete live list including real-time health, latency, and uptime for every active model, see the Model Status page. The full list including domain score profiles and per-model pricing is also available programmatically via GET /v1/user/model-config.

All models are monitored continuously. The public model status endpoint (GET /v1/public/model-status) returns real-time health data for every model in the system. The response includes whether each model is currently healthy, its current response latency, its 24-hour average latency, and its 24-hour uptime percentage.

If a model becomes unhealthy during an active debate, it may be skipped for that round. When this happens, a model_skipped SSE event is emitted with the affected model name and the reason. The debate continues with the remaining debaters. A skipped model in the debater role reduces the panel size for that round but does not terminate the debate.

Auto mode checks model health before assembling a panel and will not select a model that is currently marked unhealthy. If health status changes between panel selection and the start of a debate round, the model_skipped event handles the fallback at runtime.

The /models page on the DebateTalk website shows a live model status dashboard updated every 30 seconds, with current health indicators, latency trends, and uptime history for each model.