# Keeping responses small

Every response is projected, paginated and capped before it reaches you. Working
*with* that is much cheaper than fighting it.

## The four levers, cheapest first

**1. `fields=[...]` — surgical.** When you need two values, ask for two values.

```
norsk_call(id="brreg.enhet.search", params={naeringskode:"47.111"},
           limit=30, fields=["orgnr","navn"])
```

**2. `limit` — always set it.** Default 10, max 50. A screen of 30 rows at two
fields each is cheaper than 10 rows of the full default projection.

**3. `view` — the curated middle ground.** `default` is hand-picked per
operation. Some operations offer named alternatives (`minimal`, `adresse` on
`brreg.enhet.search`); `norsk_describe` lists them.

**4. `view:"full"` — last resort.** Unprojected upstream payload. The brreg
company search costs about 9 000 tokens this way versus 600 projected. Use it
only when the user explicitly needs a field that no view exposes, and pair it
with `limit=1`.

## Reading `meta`

```json
"meta": {
  "rows": 10, "total": 88, "truncated": true, "cursor": "10",
  "tokens_est": 619, "source": "brreg: ...", "fetched_at": "..."
}
```

- `truncated: true` — **there is more.** Follow `cursor`, do not re-run the same
  query with a bigger limit hoping it fits. It will not; the budget is a hard
  ceiling, not a suggestion.
- `total` — the full upstream result count. Use it to tell the user "88 matches,
  showing 10" instead of implying you found 10.
- `tokens_est` — what that response actually cost you.

## Pagination

```
norsk_call(id="brreg.enhet.search", params={...}, limit=25)              # cursor "25"
norsk_call(id="brreg.enhet.search", params={...}, limit=25, cursor="25") # next page
```

Keep `params` identical between pages. Changing the query mid-pagination gives
you an incoherent result set.

**Before paginating, ask whether you should narrow instead.** Three pages of a
national search is usually a sign the filter was too broad — add
`kommunenummer`, `organisasjonsform` or a tighter `naeringskode` and get the
answer in one call.

## The hard cap

Responses are capped at 4 000 estimated tokens. On overflow, rows are dropped,
`truncated` goes true, and `meta.note` says how many went. This applies even to
`view:"full"` — a runaway payload is a problem for you regardless of what you
asked for.

## Rough costs

| Call | Tokens |
|---|---|
| `norsk_search` (8 results) | ~300 |
| `norsk_describe` (1 op) | ~400–900 |
| `norsk_resolve` (5 candidates) | ~250 |
| Company record, default view | ~200 |
| Board roles | ~65 |
| Annual accounts, 3 years | ~150 |
| Company search, 10 rows default | ~620 |
| Same search, `view:"full"` | ~9 000 |

A complete company profile — resolve, registry record, board, accounts — is
about 1 200 tokens including the tool schemas. If you are spending far more than
that on a simple question, you are probably calling `view:"full"` or skipping
`limit`.

## Skip `norsk_describe` when you can

It costs 400–900 tokens. `norsk_call` returns the parameter schema *inside* its
error when you get something wrong, so for an operation with obvious parameters,
guessing and correcting is cheaper than describing first. Reach for `describe`
when an operation has non-obvious parameters (SSB's `valgKoder`) or when you
need to know which views exist.