Apple Intelligence
Table of contents
Overview
Pharos can ask the Apple Intelligence model built into macOS for help with five things: explaining an error, naming a tab, a query card or a saved Session, drafting SQL from a sentence, and summarising a query plan.
The model runs on this Mac. Pharos uses Apple’s on-device SystemLanguageModel and opens no network connection of its own for it, so the prompt — which can carry your schema names, your SQL and, where you allow it, your row values — does not leave the machine.
Everything here is optional. Turn the whole set off in one place and Pharos behaves exactly as it did before.
Turning it on and off
Settings ▸ Intelligence ▸ Use Apple Intelligence features.
It is on by default. Clear it and every feature below disappears from its menu or panel — no prompts are built, no sessions are opened.
The line under the checkbox says what the features do, and the checkbox is greyed out when the model cannot run here at all. The reason then replaces the description:
| What you see | What to do |
|---|---|
| This Mac does not support Apple Intelligence. | Nothing — the hardware is not eligible. |
| Apple Intelligence is turned off in System Settings. | Turn it on in System Settings ▸ Apple Intelligence & Siri. Pharos notices the next time you switch back to it. |
| The on-device model is still downloading. Try again shortly. | Wait. macOS is fetching the model. |
| Turned off in Pharos settings. | Set the checkbox again. |
What the model is told
Every feature sends the same instruction first: it helps a PostgreSQL analyst, it must never propose DROP, DELETE, TRUNCATE, ALTER or UPDATE, and it writes text rather than running anything.
Pharos never executes what comes back. SQL the model drafts arrives in the editor as text for you to read, change and run yourself.
Features that read only your schema — table names, column names, types, a query plan — go ahead without asking. Anything that would put your row values in a prompt asks first, every time, with a sheet naming what will be read.
The label and the thumbs
Generated text always sits under a one-line header: the Apple Intelligence badge, the words Generated by Apple Intelligence, and a thumbs up and thumbs down.
The thumbs are for you to say whether the answer was any good. A press is recorded locally, in Pharos’s own database, as three things: which feature asked, a short digest of the prompt, and 1 or -1. The prompt itself is never stored, so nothing of your schema or your rows goes into that record. Nothing is uploaded, and pressing a thumb sends no message anywhere.
Pressing the other thumb changes your mind and is recorded as a second answer; pressing the same one again does nothing.
The five features
All five are new in this release.
Explain this error
When a query fails, the error sheet can turn PostgreSQL’s message into a plain sentence and suggest what to look at. It is given the message, the failing SQL and the relevant schema — never any rows.
Open the sheet — from the banner’s Details…, from the tab’s error button, or because a second failure opened it for you — and the explanation appears under the error text: the cause in one sentence, where in the statement it is when the message says, and up to three fixes. The first sentence arrives while the rest is still being written, so a spinner and Explaining the error… sit above it until the answer is complete. Previous and Next explain the entry you move to and drop the one you left; a cancelled query gets no explanation, because you already know why it stopped. If the model cannot answer, one line says so and a Retry button starts again with a fresh session.
What goes in the prompt is the server’s message word for word, the statement that ran (cut at 4,000 characters), and the tables the statement names — each with the columns the statement names, and their types. A table the statement never mentions is not described, and neither is a column: the prompt carries names and types, and there is no field in it a row value could occupy. Nothing is sent anywhere; the answer is written on this Mac and is gone when the sheet closes.
Suggest a name
Names a query card or a saved Session from the SQL it holds, so a card reads as Recent orders by region. Schema only; you can edit the suggestion before it is used. Query tabs are not named by the model: they take their connection’s name and schema (see Tab names).
Where it is. There is no button. A name is suggested in three places, and each of them shows you its usual text first — nothing waits for the model:
| Where | What happens |
|---|---|
| A card’s first run | A card with no name gets a suggested name. A name you type always wins. |
| Save Session… (⌘S) | The name field fills with a suggestion, selected, so your first keystroke replaces it. If your folders match, the folder is picked too. |
| Rename… on a query card | The dialog opens with the name it has; the suggestion arrives and replaces it, selected. |
Anything you have typed wins. A suggestion that arrives after you start typing is discarded, and the field says where the text came from — hover it for Name suggested by Apple Intelligence.
What the model is given. The statement (its first 2,000 characters), the table names it mentions, and — for a saved Session — the names of the folders you already have. No rows, no cell values, no result.
What Pharos does to the answer. Two to four words are asked for and the answer is then trimmed, stripped of wrapping quotes and a trailing full stop, put in Title Case (an identifier such as pg_class keeps its own spelling) and cut to 40 characters at a word boundary. It goes through the same sanitiser a name you type does, so a suggestion cannot carry an invisible or direction-reversing character into your library. A folder the model invented is dropped; only one you already have is selected. An empty answer changes nothing.
There is no thumbs up or thumbs down on a suggested name. You read and edit it in a field you are about to press Save or Rename on, which is a better answer than a rating.
Draft SQL
Describe what you want in a sentence and get a SELECT back in the editor, written against the connected database’s real tables and columns. The draft is inserted as text: read it, change it, and run it yourself when you are ready. The safety instruction keeps the model off statements that modify data.
Where it is. The Apple Intelligence button sits next to Format SQL in the editor’s toolbar. It is there only while Apple Intelligence is on, and it is greyed out — Connect this tab to a database to draft a query. — until the tab is connected, because a draft is written against a real schema or not at all.
How it works. Type what the query should return and press Draft (⌘↩). The on-device model has a 4,096-token window, so Pharos finds the tables and the model only writes the SQL. The popover names each step as it runs:
- Finding tables. Pharos matches the words of the request to table, column and comment names, and adds the tables one foreign key away. The strongest matches, plus the tables they reference, are the candidates.
- Choosing tables (only when there are too many candidates for one request). The model chooses up to six from the list by name. Its answer is held to the names on the list, so it cannot invent a table.
- Pharos adds any table that joins two chosen tables, and writes each table as a compact block: columns, types, primary keys, foreign keys (
->), enum values ({…}) and short comments. - Writing the query. The model gets the block, the request, and three short worked examples.
- Checking names. Pharos reads the draft and checks, on this Mac, that every table exists, that every
alias.columnbelongs to its table, that mixed-case names keep their double quotes, and that an enum is compared only with its own values. What the catalogue can answer, Pharos corrects itself: a join on columns that do not exist gets the foreign key between the two tables (when exactly one key joins them), a column read through the wrong alias moves to the one table that has it, and a mixed-case name gets its quotes. Each correction is listed under the draft — Pharos corrected: …. - Fixing names (only when a problem is left). The model gets the draft and the problems once, in a new session. A problem that is still there is shown under the draft — Check before running: … — rather than hidden.
Each model step is a new session with greedy sampling, so the same request against the same schema gives the same draft.
How well it works. scripts/eval-sql-draft.sh grades the feature with the real model against a 26-table fixture database and 22 requests. On macOS 27 (2026-10-05) the earlier design — one session that looked tables up with two tools — answered none of them: it ran out of the model’s window after more than a minute. This design answers 17 with SQL that runs and names the right tables, in about 7 seconds. Read closely, about 10 of those answer the request exactly; the others join a table the request did not need or choose the wrong aggregate. Read the draft before you run it.
What the model is given. Table and column names, types, keys, enum values and the first 80 characters of table and column comments, read from the schema cache and from one catalogue query per schema when the popover opens. There is no way for a row, a cell, a row count, a column default or a CHECK expression to enter it, so this feature never asks for consent to read your data — it cannot see any. Nothing is sent to the database to test the draft.
The answer arrives as one statement plus a sentence saying what the model assumed, under the Generated by Apple Intelligence header. Then:
- Insert puts the statement into the focused card when that card is empty, and otherwise into a new card.
- Retry asks the same question again, of a new session.
- Cancel closes the popover and discards the draft.
What Pharos does to the answer first. It trims it, takes off a code fence if the model added one, and keeps only the first statement — anything after the first semicolon is dropped. It then reads the result: a draft that does not start with SELECT, WITH or EXPLAIN, or that contains DROP, DELETE or TRUNCATE anywhere outside a string or a comment, is named before it goes in — This draft is not a plain SELECT: it contains DELETE. — with Insert Anyway and Cancel.
After Insert. The inserted statement is selected and washed with the accent colour, so you can see exactly what arrived. The wash goes as soon as you edit anything. One ⌘Z removes the whole draft in a single step.
Nothing runs. Drafting produces no results and writes nothing to your query history; the draft is text in the editor until you run it yourself.
Summarise a plan
Turns the output of a query plan into a short paragraph — which step costs the most, which index was used, which was not. It reads the plan, which is structure and estimates, not your rows.
Where it is. In the card’s Plan view (⇧⌘E, or ⌥⇧⌘E for a measured plan), between the header line and the outline. It starts as soon as the plan is shown — Summarising the plan… with a spinner — and is replaced by three lines under the Generated by Apple Intelligence header:
- a paragraph of two or three sentences,
- Slowest step: the node type and relation that account for the most work,
- Suggestion: one thing to try, when the model has one.
The outline is never replaced or reordered. The numbers stay exactly where they were; this is a reading of them, and it is marked as one. If the model cannot answer, the block says so and offers Retry. Switching away from the plan and back does not spend a second generation on the same plan.
What the model is given. The whole-plan figures — node count, planning time, execution time where the plan was run — and the twenty most expensive steps, worst first. A step is described by its node type, its relation and index, its estimated and measured row counts, its own time, its cost and the conditions the planner printed. Nothing else the server sent is included.
“Most expensive” means the step’s own measured time when the plan was run under ANALYZE, and its own cost when it was only estimated — the same measure the Share column draws, so the list the model reads is ordered the way the outline looks. Both kinds of plan are summarised; an estimate-only plan is the one most worth having read to you, because it has no measured times to rank by eye.
A query plan is structure, names and numbers. There is no row value anywhere in it, so this feature never asks for consent to read your data.
Suggest a chart
Picks a chart for a query result — the type, which column goes on which axis, how the values are aggregated, a title and axis titles — and says in one sentence why. It reads the columns’ names, types and shape, never a value.
Where it is. At the top of the chart rail, the Suggest chart button (see Charts). With the model available the button carries the Apple Intelligence badge and asks the model; without it the same button applies the chart Pharos itself recommends, and nothing is generated. The model is asked only when you press the button — opening Chart view for the first time uses the built-in recommendation alone.
The answer replaces the chart’s configuration and its reason appears under the Generated by Apple Intelligence header with the thumbs. More layouts lists the built-in candidates so you can compare. If the model names a column that is not there, or puts a text column on a numeric axis, Pharos keeps the top built-in candidate instead and labels the reason as its own. A request that does not finish in thirty seconds is stopped and offers Retry.
What the model is given. For each column: its name, its PostgreSQL type, and its shape — whether it reads as a category, a time, a measure, an identifier or a boolean; how many distinct values it has; whether they are all different; the share that is null; for a number, whether any is negative and whether all are whole; for a time column, the span between its earliest and latest value in days. Then the ranked candidates Pharos computed, and the SQL (its first 2,000 characters). The row count is given as a number. No cell value is in the prompt: a span, a count or a share is derived from the values, but none of them is one, which is why this feature never shows the consent sheet.
What Pharos stores
| Stored | Where | Contains your data? |
|---|---|---|
| The Use Apple Intelligence features switch | Pharos’s settings | No |
| One row per thumbs up or thumbs down | Pharos’s local database | No — feature name, prompt digest, rating and a timestamp |
Prompts, answers and sessions are not written to disk. Closing the panel that showed a generated answer discards it.