---
url: 'https://adk.nht.io/api/@nhtio/adk/type-aliases/TokenEncodingId.md'
description: >-
  A recognised token-encoding identifier: one of the closed {@link
  TokenEncoding} built-ins, OR any other string registered via {@link
  registerTokenEstimator}.
---

# Type Alias: TokenEncodingId

```ts
type TokenEncodingId = TokenEncoding | (string & {});
```

Defined in: [src/lib/classes/tokenizable.ts:93](https://github.com/NHTIO/ADK/blob/v1.20260713.1/src/src/lib/classes/tokenizable.ts#L93)

A recognised token-encoding identifier: one of the closed [TokenEncoding](../common/variables/TokenEncoding.md) built-ins, OR any
other string registered via [registerTokenEstimator](../functions/registerTokenEstimator.md).

## Remarks

The `(string & {})` half of the union is a widening trick, not a real intersection — `string & {}`
has no members beyond `string`, so it accepts any string value while `TokenEncoding` still
contributes its literal members to editor autocomplete (a bare `string` union member would erase
that autocomplete entirely, since TypeScript collapses `TokenEncoding | string` to `string`). Use
this type wherever an API accepts "a built-in encoding, or a registered custom one" — for example
[Tokenizable.estimateTokens](../common/classes/Tokenizable.md#estimatetokens)'s `encoding` parameter. APIs that only ever accept the CLOSED
built-in set (e.g. a battery's `tokenEncoding` validation list) should keep using [TokenEncoding](../common/variables/TokenEncoding.md).