GPT-6 Astra for Agencies: The Orchestration Pattern, 8 Skills, and Cost Receipts Per Deliverable

Source: github.com/DannyMac180/astra-advisor, MIT. A Codex plugin where GPT-6 Astra plans the work, delegates bounded pieces to subagents, and owns verification and acceptance.

It was built for software delivery. The pattern is the transferable part, and it maps almost exactly onto agency client work: one owner of quality, bounded briefs, declared cost, and a reviewer who did not do the work.

What the plugin actually does

Astra stays the architect and the acceptance owner in the primary session. It does not change the parent session's model or effort.

When delegation helps, it spawns a subagent with an explicit model and reasoning effort, gives it one concrete bounded deliverable, and keeps working on the parent task while that runs.

For anything substantial it then inspects the complete output, reruns the requested checks, and sends the accumulated change set to a fresh read-only reviewer. Work is accepted only when the reviewer returns ship.

The three things that make it worth porting to agency work:

1. It fails closed. If a model, effort or tool is unavailable or unobservable, it fails that delegation and reports the limitation. It does not silently substitute.
2. Chosen and confirmed are reported separately. A requested setting is not proof of the realised setting.
3. Every task ends with a cost receipt. Token usage priced against a versioned snapshot, with whole-task, delegated-only, and partial coverage kept separate.

Install

Needs a current Codex CLI or the ChatGPT desktop app with plugins enabled. Start a fresh task after installing and select GPT-6 Astra.

codex plugin marketplace add DannyMac180/astra-advisor --ref main
codex plugin add astra-advisor@astra-advisor

Then start any task with:

Use $astra-advisor:orchestration to plan, build, verify, and review
this work.

Updating:

codex plugin marketplace upgrade astra-advisor
codex plugin add astra-advisor@astra-advisor

Local development, if you want to fork it and add the GTM skills from this guide directly:

cd /absolute/path/to/astra-advisor
codex plugin marketplace add /absolute/path/to/astra-advisor
codex plugin add astra-advisor@astra-advisor

The plugin structure

One plugin, one skill. Small surface, which is why it is easy to extend.

astra-advisor/
├── .agents/plugins/
├── plugins/astra-advisor/
│   ├── skills/orchestration/
│   │   └── references/operations.md   <- the input contract
│   ├── pricing/2026-09-04.json       <- the versioned rate snapshot
│   ├── scripts/cost_receipt.py
│   ├── scripts/verify.sh
│   └── examples/illustrative-usage.json
└── README.md

The GTM skills in this guide go alongside skills/orchestration/ as sibling skills, so Astra can route to them the same way it routes to the built-in one.

Try the cost calculator

Run this before you build anything, because the receipt format is what makes the whole thing usable for client billing.

python3 plugins/astra-advisor/scripts/cost_receipt.py \
  plugins/astra-advisor/examples/illustrative-usage.json

sh plugins/astra-advisor/scripts/verify.sh

The calculator emits JSON and accepts --pricing PATH for another verified snapshot. Its input lists agents and unique atomic calls, usage provenance, coverage assertions, and explicit pricing eligibility.

What it deliberately refuses to do is worth knowing: it rejects unsupported long-context, service-tier and cache-write cases rather than assuming standard rates, refuses overlapping aggregates, and keeps unknown usage separate from zero. It supports at most 128,000 input tokens per call as an implementation boundary.

The example workload is labelled illustrative. It is not a receipt for your task and should not be shown to a client as one.

Two limitations to plan around

Cloud tasks cannot pin model or effort. ChatGPT Work cloud create_thread must omit both, so it cannot promise arbitrary model or effort control. Astra does not dispatch a model-pinned request there by default.

For an explicit Codex app task, mcp__codex_app__create_thread does support model and thinking. Call mcp__codex_app__list_projects first for project targets, use a worktree by default for Git projects, local otherwise.

The repo is explicit that you should not use an API key, a nested CLI, or an invented tool as a workaround. That discipline is the whole point of the pattern.

The cost comparison is narrower than it looks. It is a same-token API price comparison. It does not measure what an all-Astra run would actually consume, actual net savings, quality, speed, or any change to subscription charges. No subagents means no delegation savings. Reasoning effort does not multiply the token price.

If you put a receipt in front of a client, that caveat goes in the same document. A margin number you cannot defend is worse than no number.

Why port this to GTM at all

Agency work has the same failure mode as software delivery: many parallel pieces, one person accountable, and no reliable gate between produced and shipped.

The four properties that transfer directly:

• One acceptance owner. Not a committee, not the person who produced it.
• Bounded briefs. One concrete deliverable per delegation, not a theme.
• Fail closed. If the inputs are not there, stop and say so rather than producing something plausible.
• A fresh reviewer. Someone who did not do the work, with three verdicts and no fourth option.

Every skill in this guide is that pattern applied to a client deliverable.

Astra chooses among three subagent models at a declared reasoning effort. There are no predefined roles and no fixed subagent count. It picks from the task's risk, context, and how much independent work there is.

Live tool metadata is authoritative. The table below is the documented snapshot, not a guarantee.

The models and their efforts

Model	Known efforts
gpt-5.6-sol	low, medium, high, xhigh, max, ultra
gpt-5.6-terra	low, medium, high, xhigh, max, ultra
gpt-5.6-luna	low, medium, high, xhigh, max

Note luna has no ultra. If you route a high-stakes deliverable to luna at ultra, the delegation fails closed rather than quietly dropping to max. That is the behaviour you want and the reason not to hard-code routing without checking live metadata.

Delegation uses the generic collaboration.spawn_agent tool with an explicit model, reasoning_effort, and fork_turns: none.

Routing GTM deliverables

The repo deliberately has no role-to-model mapping, so this is a starting heuristic rather than a rule. Adjust once you have receipts.

Deliverable	Effort	Why
List filtering, reply classification, field normalisation	low	Classification at volume. One right answer per row.
Ad variants, opener copy, subject lines, merge prompts	medium	Known artefact from known inputs
Content briefs, sequence specs, audit findings	high	Structure plus judgement
ICP derivation, positioning, campaign diagnosis	xhigh	Reasoning over conflicting evidence
Client proposals, pricing architecture, quarterly plans	max	Highest stakes, single-shot, hard to unwind
The parent architect session	your call	Astra never changes the parent effort. You set it.

The expensive mistake is routing a proposal low. The tokens saved are trivial against a lost deal, and a proposal is the one deliverable a client reads word by word.

The wasteful mistake is routing list filtering high. It touches every row, so it is the highest-volume call in any GTM chain and has the least reasoning in it.

The delegation brief

Every delegation announces its name, bounded task, selected model and effort, and the reason it was selected. Write briefs that make that announcement meaningful.

DELEGATION BRIEF

Name: [short identifier, appears in the announcement]

Bounded deliverable: [ONE artefact, named as a file or document. Not
a theme, not an area of work. "filtered-leads.csv with a KEEP/DROP
column and a 12-word reason per row" is bounded. "help with the
list" is not.]

Model: [gpt-5.6-sol | gpt-5.6-terra | gpt-5.6-luna]
Reasoning effort: [low | medium | high | xhigh | max | ultra]
Selection reason: [one sentence tying the choice to risk, context
volume, or independence of the work]

Inputs it may use: [exact file paths or pasted content. Nothing else.]
Inputs it may NOT infer: [the fields where guessing is fabrication]

Definition of done: [the checks that must pass, stated so a reviewer
who did not do the work can run them]

Fail closed if: [the conditions under which it should stop and report
rather than produce something plausible]

The last two fields are what make the pattern work. Without a definition of done a reviewer has nothing to check against, and without fail-closed conditions the delegation invents its way past a missing input.

Chosen versus confirmed

The principle worth stealing outright: a requested setting is not proof of the realised setting.

Astra reports chosen values and runtime-confirmed values separately, and where a setting is unobservable it says so explicitly rather than assuming it took effect.

Ported to agency reporting, that means every deliverable log carries three columns rather than one:

Deliverable | Chosen model+effort | Confirmed | Status

icp.md          | terra / xhigh   | confirmed    | ship
filtered.csv    | luna / low      | confirmed    | ship
proposal.md     | sol / max       | unobservable | ship
ad-variants.md  | luna / medium   | confirmed    | fix-first

The unobservable row is the honest one. If you cannot confirm what actually ran, the receipt cannot claim whole-task coverage, and neither can your margin number.

Eight skills, written in the plugin's own shape. Each one is a bounded deliverable with a definition of done and explicit fail-closed conditions.

Save alongside the built-in skill so Astra can route to them:

mkdir -p plugins/astra-advisor/skills/{icp-derivation,list-qualification,signal-research,outreach-sequence,audit-production,proposal-assembly,campaign-diagnosis,deliverable-review}

1. icp-derivation

---
name: icp-derivation
description: Derive an ICP from closed-won evidence. Bounded
  deliverable, high delegation value, runs independently of
  everything else.
suggested-effort: xhigh
---

# ICP Derivation

BOUNDED DELIVERABLE
clients/[CLIENT]/icp.md, containing all six sections below. Nothing
else.

INPUTS YOU MAY USE
- The CRM export of closed-won deals, last 12 months
- The client brief

INPUTS YOU MAY NOT INFER
- Deal sizes not present in the export
- Job titles not present in the export
- Any attribute of a customer not in the data

PRODUCE
1. Three attributes correlating with fast closes
2. Three correlating with long or lost deals
3. Exact job titles that actually signed
4. Size band with the highest win rate
5. A searchable filter string
6. The gap between the stated ICP and the actual one

DEFINITION OF DONE
- Every attribute traces to at least three deals in the export
- Section 6 names a specific difference or states there is none
- The filter string is syntactically valid for the target platform

FAIL CLOSED IF
- Fewer than 10 closed-won deals exist. Report the count and stop.
  Do not derive a pattern from three customers.
- The export lacks job titles or company size. Name the missing
  field.
- Deals are present but all from one sector. Say so, because the
  pattern is sector-specific rather than general.

REPORT chosen model and effort, and whether runtime settings were
confirmed or unobservable.

2. list-qualification

---
name: list-qualification
description: Filter and grade a raw prospect list. Highest-volume
  delegation in the chain, lowest reasoning content.
suggested-effort: low
---

# List Qualification

BOUNDED DELIVERABLE
two files: filtered.csv and dropped.csv. Plus a grade.

INPUTS YOU MAY USE
- prospects.csv
- icp.md

PRODUCE, PER ROW
Exactly one of KEEP, DROP, UNSURE, plus a reason of 12 words maximum.

KEEP    Matches the title band and the size band
DROP    Fails either, or is a competitor, a student, an agency when
        the client sells to in-house teams, or too small to afford
        the stated price
UNSURE  Headline is ambiguous. Do not guess.

Then grade the surviving list A to F across eight dimensions, 1 to 10:
ICP fit, title accuracy, affordability, data completeness,
deduplication, recency, reachability, signal strength.

A 9.0+  B 7.5+  C 6.0+  D 4.5+  F below

DEFINITION OF DONE
- Every input row appears in exactly one output file
- Every row has a reason
- The grade is stated with the two lowest dimensions named

FAIL CLOSED IF
- The grade is below B. Report the grade and the two weakest
  dimensions. Do not pass a failing list downstream.
- icp.md does not exist. Do not filter against an assumed ICP.

WHY LOW EFFORT
This is classification across volume, not reasoning. Running it high
is where the cost advantage disappears. Keeping dropped.csv is what
makes the filter auditable when a client asks why a company was
excluded.

3. signal-research

---
name: signal-research
description: Find a dated, verifiable reason each prospect would buy
  now. Runs independently, good parallel delegation.
suggested-effort: high
---

# Signal Research

BOUNDED DELIVERABLE
filtered.csv with four columns added: signal, tier, date, source_url.

PRODUCE one signal per row, ranked by proximity to a budget decision.

TIER 1, budget is already moving
- Hiring for the role the offer replaces or supports
- Raised in the last 90 days
- New leader in post, last 60 days
- Publicly named the exact problem, last 30 days

TIER 2, the problem is visible
- Site or content shows the specific gap
- Expanding into a new market or location
- Competitor of an existing client

TIER 3, fit only, no observable trigger

DEFINITION OF DONE
- Every signal has a date and a URL
- Rows with no signal read NONE, not a stretched Tier 3
- Tier counts reported

FAIL CLOSED IF
- A row's only available signal is the company's industry. That is
  fit, not a signal. Write NONE.
- A source cannot be reached to verify a date. Write NONE rather
  than an undated signal.

Never stretch an attribute into a trigger. An undated signal is worse
than none, because it will be referenced in a first message and the
prospect will check.

4. outreach-sequence

---
name: outreach-sequence
description: Produce a node-by-node sequence spec with copy per
  branch. Structure plus judgement.
suggested-effort: high
---

# Outreach Sequence

BOUNDED DELIVERABLE
sequence-spec.md as a node list, plus merge prompts.

PER NODE specify: action, delay before it, exact copy, exit
condition.

RULES
- Under 300 characters on first touch
- Line one references the signal specifically, not its category
- One ask, answerable in under ten words
- Every touch a different angle. Never "just following up".
- Four touches maximum
- Reply stops the sequence, always
- A connection request auto-detects acceptance, so no wait node
  after one
- Any voice note pairs with a written message

BRANCH on connection state:
1st degree     message directly
Not connected  connection request, then message on acceptance

DEFINITION OF DONE
- Both branches have complete copy, not placeholders
- Character counts stated per message
- Daily send split stated against the account ceiling

FAIL CLOSED IF
- The signal column is empty for most rows. A sequence referencing
  a signal that does not exist is a template.
- The requested volume exceeds the account ceiling. State the
  ceiling and the required split rather than writing the sequence.

BANNED OPENERS, these are burnt:
"I came across your profile"
"I help [vertical] with [service]"
"Are you open to a quick chat"

The spec maps onto the Prosp builder directly. Actions: connection request, message, voice note, InMail, message to open profile, comment on last post, reply comment, like last post, visit profile, wait X days, add tag. Conditions: has LinkedIn URL, lead is 1st level, opened message, lead is open profile, check data in column.

The send ceiling the skill fails closed against is a real one: 20 connection requests a day and roughly 100 messages a week, account-wide rather than per campaign.

5. audit-production

---
name: audit-production
description: Produce a free audit of a prospect's business as an
  outreach wedge. Parallelises well across a list.
suggested-effort: high for the first, medium for the batch
---

# Audit Production

BOUNDED DELIVERABLE
audits/[company]-[YYYYMMDD].md, six sections, under 900 words.

SECTIONS
1. What they are doing well. Two genuine, specific things.
2. The thing costing them most. One finding, quantified only if the
   arithmetic is defensible from something observable.
3. Four more findings. Each: issue, evidence with URL, fix, effort.
4. What I would do first. ONE action they could take without us.
5. What this audit does not cover, and what access would be needed.
6. If you want the rest. Two lines and the price.

DEFINITION OF DONE
- Every finding cites an observable URL or screenshot
- Section 4 is actionable without engaging us
- Section 5 names at least two real limits
- Under 900 words

FAIL CLOSED IF
- Fewer than four findings have observable evidence. Report the
  count and skip this prospect. A thin audit is worse than none.
- The site is unreachable. Do not audit from the LinkedIn profile
  alone and present it as a site audit.

BATCH DISCIPLINE
Produce ONE at high effort and stop for acceptance before batching.
Do not produce fifty against an unvalidated template.

Section 4 must be usable without us. That is what makes it a gift
rather than a sales document, and it is the instruction most likely
to get softened.

6. proposal-assembly

Highest stakes in the set. Route at max and never delegate it low.

---
name: proposal-assembly
description: Assemble a client proposal from call notes. Single-shot,
  hard to unwind, highest stakes.
suggested-effort: max
---

# Proposal Assembly

BOUNDED DELIVERABLE
proposals/[company]-[YYYYMMDD].md, four sections.

INPUTS YOU MAY USE
- Call notes, including the problem quoted verbatim
- proof-library rows
- The price to quote and the budget signal

INPUTS YOU MAY NOT INFER
- Any number about their business they did not state
- Any result of ours not in proof-library
- Their internal timeline or approval process

SECTIONS
1. DIAGNOSIS. Reflect their problem in their own phrasing. Then the
   underlying cause, using why the last attempt failed. Then the
   cost of leaving it.
2. APPROACH. Phased. Per phase: what we do, what they receive as an
   object, roughly when. Phase one addresses why the last attempt
   failed. One line naming what we do NOT do.
3. SCOPE AND INVESTMENT. Branch on budget signal:
   named a figure -> ONE option at that price
   gave a range   -> TWO options, quote and 70% reduced scope
   dodged it      -> THREE tiers at ~70%, 100%, 140%
   no budget yet  -> ONE option plus paid discovery at ~15%
4. WHAT COULD GO WRONG. Two or three real risks, starting with the
   deal-killer they named. Each with what we do about it.

DEFINITION OF DONE
- Section 1 contains their actual words, not a paraphrase
- Every deliverable in section 3 traces to a phase in section 2
- Timeline in week ranges, never dates
- Payment terms and notice period stated

FAIL CLOSED IF
- The problem was not captured verbatim. Ask for it. The whole
  proposal converts on that quote.
- No budget signal was recorded. The section 3 branch cannot be
  chosen without it.
- A required proof point is not in proof-library. Leave the gap and
  flag it. Never fill it.

7. campaign-diagnosis

---
name: campaign-diagnosis
description: Diagnose which stage of a campaign is broken. Reasoning
  over conflicting evidence.
suggested-effort: xhigh
---

# Campaign Diagnosis

BOUNDED DELIVERABLE
report/week-[DATE].md containing the failing stage, the evidence, and
ONE change.

Work the chain IN ORDER. Stop at the first failure. Do not report six
stages of numbers when the first is broken.

1 ACCEPTANCE BELOW 15%
  The connection note, or the list is off-ICP. Not the sequence.
2 ACCEPTANCE FINE, REPLIES BELOW 10%
  The list is fine. The first message is the problem.
3 REPLIES FINE, MEETINGS LOW
  The ask is mistimed, or the offer is wrong.
4 MEETINGS FINE, PROPOSALS NOT CONVERTING
  Not an outreach problem. Price or offer fit.
5 ALL FINE, VOLUME LOW
  Capacity-limited on sends. Check the daily split.

DEFINITION OF DONE
- One stage named, with the numbers that identify it
- Exactly one recommended change
- Any kill criteria checked against their date

FAIL CLOSED IF
- The figures are incomplete. Name which stage cannot be assessed.
  A diagnosis on partial data points at the wrong stage.
- More than one stage appears to be failing. Report the earliest
  only. Fixing a later stage while an earlier one is broken teaches
  you nothing.

Never recommend more than one change per week. Never soften a kill
recommendation; the criteria were set in advance precisely so this is
not a judgement call.

8. deliverable-review

The fresh reviewer. Runs read-only, on work it did not produce. Full detail on the next page.

---
name: deliverable-review
description: Read-only review of an accumulated deliverable set.
  Returns exactly one of three verdicts.
suggested-effort: high
---

# Deliverable Review

You did not produce this work. Do not defend it.

BOUNDED DELIVERABLE
A verdict plus the findings behind it. You change nothing.

INPUT
The complete accumulated change set, plus each deliverable's stated
definition of done.

CHECK, per deliverable
- Does it meet its own definition of done, line by line
- Does any claim lack a traceable source
- Any number not present in the inputs
- Any fail-closed condition that should have fired and did not
- Anything a client would query on first read

RETURN EXACTLY ONE VERDICT
ship        Meets every definition of done. Accept.
fix-first   Specific, listed defects. Requires a new parent
            verification AND a fresh review afterwards.
rethink     The approach is wrong, not the execution. Requires a
            revised plan, not edits.

There is no fourth verdict. "Mostly fine" is ship or fix-first, and
you must choose.

List the five most significant findings regardless of verdict, even
on ship. A clean review with no observations means you did not look.

The gate is the reason the pattern is worth porting. Astra inspects the complete output, reruns the requested checks, then hands the accumulated set to a fresh read-only reviewer. Work is accepted only on ship.

Most agencies have no gate at all. The person who made the thing decides it is finished.

The three verdicts

Verdict	Means	What happens next
ship	Meets every definition of done	Accepted. It goes to the client.
fix-first	Specific listed defects	New parent verification AND a fresh review afterwards. Not a quick edit and out.
rethink	The approach is wrong, not the execution	A revised plan. Editing will not fix it.

There is no fourth verdict, and that is the design. "Mostly fine" is where agency quality dies, because it means shipped with known defects and nobody accountable for which ones.

The fix-first loop is stricter than it looks. Fixing and shipping is not allowed. It goes back through parent verification and then to a fresh reviewer, because the reviewer who listed the defects now has an interest in their fix being adequate.

Why the reviewer must be fresh

A model asked to review its own output defends it. Same as a person.

The repo's approach is a fresh read-only reviewer, which can be any of the three supported models at a live-supported effort. Read-only matters as much as fresh: a reviewer that can edit will fix small things silently and you lose the signal about how often the producer gets it wrong.

For agency work the practical version:

Spawn a fresh reviewer with no history of this task.

Read-only. You change nothing.

Input: the complete accumulated deliverable set, plus each item's
stated definition of done.

You did not produce this work and you have no stake in it shipping.
Review it as a skeptical expert reviewing someone else's work.

Return exactly one of: ship, fix-first, rethink.

List the five most significant findings regardless of verdict.
A clean review with no observations means you did not look.

The last line stops the empty approval. A reviewer that returns ship with nothing to say has not read it.

The client-facing version

The gate is also a sellable process, which is unusual for an internal QA step.

What a client sees, per deliverable:

Deliverable      Definition of done met      Verdict    Reviewed by
icp.md           6 of 6 sections             ship       fresh, high
filtered.csv     grade B+, both files        ship       fresh, low
sequence-spec.md 2 defects, fixed, re-run    ship       fresh x2
proposal.md      4 of 4 sections             ship       fresh, max

The fresh x2 row is the one that builds trust. It says something was caught, fixed, and re-reviewed before they saw it, which is more reassuring than four clean rows.

In regulated verticals this is worth more than the work itself. Health, finance and insurance buyers are not looking for the cheapest agency, they are looking for one with a documented gate.

Fail closed, always

The repo's most transferable rule: if a model, effort, control or tool is unavailable, conflicting or unobservable, fail that delegation and report the limitation. Never silently substitute a model, effort, role, or fabricated tool.

The GTM translation, and the four places it matters most:

1. Missing proof. A required case study is not in the proof library. Leave the gap and flag it. Never fill it.
2. Missing verbatim. The client's problem was not captured in their own words. Ask for it rather than paraphrasing from memory.
3. Unverifiable signal. A date cannot be confirmed. Write NONE rather than an undated trigger that a prospect will check.
4. Volume over ceiling. The requested send volume exceeds the account limit. State the ceiling and the split rather than writing a sequence that will get the account restricted.

In each case the failure mode without the rule is the same: something plausible, produced confidently, that a client or prospect can disprove.

Running the whole thing

Use $astra-advisor:orchestration to plan, build, verify, and review
this work.

GOAL: a launch-ready outbound system for [CLIENT], every output in
clients/[CLIENT]/.

Available skills: icp-derivation, list-qualification,
signal-research, outreach-sequence, audit-production,
proposal-assembly, campaign-diagnosis, deliverable-review.

Route each to a model and effort you choose. Announce the name,
bounded task, selected model and effort, and the selection reason for
every delegation. Report chosen and runtime-confirmed values
separately, or say they are unobservable.

Delegate what runs independently and keep working on the rest.

Stop for my acceptance at two points:
- After icp-derivation, before any list work
- After ONE sample audit, before batching

Then inspect the complete set, rerun each deliverable's definition of
done, and send the accumulated set to a fresh read-only reviewer.
Accept only on ship.

End with the cost receipt and the coverage it can honestly claim.

Every task ends with an API-equivalent cost receipt. For an agency that is a per-deliverable margin number, which most agencies do not have at all.

The caveats matter as much as the number, and they go in the same document.

What the receipt actually claims

Where native tools expose token usage, the receipt estimates the USD price against a versioned pricing snapshot, then compares the same token workload repriced entirely at Astra.

It separates three coverage levels and does not blur them:

• Whole-task. Parent and reviewer usage both observed.
• Delegated-only. Subagent usage observed, parent not.
• Partial. Some calls observed.

Missing parent or reviewer usage prevents a whole-task claim. Without observed usage at all, the receipt states why it is unavailable rather than estimating.

The snapshot records official source URLs and standard short-context USD rates per million tokens, verified on 4 September 2026. These are historical estimates and Sol pricing is promotional, so it may change.

What it does not claim

This is the part to read twice before putting a number in front of a client.

The comparison is a same-token API price comparison. It does not measure:

• What an all-Astra run would actually consume
• Actual net task savings
• Quality or speed
• Any change to subscription charges or usage credits

Two further constraints worth knowing. No subagents means no delegation savings, so a task Astra chose not to delegate has nothing to compare. And reasoning effort does not multiply the token price, so routing something at max is not automatically more expensive than medium.

The calculator also refuses rather than assumes: it rejects unsupported long-context, service-tier and cache-write cases, refuses overlapping aggregates, and keeps unknown usage separate from zero. It supports at most 128,000 input tokens per call as an implementation boundary, not a claimed official threshold.

The per-client margin sheet

What receipts give you that hourly tracking never did: cost per deliverable, per client, comparable across months.

CLIENT: [name]        MONTH: [YYYY-MM]        RETAINER: [amount]

Deliverable       Model / effort   Coverage      Est. cost
icp.md            terra / xhigh    whole-task    $
filtered.csv      luna / low       whole-task    $
signals           sol / high       delegated     $
sequence-spec.md  terra / high     whole-task    $
audits x12        luna / medium    partial       $
proposal.md       sol / max        whole-task    $
reviews x6        varies           whole-task    $
                                                 -------
                                   Delivery cost $
                                   Retainer      $
                                   Margin        $

Coverage notes: [which rows could not claim whole-task, and why]

The coverage notes line is not optional. A margin figure built partly on partial coverage is an estimate, and labelling it as one is what makes it usable in a pricing conversation rather than a liability in one.

The row that will surprise you is audits x12. Batch production at medium effort is usually the cheapest line on the sheet and the one that generates the most pipeline, which is an argument for producing more of them rather than fewer.

Pricing decisions receipts unlock

Three things you can only decide with per-deliverable cost in front of you.

Which deliverables to include for free. If the weekly report costs cents to produce, including it lifts perceived value at almost no cost. Guessing at that leads to either giving away the expensive thing or charging for the cheap one.

Where the retainer floor actually is. Delivery cost plus review cost plus the human hours you cannot remove. Below that number the client is unprofitable regardless of how the work goes.

Whether a client is worth keeping. The account that needs three fix-first loops per deliverable costs multiples of the one that ships first time, and until you can see it per deliverable that difference is invisible.

One warning. Do not price a retainer on the delegation saving. It is a same-token comparison, not a guarantee, and Sol pricing is promotional. Price on your real delivery cost and treat any saving as margin.

Where this hands off

Everything above produces files and a receipt. Nothing above reaches a prospect.

The outreach-sequence skill outputs a spec, and the spec has to run somewhere. Prosp is the send layer: cloud-based so it does not depend on a session staying open, a free dedicated residential proxy per connected account, and activity paced under the platform's thresholds. Setup is about five minutes, free trial, no card.

The fail-closed discipline carries across. The ceiling the sequence skill checks against is real: 20 connection requests a day and roughly 100 messages a week, account-wide rather than per campaign. Three campaigns at 20 each means 60 attempts a day and a restricted account, which is the outreach equivalent of shipping without a review.

For multi-client work: one account per client profile, each created in its own browser session, all managed from one workspace, with white-label domain and a sub-workspace per client. The unified inbox spans accounts with filters for campaign, replied and unread, so reply handling runs over one queue.

Three things to remember

1. One acceptance owner, and it is never the thing that produced the work. The fresh read-only reviewer is the whole pattern.
2. Fail closed. Missing proof, missing verbatim, unverifiable signal, volume over ceiling. In every case, stop and report rather than produce something plausible.
3. Chosen is not confirmed. Report both separately, and let the receipt claim only the coverage it can honestly support.

Astra builds and verifies it. Prosp runs the half that reaches people 💜

↳ Start a 14 Day Free Trial 💜 ↳ Watch Full Tutorial ▶️