Skip to main content

Hidoba Metadata

Messages API v3 accepts optional Hidoba-specific request metadata under metadata.hidoba.

Only these fields are allowed:

FieldTypeDescription
characterString or objectGitHub character reference or inline character object.
character_paramsObjectFlat template parameters for the character personality. Values may be string, number, boolean, or null.

All other metadata.hidoba fields are rejected.

GitHub Character​

Use a GitHub character reference when the character is saved in Hidoba:

{
"metadata": {
"hidoba": {
"character": "github:partner/CharacterName",
"character_params": {
"person_name": "Alex"
}
}
}
}

github-force: is also accepted for force-refresh flows:

{
"metadata": {
"hidoba": {
"character": "github-force:partner/CharacterName"
}
}
}

Hidoba validates that the quota is allowed to use the requested character.

Inline Character​

Use an inline character object for ad hoc testing or cases where the character is supplied with the request:

{
"metadata": {
"hidoba": {
"character": {
"parameters": {
"name": "Mira",
"language": "en",
"person_name": "Alex",
"robot_name": "Mira",
"name_colon": "Mira:",
"conversation_prefix": "",
"interruption_message": "",
"easy_questions": [],
"difficult_questions": [],
"voice": null,
"greetings": [],
"max_new_tokens": 128
},
"personality": "You are {{ robot_name }}. Be concise and helpful."
}
}
}
}

Inline characters must pass Hidoba character validation. Some existing character schemas include max_new_tokens as legacy character metadata. Messages API v3 does not use character max_new_tokens to control generation length; use request-level token limits instead.

Character Params​

character_params are rendered into Jinja character personality templates.

{
"metadata": {
"hidoba": {
"character": "github:partner/CharacterName",
"character_params": {
"person_name": "Alex",
"plan": "premium"
}
}
}
}

Rules:

  • character_params must be a JSON object.
  • Values must be string, number, boolean, or null.
  • character_params.context is reserved and rejected.

Knowledge Context​

Knowledge context is configured in the character settings. This works the same way whether the character is referenced from GitHub or supplied inline.

For a GitHub character, configure the knowledge settings in the saved character file and reference the character:

{
"metadata": {
"hidoba": {
"character": "github:partner/CharacterName"
}
}
}

For an inline character, include the knowledge settings inside the character parameters object:

{
"metadata": {
"hidoba": {
"character": {
"parameters": {
"robot_name": "Mira",
"rag_index_required": "partner/knowledge-base-name",
"rag_enabled": true
},
"personality": "You are {{ robot_name }}. Use the available knowledge context when relevant."
}
}
}
}

When knowledge context is configured, Messages API v3 may add relevant context automatically before the model answers.

In character settings:

  • rag_enabled turns knowledge context on for that character.
  • rag_index_required selects which saved knowledge base the character should use.

Model Fallback​

Do not send routing config in metadata.hidoba.

Invalid:

{
"metadata": {
"hidoba": {
"routing": {
"primary_model": "google/gemini-2.5-flash"
}
}
}
}

To request a fallback model, use top-level fallback_model:

{
"model": "google/gemini-2.5-flash",
"fallback_model": "qwen/qwen3.6-27b"
}

Messages API v3 uses this as a routing option when supported.

Model Conversation Visibility​

metadata.hidoba is Hidoba-only request metadata and is not included in the model conversation. Non-Hidoba metadata is preserved:

{
"metadata": {
"client": "kept",
"hidoba": {
"character": "github:partner/CharacterName"
}
}
}

The model request keeps:

{
"metadata": {
"client": "kept"
}
}