Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

Pagination and limits

Cursor pagination, the 50-result cap on job search, and why a large limit is usually a bug rather than an optimization.

Job search is free within monthly quotas. A limit of 50 burns five times the quota of a limit of 10.

How cursors work

List endpoints return a meta.next_cursor. Pass it back as cursor to get the following page. When it is null or absent, you have reached the end.

curl -s "https://api.worklittle.com/jobs?q=data+engineer&limit=20" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY"

curl -s "https://api.worklittle.com/jobs?q=data+engineer&limit=20&cursor=NEXT_CURSOR" \
  -H "Authorization: Bearer $WORKLITTLE_API_KEY"

Cursors are opaque. Do not parse them, do not construct them, and do not assume they encode an offset you can skip ahead with. Keep the rest of your query parameters identical between pages; changing filters mid-pagination gives you an undefined result set.

Limits by surface

| Surface | Default | Maximum | Notes |
| --- | --- | --- | --- |
| `GET /jobs` | 20 | **50** | Free within monthly quota |
| `/candidates` | paginated | use `limit` + `cursor` | Free, but do not omit `limit` |
| Public board list | 25 typical | board-defined | Free, ETag cached |

Asking for more than the maximum does not silently give you more. Plan for the cap rather than discovering it in production.

Why big limits backfire

Three separate reasons, and they compound.

Cost. Search billing counts jobs in data. A limit=50 call bills like fifty rows even if your user reads three. Over a busy agent loop this is the dominant line item on Usage.

Model quality. Fifty results in a context window crowd out the conversation and push the model toward shallow scanning. Ten well-filtered results produce better recommendations than fifty loosely filtered ones.

Latency. Bigger pages are slower to produce and slower to stream into a UI. Users perceive the first result appearing, not the fiftieth.

The right fix for "I am not finding enough" is almost never a bigger page. It is better filters: title with negative tokens, workplace_type, seniority_level, and a sensible posted_within_days.

Paginate on intent, not on principle

An agent should fetch the next page when a user asks for more, not as a default completion behavior. Concretely:

Fetch page one. Present it. If the user says "more" or "none of these", fetch page two with the same filters, or refine the filters instead. Cap total pages per conversation. Three is generous for interactive use. For batch or export jobs where you genuinely need everything, paginate to exhaustion deliberately, off the interactive path, with the cost accounted for.

Exhaustive pagination inside a chat turn is the classic runaway. It is slow, it is expensive, and the model rarely uses the last pages it pulled.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| `limit=200` to reduce round trips | The cap is 50, and each row bills |
| Parsing or fabricating a cursor | Pass back exactly what `meta.next_cursor` gave you |
| Changing filters between pages | Keep the query stable across a pagination run |
| Looping until `next_cursor` is null by default | Paginate on explicit user intent |
| Re-requesting page one to re-read a title | Cache the page for the conversation turn |
| Counting results by paging | Use `GET /jobs/stats` |