War Room Autopilot¶
Autopilot runs an automated War Room debate using provider API keys that you bring to SynContext. SynContext is shared project memory for Claude and other MCP-compatible clients; Autopilot uses that project memory to prepare model turns, stream the debate into the room, and save the resulting messages so the discussion remains attached to the project record.
Use Autopilot when you want a fast structured debate instead of manually moving between clients. It is best for architecture choices, implementation plans, security reviews, code review disputes, and decisions where you want several model perspectives before resolving the room.
Autopilot does not replace judgment. It drafts arguments, counterarguments, and synthesis messages. You still choose whether to accept the recommendation, ask follow-up questions, or resolve the room into a decision.
Availability¶
Autopilot is available on Pro and Team. Free accounts can create and participate in manual War Rooms, but they cannot start Autopilot runs.
The current monthly run limits come from context_hub/config.py: Free has 0 Autopilot runs, Pro has 3, and Team has 50. A run that has already called a provider may still count even if it is later cancelled, because provider tokens may already have been used.
| Capability | Free | Pro | Team |
|---|---|---|---|
| Autopilot runs per month | 0 | 3 | 50 |
| Models per debate | Not available | 2 | 4 |
| Rounds per debate | Not available | Up to 3 | Up to 5 |
| Max tokens per response | Not available | 4096 | 8192 |
| Provider key storage | Not available | Anthropic and OpenAI, default endpoints only | Custom providers and custom base URLs that pass validation |
These values are enforcement values, not marketing estimates. Documentation about quotas should stay aligned with config.py and the validation in orchestrator.py.
Bring Your Own Keys¶
Autopilot uses BYOK: you add your own provider API keys and SynContext uses them only to run the debates you start. Token usage is billed by the provider account behind those keys. SynContext does not absorb provider token cost, and it cannot guarantee what a provider will charge for a selected model.
Stored provider keys are encrypted before persistence and are not returned to the frontend after saving. You can remove or replace provider keys from settings when you no longer want SynContext to use them.
The Two BYOK Gates¶
There are two separate gates, and both matter.
Storage Gate¶
The storage gate controls which provider keys and base URLs a user can save. It is enforced by save_orchestration_key in context_hub/db/operations.py.
Pro can save only the built-in providers anthropic and openai. Pro cannot save a custom base_url; a non-empty custom provider URL requires Team.
Team can save custom provider names and custom base_url values. Custom URLs are validated before storage. In hosted mode, the URL must use https://. Remote hosts also go through SSRF protection before the URL is accepted. Localhost exceptions are only for local development behavior.
Consumption Gate¶
The consumption gate controls how many saved provider configurations can participate in a single debate. It is enforced by context_hub/orchestrator.py when validating models.
Pro can use up to 2 models per debate. Team can use up to 4 models per debate. This gate does not replace the storage gate; it runs after keys have been saved and after the debate configuration is submitted.
Provider and Model Configuration¶
Each model entry in a debate configuration needs a provider and a model name. If the model name is omitted, SynContext uses the default model stored with that provider key. If neither the entry nor the provider key has a model name, the run fails before a provider call is made.
For Anthropic, SynContext uses the Anthropic client. For OpenAI-compatible providers, it calls the configured endpoint using the chat completions shape. Team custom endpoints should be compatible with that request format and should expose a /v1/chat/completions route after the configured base URL.
Use clear labels for keys when you have multiple environments, such as production, staging, or a local gateway. Keep provider names short and stable; a provider name is used when resolving the saved key for a model entry.
Starting a Run¶
Start from an open War Room. Choose the room topic, template, models, number of rounds, max tokens per response, and whether to include synthesis when the interface offers that option. Autopilot validates the plan before making provider calls: tier, monthly quota, active run status, model count, provider keys, rounds, and max token ceiling.
A valid run creates an orchestration record, loads project context, assigns roles from the selected template, and begins calling models one turn at a time. Each completed model response is saved as a War Room message with a source such as provider/model and a stance when the response includes one.
The room remains the system of record. After the run finishes, you can continue manually, post corrections, or resolve the room into a decision.
Streaming and Cancellation¶
Autopilot streams progress while the run is active. Expected stream events include round starts, completed messages, token or cost updates when available, round completion, final completion, errors, and heartbeats. If the browser or client disconnects, read the War Room again to recover saved messages.
Cancel a run when the debate is no longer useful, the wrong model was selected, or a provider is failing repeatedly. Cancellation stops additional work, but it cannot undo provider calls that already happened. If tokens have already been spent, the run may still count against the monthly quota.
Rounds, Models, and Tokens¶
Use the smallest run that can answer the question. A two-model, one-round debate is often enough for a narrow code review question. More rounds help when the first answers disagree or when a synthesis pass needs stronger evidence.
Pro supports 2 models, up to 3 rounds, and up to 4096 tokens per response. Team supports up to 4 models, up to 5 rounds, and up to 8192 tokens per response. Larger settings can produce better coverage, but they also increase provider cost and make the room harder to scan.
The selected template affects role assignment. For example, an architecture-decision debate can assign proposer and challenger roles, while a security-audit debate can assign defender and attacker roles. These roles are prompts, not guarantees; review the output before adopting it.
Cost Responsibility¶
Provider token charges belong to the account that owns the API key. Before starting a long debate, check the selected models, max tokens, and rounds. A Team debate with several high-cost models and long responses can spend more than a short Pro debate with compact models.
SynContext may estimate or display usage when provider responses include enough metadata, but provider billing remains authoritative. For budget control, choose lower-cost models, reduce max tokens, reduce rounds, and avoid unnecessary synthesis calls.
Safety and Data Handling¶
Do not put secrets, private keys, access tokens, regulated personal data, or production-only credentials into an Autopilot topic. The models you choose will receive the prompt and project context needed for the debate. Treat model selection as a data-sharing decision.
Custom provider URLs on Team are validated to reduce SSRF risk, but validation does not mean the provider is trusted. Use endpoints you control or providers you intentionally selected. Rotate a key at the provider if you suspect it was exposed outside SynContext.
Autopilot messages become War Room messages. Review them before resolving the room, especially for security, billing, legal, or infrastructure decisions.
Troubleshooting¶
If Autopilot is unavailable, check your plan. Free has 0 runs. Pro and Team can start runs within their monthly limits.
If saving a provider key fails on Pro, confirm the provider is anthropic or openai and leave base_url empty. Custom providers and custom base URLs require Team.
If a Team custom URL fails, use https:// for hosted remote endpoints and make sure the host passes SSRF validation. Localhost behavior is intended for local development.
If a run says no API key is saved for a provider, add that provider in Settings or change the debate configuration to a saved provider.
If a run rejects the model count, reduce the debate to 2 models on Pro or 4 models on Team.
If a run rejects rounds or tokens, use at most 3 rounds and 4096 tokens on Pro, or at most 5 rounds and 8192 tokens on Team.
If streaming stops, reopen the War Room and read the saved messages. Completed turns are persisted as they finish, so the room can show partial progress even after a client-side disconnect.
Reading the Results¶
Treat Autopilot output as a structured first pass. The most useful result is often not the final answer, but the disagreement pattern: which model found a risk, which assumption was challenged, and where synthesis changed the original proposal. Read the first round for independent positions, later rounds for convergence, and the final synthesis for actionability.
If a model response is weak, ask whether the prompt was too broad, the model was mismatched to the task, or the room lacked project context. Do not increase rounds automatically. A narrower prompt with two models can be better than a long debate that repeats vague claims.
For implementation work, convert the outcome into an execution-ready plan only after a human or trusted reviewer checks the assumptions. For security work, require concrete evidence and file-level references before accepting a recommendation.
Operational Checklist¶
Before starting: confirm the room is open, the topic is specific, the selected providers have saved keys, the model names are valid, and the run settings fit your plan limits. On Pro, keep the debate to 2 models, 3 rounds, and 4096 tokens per response or less. On Team, keep it to 4 models, 5 rounds, and 8192 tokens per response or less.
During the run: watch for provider errors, repeated answers, and cost updates. If the first round shows the wrong framing, cancel early instead of spending more tokens on a bad setup.
After the run: read the saved messages, post corrections if needed, and resolve the room only when the conclusion is clear enough to preserve.