Airtable is where a lot of small teams keep the thing that actually matters: the content calendar, the lightweight CRM, the inventory sheet, the applicant pipeline. Getting an AI model to touch that data usually means writing a script against the Airtable REST API, or wiring an automation that calls an LLM with a frozen prompt and hoping the output lands in the right cell.
Terminal X takes a third path. You type what you want in plain English, a classifier turns it into a real Airtable API call, and the same run can also do the thinking part: look something up on the live web, draft the copy, generate an image, then write the result into your base.
This page is deliberately specific, because vague connector pages waste your afternoon. Below is the actual operation set from the Airtable runner, the actual record limits, the actual credit cost, and a straight list of what the connector cannot do.
The Airtable runner is a dispatcher with exactly six operations: list, search, get, create, update and delete. Nothing else is wired, so if a capability is not in this list, it does not exist yet.
list pulls recent records. The default is 20 and the hard ceiling is 100, because the runner issues a single pageSize request and does not follow Airtable's pagination offset. Ask for 500 rows and you get 100.
search filters using Airtable's own formula language. The classifier writes the formula in the same {FieldName} syntax you would type into a view filter. Two examples taken directly from the instructions it is given: {Status} = 'Active' and FIND('alex', LOWER({Email})) > 0. The same 100-record ceiling applies to a filtered result.
get returns one record with every field printed out, not just a preview. You can identify it by its record id (the rec... string) or by describing it in words.
create appends one record. Airtable's typecast flag is switched on, so a plain string like "High" written into a single-select field gets coerced into the right cell type instead of bouncing back a 422. One record per task. There is no batch insert.
update is a PATCH, not a replace. Fields you did not mention keep their existing values, which is the behaviour you want when an AI is editing a row you care about. Same typecast handling.
delete removes a single record and reports back the id it removed.
Two consequences fall out of that shape. list and search answers are summaries: the first five fields of each record, each value truncated at 80 characters. That is a readable answer in a chat surface, not a full export. And every write path is single-record, so "update all 40 rows where Status is Stale" is not one call, it is forty prompts.
When a prompt mentions Airtable, the parser routes that piece of the work to the airtable runner. The runner then makes a second, smaller call: Claude Sonnet 4-6, capped at 1500 tokens, asked to return strict JSON with an op, a maxResults, a filterByFormula, a recordId, a match phrase and a fields object. No prose, no markdown fences. If the request is genuinely unclear about intent, the fallback op is create.
The interesting engineering problem is get, update and delete when you have not given a record id, which is almost always. Airtable has no native full-text record search, so the runner approximates one. It fetches the first 100 records, flattens the first five fields of the first 50 of them into a single labelled line each with values cut at 40 characters, and asks Claude which index best matches your phrase. If it cannot pick with confidence it returns -1 and you get "Couldn't find that record" rather than a silent edit to the wrong row.
Know the failure mode this creates. If the record you meant is row 220 of a 400-row table and you gave neither an id nor a filter, it will not be in the candidate list, so it cannot be found. The reliable pattern is to narrow first: search for it, read the rec id off the answer, then reference that id in your next prompt.
Letting a model issue DELETE against a production base is the kind of feature that reads well in a demo and badly in a postmortem. The Airtable classifier is handed a shared rule block before it is allowed to choose an operation. Four of those rules do most of the work.
Never invent values. Every id, name, date, field value and table name in the classifier's output must appear literally in your request or in the context it was given. If a required field is missing, it must leave it empty and fall back to an operation that does not need it.
Prefer safe operations on ambiguous prompts. When a phrase could mean two things, it leans toward the read. "Look at the Q3 doc" resolves to a read, not an update. You can always escalate to the destructive version explicitly; you cannot undo a wrong delete.
Destructive operations need a specific target. A bare "delete my old records" with no qualifier is classified as a search instead, so you see the candidates before anything is removed.
Untrusted context. If an earlier task in the same run scraped a web page, that text is treated as data, never as instructions. A delete target or a send destination that appears only in scraped context and not in your own words is refused. This matters more than it sounds when a prompt chains a web scrape into an Airtable write.
One Airtable action bills a flat 5 credits. It does not scale with how many records come back, and it is not metered per token, because Airtable's own API is billed against your Airtable account rather than ours. Our real spend on that task is the classifier call and, when a match phrase is involved, the candidate-picking call.
One credit is calibrated at $0.006 of API spend, so an Airtable operation is roughly three cents. The Basic plan is $4.99 for 400 credits a month, which is about 80 Airtable operations if you spent the entire allotment on nothing else. In practice you will not, because the point of a router is that the Airtable step is one piece of a larger prompt. The other pieces bill separately, at their own rates.
The table below is the base per-task credit cost for the things people most often chain onto an Airtable step, straight from the executor's cost table. Read it with one caveat: connector and document rows bill that number flat, while model rows are metered against real token and API usage, so their figure is the starting quote rather than a ceiling. A long multi-step research run is the one to watch — it loops, and it can settle several times above its base.
A worked example. "Find the three highest-priority open items in my base, research each company, write a two-line summary for each, and post it to Slack" is one search, one research pass, one Sonnet writing pass and one Slack post. The two connector steps are fixed at 5 and 3 credits; the research and writing steps start from 20 and 4 and settle on what they actually consume. What you do not pay for is the copying: the research and writing steps run against the same data the search returned rather than against something you pasted somewhere.
One base, one table per connection. On the OAuth path, Airtable's consent screen lets you choose which bases to grant, and the runner then discovers your first granted base and the first table inside it. On the pasted-key path, the credential itself is the pin: the format is PAT:BASE_ID:TABLE_NAME. Either way, a prompt cannot hop to a different table mid-run, and there are no cross-table joins or linked-record traversals.
No pagination. 100 records is the wall on any single read. This is a connector for looking things up and changing them, not a reporting layer over a 10,000-row base. If you need the whole table, export it from Airtable.
No batch writes. Create, update and delete each act on exactly one record.
No schema access beyond discovery. It reads base and table metadata to find where to point, and that is all. It cannot create a base, add a table, add a field, or change a field type.
No attachments, no views, no sorts. It cannot upload a file into an attachment field, cannot target a named view, and cannot ask Airtable to sort before returning. Ordering is whatever Airtable returns by default.
No triggers and no scheduling. There is no "when a record is created" webhook and no recurring run. Every Airtable action starts from a prompt you send.
No approval step. There is no review gate where a named teammate signs off before a record changes — once the run is authorised, the write goes in.
Being blunt about these is cheaper for both of us than a support thread three weeks in.
Zapier and Make are event-driven automation platforms. They watch Airtable, fire on a record change, and run a fixed sequence of steps. Terminal X does not do that half at all, and pretending otherwise would be dishonest. If your requirement is "every time a row is created, do X," build the Zap.
The half Terminal X does differently is the intelligence inside the step. In a Zap, an AI action is usually one node with a hand-written prompt template and one chosen model. In Terminal X, a single request is parsed, split into tasks, and each task is sent to the model that specialist work belongs to. The research goes to a search-grounded model, the prose goes to Sonnet, the image goes to an image model, and the Airtable write goes to the connector, with several of them running in parallel rather than in a queue.
So the honest split is this: recurring, event-shaped work belongs in an automation platform. Ad hoc work that needs judgment, a live web lookup or a piece of generated content before it touches the base is where a router earns its keep.
There are two ways in, and which one you see depends on whether the Airtable OAuth app is configured on our side. The OAuth flow uses PKCE with S256 (Airtable requires it even for confidential clients) and requests three scopes and no more: data.records:read, data.records:write and schema.bases:read. During consent you choose which bases to grant. Nothing outside that selection is reachable.
The fallback is a pasted personal access token. Create one at airtable.com/create/tokens, then paste it in the format PAT:BASE_ID:TABLE_NAME, which pins the exact table the connector will use.
Access tokens from the OAuth flow last one hour and refresh tokens are single-use, so each refresh issues a replacement that overwrites the old one. That is handled for you, with a five-minute expiry margin so a long-running task does not die halfway through holding a stale token. Connector tokens are encrypted at rest with AES-256-GCM.
When something is wrong you get a plain sentence rather than a stack trace. "Airtable isn't connected. Connect it at /connections first." means there is no credential. "No Airtable base is granted to Terminal X" means the token is valid but the consent screen was completed without selecting a base, and you need to reconnect and grant one.
Airtable is available on every plan, and every plan unlocks every connector — there is no connector-tier upsell. The only models gated by plan are Kling video and Runway Aleph, both Business-only.
Or skip the comparison shopping: Terminal X routes one prompt to the right model automatically — and runs several in parallel when a job needs more than one.
| Task in the prompt | Model or connector | Base credits | ≈ USD |
|---|---|---|---|
| Read, filter or write Airtable records | airtable connector | 5 (flat) | $0.030 |
| Post the result to a Slack channel | slack connector | 3 (flat) | $0.018 |
| Mirror a summary into Notion | notion connector | 5 (flat) | $0.030 |
| Export the same rows as an .xlsx | excel | 8 (flat) | $0.048 |
| Quick live-web lookup or fact check | perplexity | 6 (metered) | $0.036 |
| Draft the copy that goes in the record | claude-sonnet | 4 (metered) | $0.024 |
| Multi-step research before writing | research | 20 (metered) | $0.120 |
| Generate an image for the row | nano-banana | 2 (metered) | $0.012 |
It writes. The connector supports six operations: list, search by formula, get, create, update and delete. Create appends one record with typecast enabled, so plain strings get coerced into the correct field type. Update is a PATCH, so fields you did not mention keep their existing values. Every write acts on a single record at a time; there is no batch insert or bulk update.
Twenty by default, one hundred at the ceiling. The runner issues a single paged request and does not follow Airtable's pagination offset, so asking for more than 100 still returns 100. If you need a specific subset from a large table, use a filter: search accepts real Airtable formula syntax such as {Status} = 'Active' or FIND('alex', LOWER({Email})) > 0.
One base and one table per connection. If you connect over OAuth, Airtable's consent screen lets you pick which bases to grant, and the runner uses the first granted base and the first table inside it. If you paste a personal access token, the credential format PAT:BASE_ID:TABLE_NAME pins the target explicitly. A prompt cannot switch tables mid-run, and there are no cross-table joins or linked-record lookups.
A flat 5 credits, about $0.03 at the calibrated rate of $0.006 per credit. It does not scale with the number of records returned, because Airtable's API is billed to your Airtable account rather than ours; the 5 credits cover the classifier call that turns your sentence into an API request. The Basic plan is $4.99 for 400 credits. Other tasks in the same prompt, such as research or drafting, bill separately — those are model tasks, so they meter against real token usage rather than a flat rate.
No. There are no Airtable triggers, webhooks or scheduled runs. Every action starts from a prompt you send. For recurring event-driven work, an automation platform like Zapier is the right tool. Terminal X is aimed at the ad hoc case where the step needs judgment, a live web lookup, or generated content before it touches the base.
Airtable has no native full-text record search, so the runner fetches the first 100 records, shows the first 50 of them to Claude as one summarised line each, and asks which index matches your phrase. If nothing matches with confidence, it returns "Couldn't find that record" instead of guessing. The practical implication is that a record deep in a large table may not appear in the candidate set, so narrow it with a search first, then reference the returned rec id directly.
Or skip the comparison shopping: Terminal X routes one prompt to the right model automatically — and runs several in parallel when a job needs more than one.