# Addressing a slot as a model

**URL:** <https://forum.hal0.dev/t/addressing-a-slot-as-a-model/48>\
**Category:** Reference\
**Created:** [August 22, 2026, 6:50am UTC](https://forum.hal0.dev/t/addressing-a-slot-as-a-model/48 "2026-08-22T06:50:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://forum.hal0.dev/user_avatar/forum.hal0.dev/system/32/37_2.png) [@system](https://forum.hal0.dev/u/system)\
**Post date:** [August 22, 2026, 6:50am UTC](https://forum.hal0.dev/t/addressing-a-slot-as-a-model/48/1 "2026-08-22T06:50:13Z")

</div>

hal0’s dispatcher resolves the `model` field of an OpenAI-compatible request primarily  
by **model id** , not by slot name — see the Model → slot resolution  
section of [OpenAI-compatible API](https://forum.hal0.dev/t/openai-compatible-api-reference/46)  
for the full 5-step resolution order. Direct slot-name addressing exists, but only as  
the last-resort fallback in that chain (`SLOT_ALIASES` direct lookup) — described in  
source as “operator muscle memory,” for requesting a slot literally by name.

## Chat-slot aliases

For `/v1/chat/completions` specifically, the route layer recognizes a small set of  
aliases in the `model` field and rewrites them to the aliased slot’s configured model  
id before dispatch even reaches the general resolver:

| Alias | Resolves to |
| --- | --- |
| `agent` | The configured default chat slot. |
| `utility` | The configured utility slot. |
| any enabled LLM slot name | That slot’s configured model. |

`hal0/*`-prefixed virtual model names are resolved separately, against live slot state,  
and set a “lane pin” recording which specific slot the caller meant — relevant when  
more than one slot serves the same underlying model id.

## Omitting `model` entirely

If a request omits `model`, the request **path** decides the default, not a global  
fallback model:

| Path | Default target |
| --- | --- |
| `/embeddings` | `embed` capability slot |
| `/rerank`, `/rerankings` | `rerank` capability slot |
| `/audio/speech` | `tts` capability slot |
| `/images/*` | `img` capability slot |
| everything else | `agent` |

> [@](#):
>
> **Note**
> 
> The default for chat-shaped requests changed from `chat` to `agent` (ADR-0023) —  
> if you’re carrying forward assumptions from pre-1.0 docs or muscle memory, update any  
> reference to a `chat` default.

## Capability-based routing fallback

When neither an alias nor an exact model-id match resolves, the dispatcher falls back  
to capability inference from the request path and model-name hints, in this order:

1. Path fragment → capability slot type (`/embeddings` → `embed`, `/rerankings`/`/rerank`  
→ `rerank`, `/audio/speech` → `tts`, `/images/generations`/`/images/edits`/  
`/images/variations` → `img` — note the last two paths aren’t actually implemented  
endpoints, but their strings are still recognized here as routing hints).
2. Model-name substring hints (`embed`, `rerank`).
3. Direct `SLOT_ALIASES` lookup — the slot-name-as-model fallback.

See [Providers, profiles & devices](https://forum.hal0.dev/t/providers-profiles-devices-reference/57) for  
how a slot’s `device`/`provider` fields relate to which capability it can serve, and  
[Slot lifecycle](https://forum.hal0.dev/t/slot-lifecycle-reference/58) for the states a slot must be in  
(`READY`, `SERVING`, or `IDLE`) to be dispatchable at all.