I’d really like to see Teable’s AI harness support automatic model selection and escalation, while keeping the current manual model selection available.
Right now, I often keep the strongest model and highest reasoning level selected because I don’t always know which model is appropriate for a particular task. If I choose a weaker model and it turns out to be a difficult task, I have to manually figure that out and switch models. If I always use the strongest model, I end up spending more credits/tokens than necessary on simple tasks.
I think the harness could solve this with a lightweight decision/routing model.
The idea is not to use another expensive model to do the actual work. A small, fast decision model, such as Jev, Laya, or another suitable model, could make bounded decisions about the task and let the harness choose the appropriate model and reasoning level.
For example, everyday coding work can vary hugely in complexity:
- Fix a typo → lightweight model
- Rename a variable → lightweight model
- Add a field → lightweight model
- Update a test → lightweight model
- Implement a small endpoint → medium reasoning
- Add validation → medium reasoning
- Debug a failing test → potentially higher reasoning
- Modify complicated SQL → potentially higher reasoning
- Complex architecture or difficult debugging → stronger model
These don’t necessarily need to be predetermined rules. The decision model could evaluate the actual request and context and determine what is appropriate.
Automatic routing
In Auto mode, we should simply describe what we want. The harness could determine:
- How complex the task is
- Which model is likely sufficient
- Which reasoning level is appropriate
- Whether a task should be broken into smaller subtasks
- Whether different subtasks need different models
- Whether an attempt should be retried
- Whether the task should be escalated to a stronger model
For example:
User request
↓
Decision / Routing model
↓
Appropriate model + reasoning level
↓
Task execution
↓
Success?
↙ ↘
Yes No
↓ ↓
Done Retry / Escalate
↓
Stronger model
The important thing is that model selection should be dynamic, not necessarily decided only once at the beginning.
A task may initially look simple but become much more difficult after the agent starts working:
Luna Low
↓
unexpected complexity
↓
Luna Medium
↓
still failing
↓
Luna High
↓
still failing
↓
Stronger model
This would be much better than requiring us to recognize the problem and manually change models.
Minimum sufficient intelligence
The goal shouldn’t simply be “always use the cheapest model.”
The goal should be to use the least expensive/fastest model that is reasonably sufficient for the task, while escalating when the evidence suggests that more capable reasoning is needed.
Using a cheap model 5 times when a stronger model could have solved the problem once isn’t actually efficient.
So Auto mode should ideally balance:
- Cost
- Speed
- Capability
- Probability of successful completion
- Number of retries or escalations
Lightweight decision model
The decision layer itself should be extremely cheap and fast.
I recently came across an interesting approach using a small decision-focused model such as Jev (or open source, Laya). Instead of generating code or long explanations, the model makes bounded decisions such as:
- Is this task small, medium, or complex?
- Should we retry?
- Should we increase the reasoning level?
- Should we escalate to a stronger model?
- Is the current attempt sufficient?
That seems like a particularly good fit for an AI coding harness because these decisions don’t necessarily require the same expensive reasoning used to implement the task itself.
The decision model could effectively act as a small controller around the more expensive execution models.
Subtask-level routing
It would also be great if this worked at the subtask level, rather than selecting 1 model for an entire user request.
For example, a single request could contain repository exploration, a simple code change, a more complex implementation, and debugging.
The harness could determine that different parts of the work require different levels of capability.
We shouldn’t have to manually think, This part needs Luna Medium, this part needs Luna High, and maybe I should use Sol XHigh for that other part.
The harness should be able to make those decisions itself.
Automatic retry and escalation
If an attempt fails, Auto mode should be able to progressively escalate.
For example:
Initial attempt
↓
Failure
↓
Retry with same/similar capability
↓
Failure again
↓
Increase reasoning or move to stronger model
↓
Failure again
↓
Further escalation if appropriate
The escalation shouldn’t happen blindly after every failure. The decision layer could consider the type of failure, how many attempts have already happened, and whether the task has become more complex than originally expected.
A simple typo shouldn’t suddenly trigger the most expensive model just because something went wrong.
Manual mode must remain
I definitely don’t want Auto mode to replace manual model selection. There should be 2 modes:
Auto
Teable harness decides which model and reasoning level to use based on the task, and can retry/escalate when necessary.
Manual
The user (we) chooses the model and reasoning level, and the harness follows that choice as it does today.
I’d also love the ability to temporarily override “Auto” for a single task without changing the global setting.
For example: Use Sol XHigh for this task.
Then Auto mode can continue normally for subsequent tasks.
This gives us full control while making model selection invisible for us who don’t want to think about it.
Some visibility would be useful
Auto mode shouldn’t necessarily be a black box either.
It would be useful to see lightweight information about what the harness decided, without requiring us to approve every decision.
For example:
Auto routing: Luna Medium
Reason: moderate multi-file implementation
Attempts: 1
Escalation: none
Or, if escalation happens:
Luna Medium → failed
Luna High → retrying
We don’t need to intervene, but we can understand why a particular model was used and what happened. In this way, Teable allows us to learn much better about “working with AI” that would be success for all Teable users and love Teable more.
Model-agnostic implementation
I wouldn’t want this feature to be tightly coupled to Jev or Laya specifically.
Those are examples of the kind of lightweight decision model that could make this possible. The actual implementation can use whichever decision/routing approach Teable finds most reliable.
The important part is having a model-agnostic orchestration layer that can intelligently decide which available model and reasoning level should handle each piece of work.
As the available models change, the routing system could evolve without us having to constantly learn the capabilities and pricing of every new model.
Why I think this would be valuable
The number of models and reasoning levels available to us is growing quickly, but that also creates a new problem: model selection itself becomes a task.
As a user, I don’t want to spend time deciding:
“Should I use GPT-6 Astra Medium, Astra High, Sol High, or Sol XHigh for this?”
I want to say:
“Implement this.”
And have the harness figure out how much intelligence is actually necessary.
This could reduce unnecessary credit/token usage while also making the AI harness easier to use and potentially more reliable.
Most importantly, it would let us benefit from having many different models without requiring them to become experts in the differences between those models.
In short: give us an Auto mode where Teable’s harness decides the appropriate model and reasoning level per task/subtask, retries when appropriate, progressively escalates when necessary, and keeps Manual mode for us who want full control.
I think this would be a really valuable evolution of the AI harness.