orchestration + memory for your business
300+ models.
One orchestrator.
Build your own model orchestration with memory on supported paths. Route tasks, run specialists together, and bring relevant context into your agents and connected apps.
new model. same context.Explore the workflows. No account needed.
hi, I’m theo.I choose and connect the models for the work.
Big model energy.The names you know. The choice is yours.
OpenAI
Claude
Gemini
DeepSeek
theo Arca
Grok
Kimi
Qwen
Meta
Mistral
theo Moonlight
GLM
MiniMax
NVIDIA
Kling
Runway
FLUX
PikaBrands in the directory, not a guarantee of account availability or local installation. No partnership or endorsement implied.
01 why an orchestrator, not just a model
The right model.
Or the right team of models.
theo brings models, tools, skills, and supported memory paths together. You choose how the work runs and which context belongs.
Spend where it counts.
Route routine requests to efficient models. Reserve deeper reasoning for difficult work, then compare cost and quality.
Put models to work together.
Run independent specialists in parallel. Combine their findings, or pass one model's output to the next step.
Keep what your team knows.
Skills define the job. Supported memory paths can bring relevant facts, decisions, and preferences into the next request.
Handle 10,000 support requests without sending every one to the most expensive model.
Use an efficient model for routine work. Reserve deeper reasoning for the cases that actually need it.
See the sample inputs & context
Fictional monthly workload: 8,000 policy lookups and 2,000 disputes needing order history and policy interpretation.
Sample setup: approved policy excerpts, a permitted order lookup, and rules that separate routine questions from disputes. Missing evidence goes to a person.
01 / REQUEST
Where can I find our returns policy?
support-policy skill02 / ORCHESTRATOR
Classify the request. Choose one eligible path.
intent + your rules03 / EXAMPLE MODEL CHOICES
04 / RESULT
Return the relevant approved policy excerpt and its source.
record the route + usageRecall the relevant support preferences and unresolved questions on the next request, within the same owner’s scope.
MCIR’s full intent pipeline and Memory Chain require separate activation.Where can I find our returns policy?
Return the relevant approved policy excerpt and its source.
Routine lookup. An efficient text model answers from the approved policy.
A cost-aware routing blueprint
illustrativeModel spend follows task complexity, while the same company rules travel with every request.
Support routing: match the model to the workRead the complete example output
ROUTE PLAN 8,000 routine lookups → efficient text model + support-policy skill. 2,000 complex disputes → reasoning model + permitted order lookup. Missing evidence → ask for clarification or a human review. MEASURE BEFORE ROLLOUT Compare cost per resolved request, answer quality, and response time against the single-model baseline. Set spending caps and inspect exceptions.
The workload is fictional. No savings are measured or guaranteed; total cost depends on model rates, context, retries, and applicable fees.
Prepared workflow blueprints with fictional information. No AI call, business connection, or message is made here.
Build the connections in the workflow editor.Advanced preview: choose capabilities, connect context and tools, then inspect a run.
This separate sandbox includes healthcare, company, and coding recipes. Edit the graph and inspect its trace. It uses deterministic fixtures, not live model calls or a parallel-performance benchmark.
Orchestrator / interactive preview
Local fixtures onlyCompleted default example. Change a setting, or Run to follow its trace.
Connected graph
6 nodes / 6 linksRouter · Otherwise
Drag a card to move it. Pick its model inline, or open Configure for more. Connect the square ports. Non-drag controls are below.
Nodes & connections · no dragging needed
- n1 to n2e1 · Continue
- n2 to n3e2 · Continue
- n3 to n5e3 · Recipe source missing
- n3 to n4e4 · Otherwise
- n4 to n6e5 · Continue
- n5 to n6e6 · Continue
Output is a demo-only endpoint for the application handoff, not a node in the current product editor. Human review happens in your application.
Build & connect
Add a node, then connect it into a complete Entry → Model → Output path. Removing a node also removes its links. Incomplete graphs stop; they never switch to an unwired model.
Bounded demo: up to 16 nodes and 32 connections.
Edit existing connections
Conditional branches are checked in the order shown. Otherwise runs only if none match.
Skills for your modelsadd your know-how
Skills
Build your own skillReusable instructions attached to a model, not extra routing nodes. Toggle a sample skill, then run to see what changes.
Request fixtures & settingssources · permissions · test input
Trace & outputInspect the authored result
Trace & output
Event trace
14 revealed- 01Graph validated
Node types, connections, cycles, and configuration checked locally.
- 02Synthetic request selected
Prepare a cover note for a fictional prior-authorization packet.
- 03Router · Otherwise
Selected e4: n3 → n4. No condition matched; this explicit Otherwise branch applies. This uses fixture values, not live classification.
- 04Demo input boundary · passed
This bound fixture check passed during preflight. It is not a safety evaluation of a real request.
- 05n1 → n2
Follow e1 · Continue.
- 06n2 → n3
Follow e2 · Continue.
- 07n3 → n4
Follow e4 · Otherwise.
- 08Synthetic source fixtures read
Sample packet checklist; Fictional supporting summary. Only these bounded fixtures are available.
- 09Demo skill · Cite fixture sources
Add the titles of the synthetic sources actually read. Attached only to n4; not a separate graph node.
- 10Demo skill · Add a review checklist
Append an authored handoff checklist, not a review decision. Attached only to n4; not a separate graph node.
- 11theo-1-reason · illustrative response
An authored draft with open questions. No inference or capability benchmark is performed.
- 12Mock result · Check sample packet
Mock inventory: cover-note slot available; attachment slot available. Nothing submitted.
- 13n4 → n6
Follow e5 · Continue.
- 14Illustrative draft
The connected path produced an illustrative draft. A person still reviews it in the application.
Route selection → path-aware preflight → mock work. No timestamps or invented execution metrics.
Illustrative draft
n4 · theo-1-reasonCover-note draft: the fictional packet includes the supporting section requested by the sample checklist. List unresolved items for a person to check.
A qualified person must verify the real documents and decide what to submit. No clinical or coverage decision is made here.
Read the full authored output
Open question: what must the application reviewer verify before this draft is used?
Fixture references: Sample packet checklist; Fictional supporting summary.
Review checklist: verify the source, resolve missing items, and decide in your application.
Mock inventory: cover-note slot available; attachment slot available. Nothing submitted.
Sources & mock activity
Current source attachments
- Sample packet checklistRead in the revealed trace
- Fictional supporting summaryRead in the revealed trace
Revealed mock tool activity
- Mock result · Check sample packetMock inventory: cover-note slot available; attachment slot available. Nothing submitted.
Playback reveals a deterministic trace, not real processing time. Reset clears playback, not your configuration.
JSON demo recipe v1 · not production-importable.
A working local simulation, not a live AI request. Everything uses bounded synthetic fixtures. No API key, uploads, patient records, external tools, or generated performance figures.
What this example does and does not represent
The connections determine the path and result. The demo uses Entry, Classifier, Router, Model, Guardrail, Description, and a demo-only Output endpoint. The current product editor does not use Output nodes. Context, mock tools, and demo skills are attachments, not additional production node types or E.V.I. Canvas skill nodes.
Gateway Guardrails are opt-in and bound per API key. The demo distinguishes absent, disabled, and unbound checkpoints from active fixture checks. Its source requirement and mock tool permissions illustrate application rules; they are not claims about built-in Gateway protections.
The simulator resolves the selected path, checks its input policies and permissions before mock work, then reveals authored events. Branch conditions and model wording are deliberately simplified. This is not live inference, a security evaluator, or proof of production equivalence. Production graph and chain capabilities depend on configuration.
Human review belongs in your application. The exported JSON is a versioned demo recipe, not production-importable. Nothing is saved to browser storage.
These examples show the idea, not a live AI run. The editor uses fixed sample data; exported recipes are for the demo, not production import.
open the real playground02 what memory brings to the work
Not everything remembered.
The right context, returned.
MCIR means Memory Context & Intent Response. Understand the task, select relevant history, and prepare a useful handoff to the model.
- Memory
- What should carry forward?
- Context
- What matters for this task?
- Intent
- What are you trying to do?
- Response
- What can we usefully return?
Start with the task, not the archive.
Resolve what you want to do, which work you mean, and when it happened.
“Resume last week’s release draft.”
- Action
- Resume
- Time
- Last week
- Prior work
- Release brief
Understand. Resume the draft. 3 selected records. Theo Flash.
Fictional records. No model calls or account changes.
Read the complete memory walkthrough
An authored MCIR walkthrough. Fictional records, no live inference, and no account memory changed. Source selection is authored, not a production scoring or contradiction-detection simulation.
- Understand. Resolve what you want to do, which work you mean, and when it happened.
- Recall. Inspect the selected sources and the reason each belongs in this example.
- Assemble. The request and selected context travel together to a qualified model route.
- Respond. A remembered requirement is not proof that the requirement was met.
Resume the draft
Request: Resume last week’s release draft.
Three relevant records in one fictional workspace. The older plan stays out.
Selected sources: draft-014, preference-006, decision-012.
Release brief: draft The retry test is pending and the rollback review remains open. [draft-014] Keep the release in draft until a reviewer signs off. [decision-012] Open question: who will confirm both checks?
Add a new instruction
Request: Resume last week’s release draft. This time, write one paragraph.
The current instruction asks for a paragraph, so this authored example does not apply the older formatting preference.
Selected sources: draft-014, decision-012.
The release is still a draft: the retry test is pending and the rollback review is open. [draft-014] A reviewer’s sign-off is required before approval. [decision-012] Confirm the checks before changing that status.
Try missing context
Request: Resume the release draft from a different project.
None of these records establishes which draft you mean. A source from the wrong project is not a useful substitute.
Selected sources: none.
Which project and release draft should I use? Provide an authorized source or clarify the request before I continue.
Inspect the source records
Last week’s release brief · draft-014 · 2026-09-18. The release brief lists a pending retry test and an open rollback review. This is the earlier artifact the request wants to resume.
How the team writes · preference-006 · 2026-09-17. Use a short summary, then separate confirmed facts from open questions. It shapes the brief’s format, not whether the release is ready.
The review requirement · decision-012 · 2026-09-18. A reviewer must sign off before the release is approved. It preserves a relevant constraint. It does not prove anyone signed off.
An earlier release plan · note-009 · 2026-09-10. An earlier plan proposed releasing before the review meeting. The example leaves this out because a later source requires review. Real conflicts still need validation.
Both illustrated model routes receive the same selected context. The response is authored and does not compare model quality.
Memory is built into supported theo request paths. The full MCIR intent pipeline and Memory Chain have separate activation requirements; confirm availability for your account.
how it differs from a memory layer03 different roles. bigger possibilities.
Not another chatbot.
A better way to run AI.
Smarter routing. Specialists working together. Company skills and supported memory paths that give the next task a useful starting point.
Make the whole operation smarter.
Control model spend, combine specialist analysis, and put your company's knowledge to work.
01Operations & finance
Stop paying premium rates for every request.
Use an efficient model for routine work. Reserve deeper reasoning for the cases that actually need it.
- Routine lookupDeepSeek V4 Flash
- Complex disputeGPT-6 Astra
- Missing evidenceYour support team
Illustrative model lineup. Check account availability.
Routine work stays on the efficient route. Complex cases get more reasoning. Measure the difference, not a promised discount.
Read the workflow blueprint
Your request mixFictional monthly workload: 8,000 policy lookups and 2,000 disputes needing order history and policy interpretation.
Your support-policy skillSample setup: approved policy excerpts, a permitted order lookup, and rules that separate routine questions from disputes. Missing evidence goes to a person.
Route by requestClassify the request + load the relevant policy
- Routine lookupAn efficient text model answers from the approved policy.
- Complex disputeA reasoning model compares the policy with permitted order history.
- Missing evidenceAsk for the missing information or hand off to the team.
Return the result + record the route and usage. Choose one path for each request, rather than paying every model to answer it.
Support routing: match the model to the work
ROUTE PLAN 8,000 routine lookups → efficient text model + support-policy skill. 2,000 complex disputes → reasoning model + permitted order lookup. Missing evidence → ask for clarification or a human review. MEASURE BEFORE ROLLOUT Compare cost per resolved request, answer quality, and response time against the single-model baseline. Set spending caps and inspect exceptions.
The workload is fictional. No savings are measured or guaranteed; total cost depends on model rates, context, retries, and applicable fees.
02Procurement & leadership
Put several specialists on one decision.
Review commercial terms, security evidence, and operational fit at the same time. Bring the findings back together.
- Commercial reviewGPT-6 Astra
- Risk reviewClaude Fable 5.1
- Technical reviewKimi K3
Illustrative model lineup. Check account availability.
One comparison, three perspectives. Missing evidence and conflicting findings stay visible alongside the recommendation.
Read the workflow blueprint
Two fictional proposalsNorthstar: $48,000 per year with a usage cap. Cedar: $54,000 with uncapped support. Neither proposal includes a current assurance report or an SSO test.
Your purchasing criteriaSample criteria: compare total cost, inspect security evidence, and verify SSO compatibility. Flag missing terms; procurement owns the decision.
Work in parallelShare the permitted proposals + purchasing criteria
- Commercial modelCompare prices, caps, and terms that could change total cost.
- Risk modelCheck supplied security evidence against the company's requirements.
- Technical modelAssess integration fit and identify the tests still needed.
Synthesize findings, sources, and disagreements. Run independent model calls together, then combine their findings. Configure concurrency and usage limits.
Supplier review: cost, risk, and technical fit
COMMERCIAL Northstar has the lower quoted price, but its usage cap needs clarification. Cedar quotes uncapped support, not unlimited product usage. RISK + TECHNICAL FIT Both are missing an assurance report and an SSO test. Neither is ready for approval from the supplied evidence. NEXT STEP Request the missing evidence and capped-usage terms. Reconcile the specialist findings before procurement chooses a supplier.
Fictional proposals and authored findings. No purchasing decision is made. More models do not guarantee a correct recommendation.
03Sales & solutions
Make your expertise reusable, not copy-pasted.
Give an RFP workflow your approved product facts, evidence, and response rules once. Reuse that skill on the next request.
- Approved knowledge
- Company instructions
- Permitted tools
GPT-6 AstraIllustrative context and model. Check account availability.
Approved answers carry their sources. Missing facts become questions for the owner, not confident inventions.
Read the workflow blueprint
The prospect's questionsFictional RFP: Is SSO supported? How long is activity data retained? Can all data stay in the EU?
Your RFP-response skillSample knowledge: Product Guide v4 lists SSO on the Business plan. Data Policy v2 says activity data is retained for 30 days. No regional-hosting commitment is supplied.
Bring your knowledgeLoad the RFP-response skill for the request
- Approved knowledgeRetrieve the relevant product and policy excerpts with their versions.
- Company instructionsCite evidence, preserve plan limits, and leave unknown claims unanswered.
- Permitted toolsUse a read-only source lookup, not permission to make new commitments.
Route the task with the skill's context attached. Load instructions, reference data, and permitted tools as context. This is not model fine-tuning.
RFP response: approved facts and open questions
SSO Available on the Business plan. [Product Guide v4] ACTIVITY DATA Retained for 30 days. [Data Policy v2] EU-ONLY HOSTING Not established by the supplied sources. Ask the infrastructure owner before making a commitment. REUSE Keep the approved knowledge and response rules in the RFP-response skill. Refresh the sources when the product or policy changes.
Fictional product facts, not claims about theo. No proposal is sent. A knowledge-backed skill does not retrain model weights.
Build beyond a single-model API.
Change the route without rebuilding your app. Run independent calls together. Reuse skills across requests.
01Application engineering
One API. A different route for each request.
Stop hardcoding every feature to one model. Let request intent and your routing rules choose the appropriate engine.
- Routine → fastDeepSeek V4 Flash
- Reasoning → thinkGPT-6 Astra
- Implementation → codeClaude Fable 5.1
Illustrative model lineup. Check account availability.
A new prompt can take a different route without a new provider integration or a rewrite of the calling feature.
Read the workflow blueprint
Three requests to the same APIFictional app prompts: explain a plan limit; compare two system designs; fix the checkout retry logic.
Your routing configurationSample setup: mode auto, per-key domain rules, and a service-review skill for relevant engineering requests. Inspect resolved_mode and usage in each response.
Route by requestOne API request → classify intent + apply your rules
- Routine question → fastUse an efficient engine for the plan-limit explanation.
- Design trade-off → thinkUse a reasoning engine to compare the two architectures.
- Implementation → codeUse a coding engine with the service's permitted context.
Return content, resolved mode, and usage to your app. Choose one path for each request, rather than paying every model to answer it.
One integration, three request routes
SAME ENDPOINT, DIFFERENT WORK Plan-limit question → fast. Architecture comparison → think. Retry implementation → code. INTEGRATION Send mode auto, attach the relevant skills, and configure domain rules on the key. Read resolved_mode, model, and usage from the response. VERIFY Replay representative prompts and near misses before rollout. These are illustrative routes, not captured API results.
No API request runs here. Available engines depend on your configuration. Auto routing selects an engine; it does not call 300 models at once.
02Platform & development
Review a change from more than one angle.
Give correctness, security, and test-design specialists independent passes, then reconcile what they found.
- Correctness passClaude Fable 5.1
- Security passGPT-6 Astra
- Test-design passKimi K2.7 Code
Illustrative model lineup. Check account availability.
Three independent passes, one reconciled brief. Missing context and disagreements are part of the result.
Read the workflow blueprint
A fictional change setThe sample patch adds retries to create_order. No idempotency token, authorization changes, or retry tests are shown in the supplied diff.
Your engineering review rulesSample rules: use the diff and approved service spec, identify the evidence for each finding, distinguish missing context from a proven defect, and never merge or deploy.
Work in parallelSend the permitted diff to independent model calls
- Correctness modelInspect retry behavior and duplicate-order failure modes.
- Security modelCheck the shown trust boundaries and flag missing authorization context.
- Test-design modelPropose failure, timeout, and replay tests for this change.
Combine findings + preserve conflicts for a maintainer. Run independent model calls together, then combine their findings. Configure concurrency and usage limits.
Parallel review: checkout retry change
CORRECTNESS Potential duplicate orders after a retry. Check whether create_order already enforces idempotency; it is not shown in the diff. SECURITY Authorization behavior is not visible. Do not infer that it is missing or safe. TESTS Add timeout-after-success, repeated-request, and rejected-request cases. SYNTHESIS Resolve the missing service context, then have a maintainer evaluate the findings and run the tests.
No code is executed, merged, or deployed. Configure bounded parallel calls in your workflow or application; each call contributes to usage.
03AI & product engineering
Build a specialist that knows your system.
Package architecture decisions, runbooks, instructions, and read-only tools into a skill your app can activate by name.
- Reference knowledge
- Domain instructions
- Scoped tools
Claude Fable 5.1Illustrative context and model. Check account availability.
Your architecture and runbooks arrive with the request, even when a different engine handles the next task.
Read the workflow blueprint
A service changeFictional checkout proposal: retry failed requests three times. The proposal does not distinguish transient failures from rejected requests.
Your service-review skillSample package: ADR-04 requires stable idempotency keys; Runbook v2 excludes rejected requests from retries. A permitted lookup can read the current service spec.
Bring your knowledgeActivate skills: [service-review]
- Reference knowledgeBring ADR-04, Runbook v2, and the approved service specification.
- Domain instructionsApply the team's retry policy, cite the source, and flag uncertainty.
- Scoped toolsAllow the service-spec lookup. Do not grant deployment access.
Give the routed model the skill's context and tools. Load instructions, reference data, and permitted tools as context. This is not model fine-tuning.
Service-review skill: retry strategy
APPLY THE COMPANY'S RULES Keep one stable idempotency key across attempts. [ADR-04] Do not retry rejected requests. [Runbook v2] STILL NEEDED Define the transient-error list and retry budget from the current service spec. Verify the proposed change against tests. REUSE Activate service-review on relevant API requests. Keep knowledge revisions and tool permissions current as the service changes.
No skill is installed here. Build and authorize the package first. This supplies context and tools, not model fine-tuning or automatic production access.
Illustrative workflow designs, not customer results or measured savings.Keep a workflow blueprint
Connect your EHR. Give theo a skill.
Your team builds the connection. Skills define the task; MCIR carries relevant, permitted context. Your people review the draft. Three fictional examples, no live connection.
explore healthcare workflows04 / THE AI BEHIND THE WORK
Choose your AI.
Keep your options open.
Different models. Relevant history on supported memory paths. Meet our models and compare published evidence. This snapshot is separate from theo’s full routing ecosystem, not your account’s callable-model list.
Our own models. Ready to use.
Live in the products shown below.
Being available is different from having a benchmark score.
TextTheoArca Magnus 5.1
Theo's own deep-reasoning engine, governed and audited.
Context window1,000,000 tokensPublisher-reported · Sep 3, 2026
The whole conversation, documents included, in one request. This is not an independent benchmark.
TextTheoArca Velox 5.1
Theo's own low-latency engine, governed and audited.
Context window1,000,000 tokensPublisher-reported · Sep 3, 2026
The whole conversation, documents included, in one request. This is not an independent benchmark.
ImageTheo Moonlight 1.1
High fidelity image renders on our own hardware.
Render time33 secondsPublisher-reported · Sep 15, 2026
A 1024 by 1024 image at the default quality setting. This is not an independent benchmark.
3D captureTheo Real World 1.1
Photos of a real thing become a 3D capture of the thing in its space.
Quick capture127 secondsPublisher-reported · Sep 21, 2026
From submit, on a 9 second walk-around clip; 40 camera positions solved from 120 candidate frames. This is not an independent benchmark.
A little less hype.
A lot more evidence.
Score snapshot Catalog checked . Not a live availability list.
1–8 of 169 models
Ranked models first. Overlapping bands are ties.Swipe or scroll the table to see scores, evidence, and sources.
| Overall rank | Model | Overall Index | Index grade | Coverage & evidence | Source |
|---|---|---|---|---|---|
| 1band 1–1 | GPT-6 AstraOpenAI · Text | 99.0band 99.0–99.7 | A+ | Independent / public boards14 comparable tests · 3 counting categoriesEpoch 5 · boards 9 | Source |
| 2band 2–2 | Claude Fable 5.1Anthropic · Text | 97.0band 96.6–97.8 | A+ | Independent / public boards17 comparable tests · 3 counting categoriesEpoch 4 · boards 13 | Source |
| 3band 3–4 | Claude Fable 5Anthropic · Text | 92.7band 91.9–95.6 | A | Independent / public boards19 comparable tests · 3 counting categoriesEpoch 5 · boards 14 | Source |
| 4band 3–4 | Claude Opus 5Anthropic · Text | 92.6band 91.7–94.3 | A | Independent / public boards20 comparable tests · 3 counting categoriesEpoch 5 · boards 15 | Source |
| 5band 5–5 | GPT-5.6 SolOpenAI · Text | 89.8band 88.7–92.4 | A- | Independent / public boards20 comparable tests · 3 counting categoriesEpoch 5 · boards 15 | Source |
| 6band 6–6 | GPT-5.6 TerraOpenAI · Text | 81.9band 80.2–85.3 | B+ | Independent / public boards18 comparable tests · 3 counting categoriesEpoch 5 · boards 13 | Source |
| 7band 6–9 | GPT-5.5OpenAI · Text | 80.2band 78.8–82.8 | B+ | Independent / public boards22 comparable tests · 4 counting categoriesEpoch 5 · boards 17 | Source |
| 8band 6–10 | Kimi K3Moonshot AI · Text Open weights | 79.6band 77.2–83.5 | B | Independent / public boards18 comparable tests · 3 counting categoriesEpoch 5 · boards 13 | Source |
How to read the rankings, sources, and availability
A relative Index, not an accuracy percentage. OpenCharts balances performance across counting categories, relative to the published frontier. An overall rank needs at least six comparable tests across three counting categories. Provisional scores do not meet that threshold. Missing scores stay missing.
Read the bands, not just the position. Overlapping rank bands should be treated as ties. Changing the category or hard-set sort never changes a model’s published overall rank. Category means with limited coverage are labelled; the hard-set score requires at least four covered tests.
Different evidence stays different. Epoch runs, public leaderboards, developer reports, and internal evaluations are counted separately. A developer report is not an independent evaluation. First-party observations above are publisher-reported. Image, video, voice, presenter, and 3D capture entries are not assigned a text-model Index.
A directory is not an availability API. A listing, logo, or open-weight flag does not guarantee hitheo access, a public API, or local compatibility. Check the source, your account, hardware requirements, and the model’s license before use.
Product availability has its own source. The first-party live labels reflect a product team confirmation on . They name the product where each model is live. Benchmark scores, publisher measurements, and public-API distribution remain separate records from OpenCharts.
Benchmark snapshot: . Internal evaluation snapshot: . First-party feed checked: . Media names reviewed: .
Aggregates reproduced from OpenCharts. Underlying score sources include Epoch AI and Arena, licensed CC BY 4.0. This is a reduced, regrouped projection; published scores and rank bands are unchanged. The source records retain test-level attribution and conditions.
Try routing and local setupCapability examples, separate from the comparison catalog.
Choose a capability and make it part of your orchestrator.
Start with auto. Supported memory paths can bring relevant context to the chosen route.
Install compatible local models. Review the choice before downloading.
Find your kind of intelligence.
6 examples to get you started
Explore all preview capabilitiesPublic theo capabilities and local setup examples, not a live account inventory. Cloud models are not automatically available to run locally.
05 make it work your way
Your expertise.
A reusable skill.
Skills define how to work. Supported memory paths can bring prior context. Package your instructions, knowledge, and permitted tools, then reuse them in your workflows, agents, and connected applications.
Memory stays within its owner’s scope. Skills do not grant new access or require retraining the underlying model.
meet the skill system- 01Define the domain or workflow
- 02Add approved documents and examples
- 03Set instructions, model preferences, and permissions
- 04Test with representative synthetic requests
- 05Reuse it across your app and workflows
Your architecture.
Built into the review.
A specialist that works from your service’s design decisions and operating rules, not just general coding knowledge.
- Instructions
- Apply retry rules. Cite the source. Flag missing context.
- Knowledge
- Architecture decisions + the current runbook
- Tools & access
- Read the permitted service spec. No deployment access.
MCIR memory
Relevant history can join supported requests without a separate memory API. Full intent-driven assembly and Memory Chain have activation requirements.
see how memory carries forwardRouting Studio
Teach the router your domain. Use per-key rules and examples to send different requests to the appropriate mode.
shape your routing rulesGuardrails
Add checks around what goes in and what comes back. These need to be configured and enabled for your workflow.
set up your checks06 from a first idea to a real integration
Build it your way.
Understand every connection.
Start with a task for your coding assistant, or take the server-side controls. Both paths build the same release assistant, one useful capability at a time.
Describe the idea. See how the pieces connect.
Turn release notes into a useful draft.
Start with one small feature, not a collection of model integrations.
- Fictional release notesNotesRetry test pending · review open
- theo · auto routetheoEligible capability + configured context
- A draft for reviewDraftNo release approval or deployment
How the pieces connect
Your coding assistant can help propose the connections. This drawing does not create an orchestrator or apply account configuration.
Draft: the retry test is pending and rollback review remains open.
Get the task prompt
Help me build a release assistant. It should turn approved notes into a draft, leave missing checks visible, and never approve or deploy a release. Show me the proposed route before changing any configuration.
Connect the documented MCP server in your own editor. Configuration-changing tools need the appropriate scope and your approval; nothing is connected here.
Build with AI. First useful result. Basic route.
Fictional example. No live requests or configuration changes. Switching paths keeps your place.
Read both paths without the interactive controls
Fictional inputs and authored outputs. No live inference, configuration changes, key collection, or persistent memory.
Build with AI · for vibe coders
Connect the MCP server using the documented setup, then ask your coding assistant to propose a workflow. Execution tools and configuration tools have different permissions. Review configuration changes before applying them.
First useful result: Help me build a release assistant. It should turn approved notes into a draft, leave missing checks visible, and never approve or deploy a release. Show me the proposed route before changing any configuration.
Illustrated result: Draft: the retry test is pending and rollback review remains open.
Add your expertise: Help me design a release-brief skill: concise summaries, approved release notes, and a read-only checklist lookup. Show the required tool handler and permissions. Do not install or change anything without my approval.
Illustrated result: Team brief: keep the known notes separate from open checks. Reviewer sign-off is still required.
Keep the context: Resume the release draft from last week. Use only the relevant context available to this owner, keep the open checks visible, and ask if a source is missing. Help me verify which memory features are enabled.
Illustrated result: Continued draft: the earlier review requirement still applies. Nothing records that the checks are complete.
Take control: Walk me through this release assistant’s routing, skill permissions, and bound policies. Show how to inspect the request ID and handle missing context or failed tools. Propose changes for review, but do not apply them.
Illustrated result: Before approval: confirm the retry test, rollback review, and reviewer sign-off.
Engineer the system · for advanced developers
Call the SDK or REST API from your server. Add a created, authorized skill through skills[]. Check supported memory paths; do not invent a memory flag. Inspect request_id, resolved_mode, and tool activity, then test failures before deployment.
import { Theo } from "@hitheo/sdk";
// Server-side only. Supply the value through your secret store.
const apiKey = process.env.THEO_API_KEY;
if (!apiKey) {
throw new Error("Set THEO_API_KEY in the server environment.");
}
const theo = new Theo({
apiKey,
timeoutMs: 30_000,
maxRetries: 2,
});
const response = await theo.complete({
prompt: "Prepare a release brief from these fictional notes: the retry test is pending and rollback review is still open.",
mode: "auto",
});
console.log(response.content);The same request over REST
curl https://www.hitheo.ai/api/v1/completions \
-H "Authorization: Bearer $THEO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Prepare a release brief from these fictional notes: the retry test is pending and rollback review is still open.",
"mode": "auto"
}'MCP setup documentation (opens in a new tab) · Completion API documentation (opens in a new tab)
Both paths stay visible. Switch between them without losing your place; no account or API key is needed for this example.
explore the developer field guide07 the thinking underneath
The interesting part
is also the careful part.
MCIR describes intent-driven context preparation. Arca defines a separate, scoped protected execution path. Explore how the layers work and what their evidence supports.
08 a simple pricing proposal
Pay for the work.
Keep the arithmetic clear.
The proposal: applicable usage plus a 5% orchestration fee, without a monthly subscription. Try an amount and see where every dollar goes.
Proposed pricing · billing alignment pending.
see pricing details and FAQWhat if my usage were…
Up to $100,000,000.00. Commas group thousands; a period separates cents.
Or try an example amount
applicable usage + 5% proposed fee = illustrative total
Browser-only arithmetic. Nothing is stored or sent.
The fee is rounded to the nearest cent in this illustration. This does not model taxes, account terms, or individual capability rates.
5%
for bringing the pieces together.- example applicable usage
- $100.00
- 5% proposed orchestration fee
- $5.00
- illustrative total
- $105.00
USD example. Not a live quote.
before you build
More possibilities.
Clearer choices.
How the models, costs, and company context fit together.
understand your data boundariesWhat does an orchestrator add beyond a model API?
theo coordinates routing, skills, tools, and built-in MCIR memory. Choose a model for each task or configure specialists to work together. Relevant company context can carry into the next session, agent, or connected app without rebuilding the memory layer yourself.
How does memory stay consistent when models or apps change?
MCIR means Memory Context & Intent Response. On supported paths, relevant owner-scoped history can join the request independently of the selected model. The full intent pipeline and Memory Chain have separate activation requirements. Different models can still answer differently; memory does not grant access to another tenant or connect an application by itself.
How can routing reduce AI costs?
An efficient model can handle routine work while deeper reasoning is reserved for complex requests. Choose relevant skills, inspect usage, and set spending caps. Compare quality and total cost against your existing approach; savings depend on the workload, models, context, retries, and applicable fees.
Can several models work at the same time?
Yes. Design independent calls to run in parallel, then combine or compare their outputs. A review might use separate correctness, security, and test-design passes. Parallel execution needs configured concurrency and usage limits, and each call adds cost. Tasks that depend on earlier results still run in sequence.
Does 300+ models mean every request uses all of them?
No. That describes the model ecosystem behind theo's engines. Auto routing selects an appropriate engine; a multi-model workflow calls the models you configure. Access and concurrency depend on availability and service limits. The sourced comparison catalog above is a separate benchmark snapshot, not the complete callable model registry.
Is a custom skill the same as training a model?
No. A skill packages domain instructions, knowledge files, model preferences, and permitted tools. It gives the selected model relevant company context at request time. You can create specialized behavior without retraining model weights. Keep the reference data current and test the resulting behavior.
Can a company start without writing code?
Use the visual builder to assemble model, knowledge, and tool steps. Engineers can use the API and SDK for custom applications. Connecting business systems, configuring access, and deploying a workflow still require an owner who can verify the integration.
Are the workflows on this page live?
No. These are authored blueprints using fictional information. The advanced editor is a separate simulation, with no model calls or business connections. Keep real customer and patient information out of this public preview. Open the real playground when you are ready to test a configured workflow.