> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lectr.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Task Types

> One header. Smarter recommendations.

## What it does

The `X-Lectr-Task` header tells Lectr what kind of work a request is doing.

Without it, Lectr guesses from signals like prompt length and response length — educated guesses, medium confidence. With it, Lectr knows with certainty and generates high-confidence model recommendations.

```
X-Lectr-Feature: classifier
X-Lectr-Task: classification   ← this one
```

That's it. One extra header.

***

## The five task types

| Value            | Use when you're...                                          |
| ---------------- | ----------------------------------------------------------- |
| `classification` | Sorting input into categories — sentiment, intent, priority |
| `summarisation`  | Condensing content into a shorter form                      |
| `extraction`     | Pulling structured data out of unstructured text            |
| `generation`     | Creating new content — copy, emails, code                   |
| `reasoning`      | Multi-step thinking, analysis, complex problem solving      |

<Note>
  Values outside this list are stored as-is and visible in your dashboard but
  don't influence recommendations.
</Note>

***

## Adding the header

<CodeGroup>
  ```typescript Node.js theme={null}
  const client = new OpenAI({
    apiKey: process.env.OPENAI_API_KEY,
    baseURL: "https://proxy.lectr.ai/v1",
    defaultHeaders: {
      "X-Lectr-Key": process.env.LECTR_KEY,
      "X-Lectr-Feature": "classifier",
      "X-Lectr-Task": "classification",
    },
  });
  ```

  ```python Python theme={null}
  client = OpenAI(
      api_key=os.environ["OPENAI_API_KEY"],
      base_url="https://proxy.lectr.ai/v1",
      default_headers={
          "X-Lectr-Key": os.environ["LECTR_KEY"],
          "X-Lectr-Feature": "classifier",
          "X-Lectr-Task": "classification",
      },
  )
  ```
</CodeGroup>

If your feature handles multiple task types, override per request:

<CodeGroup>
  ```typescript Node.js theme={null}
  const response = await client.chat.completions.create(
    { model: "gpt-4o", messages },
    { headers: { "X-Lectr-Task": isComplex ? "reasoning" : "generation" } },
  );
  ```

  ```python Python theme={null}
  response = client.chat.completions.create(
      model="gpt-4o",
      messages=messages,
      extra_headers={
          "X-Lectr-Task": "reasoning" if is_complex else "generation",
      },
  )
  ```
</CodeGroup>

***

## How Lectr uses it

### Model recommendations

Task type is the highest-confidence signal in the recommendation engine — it overrides
heuristic signals when present.

| Task type        | What Lectr does                                                  |
| ---------------- | ---------------------------------------------------------------- |
| `classification` | Strong downgrade candidate — smaller models handle this well     |
| `summarisation`  | Downgrade candidate — more conservative if prompts are long      |
| `extraction`     | Downgrade candidate — conservative for complex nested extraction |
| `generation`     | Neutral — relies on other signals, not task type alone           |
| `reasoning`      | **Never** recommended for downgrade. Ever.                       |

The reasoning protection is hardcoded. No signal, no matter how strong, will
produce a downgrade recommendation for a `reasoning` task.

### Dashboard visibility

Task type appears as a column in your request logs table — you can see exactly
which task type was tagged on each request and filter by it.

***

## Using with routing rules

Routing rules can use task type to automatically direct requests to the right model.

For example:

```text theme={null}
If X-Lectr-Task = classification
→ Route to gpt-4o-mini
```

This allows you to:

* run simple tasks on cheaper models
* reserve powerful models for complex reasoning
* optimize cost without changing application code

Task type becomes a reliable signal for automated routing — no heuristics, no guesswork.

See [Routing Rules](/guides/routing-rules) for how to configure this.

***

## Reference

| Header         | `X-Lectr-Task`                                                         |
| -------------- | ---------------------------------------------------------------------- |
| Required       | No                                                                     |
| Valid values   | `classification` `summarisation` `extraction` `generation` `reasoning` |
| Invalid values | Stored as-is, no influence on recommendations                          |
| Missing        | Request processed normally, heuristic signals used                     |

***

## FAQ

<AccordionGroup>
  <Accordion title="Do I need X-Lectr-Feature to use X-Lectr-Task?">
    No — they're independent. But combining them gives Lectr the most context and
    produces the most confident recommendations.
  </Accordion>

  <Accordion title="What if my feature does multiple task types?">
    Override per request. A chat feature might use `reasoning` for complex
    questions and `generation` for drafting — tag each request with what it's
    actually doing.
  </Accordion>

  <Accordion title="Does this affect my prompts or responses?">
    No. Lectr reads the header and stores it as metadata. Your prompt, model
    choice, and response are untouched.
  </Accordion>

  <Accordion title="Does it add latency?">
    No. The header is read on ingress and stored after the request completes.
    Zero hot path impact.
  </Accordion>
</AccordionGroup>