Skip to content

Service Configuration: Generic AI

This page is intended as a reference for intermediate and advanced users and developers. It may be useful when manually configuring other third-party services.

What capabilities does Generic AI provide?

Section titled “What capabilities does Generic AI provide?”

Generic AI is used for:

  • Extract Text
  • Extract Image Summary
  • Translate

Detect Text Block is not part of Generic AI. It requires a dedicated text block detection service.

  • Extract Text and Extract Image Summary require vision capabilities.
  • For translation, prioritize a model with stable language quality and sufficient context length.
  • Keep an eye on the model’s token cost. You can run a small batch first as a test.
  • To reduce cost, use a local model.

Both tasks require a model with vision capabilities. In product terminology, these are usually called multimodal models or vision-language models (VLMs).

For Extract Text, current VLMs are generally better at recognizing text than OCR models, especially irregular text, text outside bubbles, and special-effects lettering (SFX). They can also filter out Japanese furigana to some extent.

Therefore, even when the Detect Text Block model has already completed Extract Text along the way, running a vision model over the page again can still provide some value, although the improvement may be limited.

For Extract Image Summary, most capable vision models produce good results.

Reasoning usually does not help with this task. It is generally better to disable reasoning to save tokens and time.

Recommended models:

  • Xiaomi Mimo: mimo-v2.5
  • OpenRouter: google/gemma-4-31b-it (using OpenRouter’s mimo-v2.5 is not recommended because we have not found a way to disable its reasoning mode, which makes it more expensive and slower)

For translation, prioritize stable language quality and sufficient context length. Recommended models:

  • Official DeepSeek: deepseek-v4-flash, reasoning effort Medium. It is fast and produces good results.
  • Xiaomi Mimo: mimo-v2.5, reasoning effort Maximum.

The endpoint receiving requests. Presets normally provide it. Change it when using Ollama or another compatible local service.

The key issued by the provider. Local services may leave this blank. The key is stored in the device’s secure storage and is removed when its service configuration is deleted.

The exact model name sent to the provider. It must match a model supported by that provider. A custom display name does not change the identifier sent in the request.

Capabilities determine which automation actions can use a model.

Do not mark a model that lacks image input as capable of Extract Text or Extract Image Summary. An incorrect capability declaration may enable an action whose request ultimately fails.

The number of requests running at the same time. Higher values are usually faster, but they are more likely to trigger rate limits and use more memory. 0 means unlimited. If you are unsure, keep the preset value.

The maximum number of requests started during a time window. This is different from concurrency: concurrency limits simultaneous work, while rate limiting limits how many requests start during a period. 0 disables the limit.

The minimum delay between consecutive request starts, in seconds. Increase it when a provider throttles requests.

The number of retries after a failed request. 0 disables automatic retries. Retrying can incur provider charges; if the error is an invalid API key or an unknown model, increasing the retry count usually will not help.

Temperature, token limits, Top P, and similar parameters directly affect the request sent to the model. Leave them blank to use provider or model defaults. Do not fill them in unless you know that the provider supports the parameter.

Request override (requestOverride) handles differences between a provider and the standard OpenAI-compatible request format. It can modify request headers, URL query parameters, and the request body without changing the app’s general request logic.

A request override must be a JSON object:

{
"headers": {},
"query": {},
"body": {}
}

Keep all three fields. Use an empty object {} for a section that needs no override.

headers and query support the {{API_KEY}} placeholder. Before the request is sent, it is replaced with the API key from the current configuration. Do not put a real API key directly in a request override or commit it to documentation or a repository.

headers is a flat JSON object. Keys are header names, and values must be strings or null:

  • A string adds or replaces a header.
  • null removes the corresponding field from the app’s default headers.

For example, to add a header required by a provider:

{
"headers": {
"X-Provider-Version": "2026-01"
},
"query": {},
"body": {}
}

query is also a flat object. It modifies the query parameters after the API URL:

  • A string adds or replaces a query parameter.
  • null removes a query parameter.

For example, some providers require the API key in a key query parameter:

{
"headers": {},
"query": {
"key": "{{API_KEY}}"
},
"body": {}
}

A request override can modify query parameters, but it cannot modify the HTTP method or API path.

body is a partial patch to the request body, not a complete request body. The app first creates the common request parameters and then merges this content into them:

  • Ordinary fields add or replace fields with the same name.
  • Nested objects are merged recursively; overriding one child field does not remove its siblings.
  • A field whose value is null is removed from the final request body.
  • Numbers, strings, booleans, and arrays directly replace a value with the same name.

For example, to add provider-specific parameters:

{
"headers": {},
"query": {},
"body": {
"response_format": {
"type": "json_object"
},
"vendor_option": "value"
}
}

Use null to remove a field that the app would otherwise send:

{
"headers": {},
"query": {},
"body": {
"reasoning": null,
"reasoning_effort": null
}
}

The body override is applied after model parameters and reasoning parameters. Therefore, values in body take precedence over common parameters and reasoning mappings. An incorrect override can make the request incompatible with the provider.

A request override can come from two levels:

  • Provider-level override: the provider’s default override, usually supplied by the provider catalog.
  • Model-level override: an override that applies to one model only.

Model-level overrides follow these value states:

  • null: inherit the provider-level override.
  • A non-null object: replace the provider-level object as a whole; it is not deep-merged with the provider-level object.
  • {}: also a non-null object, meaning that this model explicitly uses no provider-level override.

Therefore, if a model-level override changes only one field from a provider-level override, it must also include the other provider-level fields that should be retained.

When a configuration is created from the provider catalog, the app may fill in a request override automatically. Until you edit it manually, the configuration continues to follow catalog default updates.

After you manually edit a request override, the app marks it as custom content and will no longer replace your input with catalog defaults when the settings page opens. Select Restore Defaults to use the catalog-provided override again.

  • The contents of headers, query, and body must be valid JSON objects.
  • headers and query use flat string or null values; do not write nested objects there.
  • Only body supports nested objects and deep merging.
  • Prefer values supplied automatically by the provider catalog.
  • If you are unsure whether a provider supports a field, check its API documentation first.
  • Test the saved configuration with one image before running it over an entire volume.