Model calls have no hook: 5 cases, and a proposed modelCallRequest / modelCallResult pair

[President]

In short:

• An agent calls a model many times in one task. Some calls are the main work. Others are helpers: a chat title, a summary of old messages, a memory note, a search query, an embedding.
• ACS has no hook at a model call. The Guardian sees the pieces (user message, tool result), but never the full request the agent sends to a model, or which model gets it.
• Proposal: 2 optional hooks. steps/modelCallRequest fires before a model call. steps/modelCallResult fires after it. Field names follow OpenTelemetry (OTel) GenAI. Message text is off by default.
• The 5 cases below answer the reopen condition in [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122.

Where this comes from: #122, NVIDIA #402, the AGT reference implementation, #123 / #124

• [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122 (14 Sep, still open) asked for a hook before the model call so the Guardian could rewrite the prompt. @rocklambros explained why not. @rocklambros left [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122 open for a reply and set a condition ("per-source provenance" is the record of where each input came from):

  "Reopen when a harness exposes a pre-dispatch event and someone can demonstrate a decision that cannot be made from per-source provenance today."

• @MKaptein answered both parts in [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122:

  • A decision that provenance alone cannot support: "customer data may go to the in-house model, not to the external one" (comment).
  • Two harnesses with an event before the model call: LangChain and Google ADK (comment).

• NVIDIA-labs Object Oriented Agents (NOOA) #402 (29 Sep, opened by @rocklambros):

  "There's a gap on our end too. ACS has no model-invocation hook. [...] We map nothing there."

• The ACS reference implementation with Microsoft's Agent Governance Toolkit (AGT) lists the same gap (README):

  "Two AGT intervention points, pre_model_call and post_model_call, have no ACS v0.1.0 method. Whether this project proposes steps/modelCall for ACS v0.2 is open."

  In mapping.yaml, both points are "unexpressed at every verdict".

• Cost ceilings were requested in discussion #123 and [Proposal] Per-turn model usage on the wire, so a Guardian can enforce cost ceilings #124. Both propose usage after the turn (turnEnd). [Proposal] Per-turn model usage on the wire, so a Guardian can enforce cost ceilings #124 also notes: "The Guardian cannot estimate usage itself because it never sees the assembled prompt ([Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122)."

Where hooks fire today

The picture shows one agent at work. ✅ marks a place where an ACS hook fires. ❌ marks a place where data leaves the agent and no ACS hook fires.

flowchart LR
    U1["User"] -->|"userMessage ✅"| H["Harness<br/>builds each request"]
    K[("Knowledge base / memory")] -->|"knowledgeRetrieval ✅<br/>memoryContextRetrieval ✅"| H
    H -->|"main call and its answer ❌"| M["Model provider<br/>external or in-house"]
    H -->|"helper calls ❌"| M2["Same or another provider:<br/>title, compaction, memory,<br/>query rewrite, embeddings, judge"]
    H -->|"toolCallRequest ✅<br/>toolCallResult ✅"| T["Tools"]
    H -->|"agentResponse ✅"| U2["User"]

Loading

The 5 cases below are about the ❌ arrows.

5 cases

1. Where the data goes

Rule: "customer data goes only to our own model". ACS cannot check this rule: it does not see which model gets each call.

Details and code

The model can change on every call, not only once per session:

• NOOA picks the model per request: "Return the model this individual request will actually dispatch" (code).
• Codex picks the memory-extraction model from memories.extract_model, or else the provider's preferred extraction model (code).
• OpenCode can use separate models for titles (code) and for compaction (code).
• Embeddings: LlamaIndex sends the query text to the embedding provider (code).
• An LLM judge: LiteLLM sends the conversation, including tool output, to judge_model (code).

What ACS has today:

• sessionStart has no model field.
• AgBOM (the Agent Bill of Materials, the inventory of the agent's components) lists the models the agent can use. A Guardian can refuse a whole session that has a banned model. AgBOM does not show which model a particular call uses.
• subagentStart names a model per subagent, not per call.
• acs.model_id in the trace identifies the Guardian's own evaluator model.

Missing: where each call goes, and a way for the Guardian to block the call. A request to an external provider crosses a trust boundary. Under principle 3(b), a field belongs on the wire when it "marks a real trust-boundary crossing".

2. Cost before the call

Rule: "stop the call that goes over budget". ACS cannot check this rule: it sees a turn only after the turn ends, when the money is already spent.

Details and code

• The harness knows the request size only after building the request from system instructions, history and tool definitions. max_tokens limits only the answer.
• turnEnd already exists. The step_count field is described as "useful for per-turn rate-limit policies and [...] resource accounting". BUT turnEnd fires after the money is spent.
• Scope: the README says a Guardian can "inspect what an AI agent is about to do and permit, deny, or modify that action before it happens". A model call is an action the agent is about to take.
• Unbounded Consumption is in the OWASP Top 10 for LLM Applications, as cited in discussion #123.
• Budget rules stay with vendors. The standard only defines when the harness asks the Guardian and what the harness sends.
• Proposed field: estimated_input_tokens. preCompact already uses that name for the region about to be compacted. In the proposed hook, estimated_input_tokens describes the outgoing request size.

3. Hidden calls

Helper calls (title, search query, memory note, embedding, LLM judge) also send data to a model. No ACS hook fires for them.

Details and code

• session title: OpenCode (code)
• query rewrite: LangChain history-aware retriever (code)
• tool selection: LangChain LLM tool selector (code)
• memory extraction: Codex (code)
• compaction summary: ADK (code), NOOA (code)
• embeddings and an LLM judge: see case 1

Some hooks see the results later:

• knowledgeRetrieval fires with retrieval results. The query has already gone to the embedding provider.
• postCompact receives the summary after the summarizer call.

Missing: a check on the helper call itself.

4. Tool text in the system prompt

Some frameworks put text from a tool or from memory into the system prompt or a developer message. The model trusts these parts most. No ACS hook sees this.

Details and code

Policy: "text from tools or retrieval never goes into the system or developer role".

• ADK: on every model call, ADK fills {key} placeholders in the agent instruction from session state (code). When the agent has no static_instruction, the completed instruction is added to the system instruction (code). A tool can write session state (ToolContext.state). A tool output can therefore reach the system instruction. toolCallResult sees the tool result. toolCallResult does not see the state write or the instruction.
• Codex: Codex adds the memory summary as a developer-role message (code, role). memoryContextRetrieval carries the text and provenance. No hook identifies the role assigned to the text. The memoryContextRetrieval payload has only query, memory_store and results.

The text keeps its provenance, but it enters the instruction role. In ACS terms, untrusted content is then "treated as if it were attested" (trust.md). This happens inside the harness, where no hook sees the role. Principle 2, item 6, asks whether the wire matches "where boundary crossing and trust-laundering actually occur". This is one such place.

Existing protections:

• Codex marks the memory as historical context, with delimiters (code).
• Compaction already preserves source lineage through preCompact / postCompact.

The proposed hook covers case 4 only when content is on. With content on, the Guardian can deny the call or remove the text with redactions. With content off, which is the default, the Guardian never gets the text.

5. Which model answered

A provider can answer with a different model than the one the agent asked for. ACS does not record which model answered, and cannot block that answer.

Details

• OTel records the answering model in gen_ai.response.model.
• There are 2 needs:
  • An audit record of the answering model. The ACS OTel and OCSF mappings (otel-mapping.json, ocsf-mapping.json) have no field for the answering model.
  • A way for the Guardian to reject an answer from an unapproved model before the harness uses the answer.

Who has which hook: 13 frameworks, checked in source

Checked in source on 20-21 Oct 2026. Every code link is pinned to a commit.

Framework	Before the call	Can stop or change it	After the call	Model in the hook	Text
NVIDIA NOOA	llm_call middleware	yes	same middleware	yes (client + params)	yes
LangChain agents	wrap_model_call, before_model	yes	after_model	model object	yes
Google ADK	before_model_callback	yes	after_model_callback	yes	yes
OpenAI Agents SDK	on_llm_start, call_model_input_filter	filter changes input; hook stops only by raising	on_llm_end	only via agent.model (RunConfig can override it)	yes
Pydantic AI	before_model_request, wrap_model_request	yes	after_model_request	model + provider	yes
Vercel AI SDK	transformParams, wrapGenerate, wrapStream	yes	wrappers	provider + model	yes
CrewAI	before_llm_call	yes (False blocks)	after_llm_call	LLM object	yes
Semantic Kernel (.NET)	OnPromptRenderAsync	yes	IFunctionInvocationFilter (per function, not per model call)	service ID	rendered prompt
LlamaIndex	LLM start event	observe only	end event	model metadata	yes
Claude Agent SDK (Python)	none per model call	-	-	-	-
Microsoft AGT (policy engine)	pre_model_call	yes	post_model_call	what the host puts in the snapshot	what the host puts in the snapshot
LiteLLM (gateway)	async_pre_call_hook	yes	async_post_call_success_hook	yes	yes
NVIDIA OpenShell (sandbox)	HTTP request check	yes, on HTTP traffic	HTTP response	from traffic	bytes, no framework context
ACS v0.1.0	none	-	none	-	-

A hook gives a framework a place to run a check. A hook does not automatically catch every model call:

• The ADK summarizer calls the model directly.
• The LangChain tool selector bypasses the agent middleware.
• NOOA sends compaction calls through the same llm_call middleware. The middleware sees the compaction call but cannot rewrite the compaction prompt (code).

The NOOA example shows that a harness can route helper calls through a model-call hook.

Why the check belongs in ACS

Model calls can also be checked outside ACS: by an LLM gateway in the network, or by settings inside the agent framework (for example, a spending limit). But then ACS checks the other actions of the agent, and not model calls. Model calls get their own rules, somewhere else.

All places compared

Where the check runs	What it sees	Problem
LLM gateway on the network	the calls routed through it	No harness context: which case, which data, which provenance. A separate policy and a separate audit trail from ACS.
The harness's own settings (spending limit, model list)	what each harness author built	The agent checks itself, with no independent decision. Each harness has its own format. No ACS audit record.
New fields on existing hooks (model on sessionStart, prompt in userMessage)	the session, not each call	A session field does not name each call's model. userMessage would carry instructions, history and tool output, not only user input.
Trace only (model name in the trace)	the call, after it happened	Records the answering model (case 5). Cannot block anything, so cases 1-4 and the reject need in case 5 stay open.
ACS hook pair (proposed)	every model call, with harness context	Relies on an honest harness, like every ACS hook.

Case	ACS today	With the 2 hooks	Still not covered
1. Where the data goes	no (sessionStart has no model; AgBOM is an inventory)	yes: model, provider and address for each call	server.address can be a proxy. The final provider behind it needs a defined way to learn it
2. Cost before the call	after the fact (turnEnd)	yes, with estimated_input_tokens or with the content	the Guardian can't verify the estimate
3. Hidden calls	partly, after the fact (knowledgeRetrieval, postCompact)	yes, if the harness fires the pair for every helper call	calls the harness doesn't instrument
4. Tool text in the system prompt	text and provenance yes, role no	yes, when content is on	-
5. Which model answered	no	yes	-

A compromised harness skips any hook. An LLM gateway is still useful as a second layer for that case, but it cannot replace the hook, because it does not receive the framework's context.

The proposal

• 2 hooks: steps/modelCallRequest before every model call, steps/modelCallResult after it. Helper calls too.
• Both are optional, like other ACS hooks.
• The Guardian can allow, block or change the call. It uses the modifications object ACS already has.
• Field names follow OTel GenAI. Message text is off by default.

The details: decisions, fields, and the 2 messages in JSON

• A harness that lists both methods in methods_implemented MUST fire both hooks for every model call, including helper calls.
• The harness treats methods absent from the Guardian's methods_evaluated list as allowed (handshake.json).
• Decisions: allow, deny or modify, as on toolCallRequest. "Modify" uses the existing modifications object. No new wire element is needed:
  • parameter_overrides changes a call field. For example, an override can send the call to the in-house model or lower max_tokens.
  • redactions replaces text in a message part at a JSON pointer, a path to a value in JSON. For example, /content/input_messages/1/parts/0/response identifies the tool output in the example below. Redactions work only when content is on.
• The Guardian can also modify the result with the same object before the harness uses the result.
• Field meanings come from the OTel GenAI client inference span, the trace record for a model call. For operation: embeddings, field meanings come from the embeddings span. Each field takes its meaning from OTel or from an existing ACS hook, and messages use OTel's JSON format. The long OTel names appear only in the ACS trace mapping. The existing mapping from tool.name to gen_ai.tool.name follows the same pattern.
• Content means the prompt, messages, tool definitions and answer. Content is off by default, following OTel's Opt-In approach.
• The harness converts each provider's format (OpenAI, Anthropic, Gemini) to the OTel format. The Guardian does not need to know every provider format.

steps/modelCallRequest, before the call

{
  "jsonrpc": "2.0",
  "method": "steps/modelCallRequest",
  "id": "42",
  "params": {
    "acs_version": "0.1.0",
    "request_id": "7c1e0000-0000-4000-8000-000000000001",
    "timestamp": "2026-10-21T15:04:05Z",
    "metadata": {
      "agent_id": "coding-agent",
      "session_id": "9f3a0000-0000-4000-8000-000000000003",
      "turn_id": "t-7"
    },
    "payload": {
      "operation": "chat",
      "model": { "name": "gpt-4.1-mini", "provider": "openai" },
      "server": { "address": "api.openai.com", "port": 443 },
      "max_tokens": 1024,
      "temperature": 0.2,
      "stream": true,
      "estimated_input_tokens": 18234,
      "content": {
        "system_instructions": [
          { "type": "text", "content": "Summarize the conversation..." }
        ],
        "input_messages": [
          { "role": "user", "parts": [ { "type": "text", "content": "..." } ] },
          { "role": "tool", "parts": [ { "type": "tool_call_response", "id": "call_1", "response": "..." } ] }
        ],
        "tool_definitions": [ { "type": "function", "name": "read_file" } ]
      }
    },
    "signature": { "algorithm": "HMAC-SHA256", "value": "...", "key_id": "..." }
  }
}

steps/modelCallResult, after the call

{
  "jsonrpc": "2.0",
  "method": "steps/modelCallResult",
  "id": "43",
  "params": {
    "acs_version": "0.1.0",
    "request_id": "8d2f0000-0000-4000-8000-000000000002",
    "timestamp": "2026-10-21T15:04:07Z",
    "metadata": {
      "agent_id": "coding-agent",
      "session_id": "9f3a0000-0000-4000-8000-000000000003",
      "turn_id": "t-7"
    },
    "payload": {
      "request_id_ref": "7c1e0000-0000-4000-8000-000000000001",
      "exit_status": "success",
      "model": { "name": "gpt-4.1-mini-2025-04-14" },
      "response_id": "chatcmpl-123",
      "finish_reasons": ["stop"],
      "usage": {
        "input_tokens": 18190,
        "output_tokens": 412,
        "cache_read_input_tokens": 16000,
        "cache_write_input_tokens": 0,
        "reasoning_output_tokens": 0
      },
      "content": {
        "output_messages": [
          { "role": "assistant", "parts": [ { "type": "text", "content": "..." } ] }
        ]
      }
    },
    "signature": { "algorithm": "HMAC-SHA256", "value": "...", "key_id": "..." }
  }
}

• The result does not repeat the provider, address or settings. request_id_ref links the result to the request, as on toolCallResult.
• model.name in the result identifies the model that actually answered (case 5).
• A failed call gets "exit_status": "failure" and an error_type.

Fields

ACS field	OTel attribute	Required in ACS
modelCallRequest
operation (chat, embeddings, ...)	gen_ai.operation.name	yes
model.provider	gen_ai.provider.name	yes
model.name	gen_ai.request.model	when known
server.address, server.port	server.address, server.port	recommended
max_tokens, temperature, stream	gen_ai.request.max_tokens, gen_ai.request.temperature, gen_ai.request.stream	when set
estimated_input_tokens	none in OTel; the name comes from preCompact, applied to the outgoing request	optional
content.system_instructions, content.input_messages, content.tool_definitions	gen_ai.system_instructions, gen_ai.input.messages, gen_ai.tool.definitions	only when content is on
modelCallResult
request_id_ref, exit_status	none in OTel; same as toolCallResult	yes
error_type	error.type	on failure
model.name	gen_ai.response.model	recommended
response_id, finish_reasons	gen_ai.response.id, gen_ai.response.finish_reasons	recommended
usage.input_tokens, usage.output_tokens	gen_ai.usage.input_tokens, gen_ai.usage.output_tokens	recommended
usage.cache_read_input_tokens, usage.cache_write_input_tokens, usage.reasoning_output_tokens	gen_ai.usage.cache_read.input_tokens, gen_ai.usage.cache_write.input_tokens, gen_ai.usage.reasoning.output_tokens	when the provider reports them
content.output_messages	gen_ai.output.messages	only when content is on

Questions we expect, with answers

• "The model is fixed per session, so sessionStart is enough." A fixed model is common for the main call. Helper calls and per-call routing can use different models (case 1).
• "ACS already has granular hooks. One hook for every model call is too coarse." The existing hooks check individual inputs and outputs. None of the existing hooks checks the model call. One pair with an operation field follows the pattern of toolCallRequest, which covers every tool. The format for stating a call's purpose remains an open question below.
• "The assembled prompt is a userMessage." userMessage "Fires when external user input arrives", with "Provenance: origin: user_input". The assembled request also contains instructions, history and tool output. Treating the assembled request as userMessage would change the boundary between user input and the full model request.
• "Why not send model calls through toolCallRequest?" toolCallRequest fires "after the framework has parsed a tool call from the LLM's output". A model call is not a tool call parsed from model output. Tool policies would also have to tell model calls apart from tool calls.
• "Cost is not security." See case 2.
• "An extra round trip on the hottest path." Both hooks are optional for the harness and the Guardian. A Guardian does not evaluate methods absent from methods_evaluated. The harness treats those methods as allowed. As @MKaptein noted in [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122, a tool call already has 2 round trips. A model call itself usually takes seconds.

Open questions

• One call or one attempt? Does each retry to the provider get a separate pair of hooks? Or does one pair cover the call and all retries?
• Streaming. The Guardian can deny an answer only while the harness still holds the answer. The first version checks the complete answer. Checks on each streamed chunk need a separate design.
• Turning content on. The handshake has no way yet to agree on whether to send content.
• Purpose of a call. How does a call state its purpose: title, compaction or memory? How does the call link to preCompact or memoryStore?
• Provenance of content. Under provenance_producer: deterministic, where do the source records for each message part go?
• Modify. Today parameter_overrides is "keyed by argument name" of a tool. parameter_overrides needs a rule for model call fields. A change early in the prompt also breaks the provider's prompt cache. Breaking the prompt cache increases the call's cost.
• Delay. The added delay has not been measured.
• OTel GenAI is still "Development". ACS would pin one exact version, as ACS does for OCSF.

Questions to decide

1. Is it enough to log model calls? Or should the Guardian also be able to block a model call?
2. Should ACS check model calls? Or should LLM gateways and agent frameworks do it?
3. Should ACS check cost before a model call?

[MKaptein]

Thanks @President, this is a clear write-up, and I am happy to support the two hooks.

One small note from my side, mostly to say where I think the strongest case is: the hook as a record of where the assembled context goes and how big it is. model.provider and server.address on modelCallRequest are what no existing hook carries today, and the example from my earlier comment on #122, customer data only to the in-house model, needs just those two fields. So content off by default seems the right default to me, and cases 1, 2, 3 and 5 all work with it off.

On the gateway question in the open points, perhaps one argument helps: a gateway sees the request but not the steps that came before it, and the Guardian sees the steps but not the request. The hook is what lets one place see both.

The OTel GenAI names and leaving the provider mapping to the harness both make sense to me. Thanks for putting this together!

[rocklambros]

@President, I checked this against the spec on integration and ran both JSON examples through the schemas. My short answer is that ACS already covers more of these cases than the post says, but the post is right about the core gap. I'd support a narrower version of the request hook.

ACS already has three checks the post doesn't count:

• preCompact fires before the compaction call, and a Guardian can deny it there. It already carries estimated_input_tokens. Compaction is therefore a helper call that ACS can check before the data goes out today.
• Every model in the AgBOM must list a provider and an endpoint (agbom/component.json). A Guardian can deny agbom/snapshot when a session includes a banned model, and it can deny agbom/changed to stop a model swap mid-session. The rule "customer data only goes to our own model" is enforceable today for any session that uses only one model.
• turnStart lets a Guardian block a turn before it starts, so ACS has a pre-spend gate at the turn level.

The post is right about these gaps:

• No hook says which model a single call goes to. That matters when one session uses both an in-house model and an external one, and the AgBOM can't handle that case.
• No hook records which model answered.
• No hook carries token usage. turnEnd has only step_count and tool_call_count, so the table's "after the fact (turnEnd)" for cost gives ACS credit for data it doesn't have.
• Nothing records which role (system, developer or user) a piece of text lands in.

Before this turns into a spec PR, I'd want these changes:

1. Please explain how the new hook relates to toolCallRequest. hooks.md says frameworks MUST fire toolCallRequest for every action that leaves the agent's reasoning context, including network fetches. A call to an external embedding or judge model could fall under that rule, so a harness might fire both hooks or neither.
2. Please also say how the new hook relates to preCompact. Without a rule, a Guardian can allow a compaction in one hook and deny the same compaction in the other.
3. The MUST to fire for every helper call can't be met, and the post shows why: the ADK summarizer and the LangChain tool selector skip their own middleware. A SHOULD for calls the harness can see is honest about that limit.
4. Retries need a rule. If the in-house model fails and the harness falls back to an external one, the Guardian approved a different destination than the one that got the data. I'd require a new modelCallRequest with a new request_id whenever the provider, model or address changes.
5. parameter_overrides is defined as "keyed by argument name" for tool arguments, so the existing object doesn't cover rerouting a model call. Rerouting also needs an allowlist on the harness side. Without one, a bad Guardian response can send the full context and the provider API key to any host.
6. The request example sets "stream": true. A deny on modelCallResult can't take back tokens the user has already seen. I'd make the result hook audit-only while streaming, unless the harness buffers the full answer.
7. I'd leave content mode out of v0.2. For case 4, a list of {role, provenance_ids} for each message part tells the Guardian the role without sending any text. That list works with content off, and it avoids sending every system prompt to the Guardian.

The proposal should also address these risks:

• With content on, the Guardian receives every system prompt, secret and piece of customer data in the context, on every call. The spec has no data-minimization rule for hook payloads, and handshake.json still allows plain http as a transport. If the Guardian uses an external model to evaluate calls, the control meant to keep customer data in-house sends that data out itself.
• The default on_decision_failure is proceed, which is fail-open. An attacker who can plant a very large tool output can push the request past max_payload_size_bytes or the Guardian timeout, and the model call then goes out unchecked. The fail-closed choice, deny, stalls every model call whenever the Guardian is slow. The proposal should say which posture case 1 needs.
• MCP sampling is also a model call. extend_mcp.md says every MCP surface other than tools/call MUST be wrapped, but the spec never mentions sampling. A harness could fire both protocols/MCP/* and modelCallRequest for the same call, and nothing says which decision wins.
• Neither shipped reference host can fire these hooks today. The Claude Code host maps only PreToolUse and PostToolUse, and the OpenCode host maps only tool.execute.before and tool.execute.after. The spec would get a hook that no ACS reference host can show working.
• I wrote the reopen condition in issue [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122, so I'll be direct about it. Cases 1 and 5 meet the condition, because nobody can work out a per-call destination or the answering model from provenance. Case 2 is about cost, not provenance, so it needs its own scope discussion alongside issue [Proposal] Per-turn model usage on the wire, so a Guardian can enforce cost ceilings #124. Case 4 needs content on and Guardian edits through redactions, which is the prompt rewrite issue [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122 declined. I'd keep case 4 under issue [Proposal] No preLLMCall hook to inspect/rewrite the assembled message context before LLM dispatch #122 until there's a design for provenance on each message part.

A few smaller points came out of the schema check:

• Both examples pass request-envelope.json, but that check proves little because the envelope doesn't constrain payload.
• toolCallRequest allows ASK and DEFER as well as allow, deny and modify. The proposal should say whether a model call allows them too.
• toolCallResult.exit_status also has timeout and blocked.
• In preCompact, estimated_input_tokens counts only the region being compacted, not the whole request. A different name for the request size would avoid confusion.
• I'd limit operation to chat, text_completion and embeddings. The OTel list also has retrieval and execute_tool, and those would duplicate knowledgeRetrieval and toolCallRequest.

The smallest version I'd back is modelCallRequest with operation, model.name, model.provider and server.address, with allow and deny as the only decisions and no content. On the result side, I'd add the answering model and usage as audit fields. The usage fields should line up with issue #124 so ACS doesn't end up with two usage objects.

No issue tracks this hook pair yet. Issue #122 asks for inspecting and rewriting the prompt, and issue #124 covers per-turn usage. Could you open a new proposal issue for the narrowed hook pair and link this discussion, issue #122 and issue #124? A proposal issue gives the leads one place to triage it.

[MKaptein]

Thanks for the careful check!

The smallest version at the end, modelCallRequest with operation, model.name, model.provider and server.address, allow / deny only, no content, and the answering model plus usage as fields on the result, actually covers what I was after.

Effectively, whether it gets a hook of its own or is simply included as additional info in the existing toolCallRequest matters less to me than the simple fact that every call to a model is broadcast. Finally, a different name than estimated_input_tokens for the request size is fine by me.

[afogel]

I agree with @rocklambros, I'm not persuaded here that query rewrite, embeddings, judge are not tool calls. Moreover, like @rocklambros mentioned, we do already have compaction. For memory and skills, they might merit their own hooks, but many harnesses don't support those as individual hooks and instead label them as tool calls. For a threat scenario where multiple models are used, I think allowing optional fields for model.name and model.provider should be enough to cover this.

In short, I don't think there's a sufficiently strong case made here that justifies the tradeoffs of the large spec changes necessary to introduce a new, separate hook to be supported, at a coarser grain than other lifecycle hooks. I believe ACS has a flexible enough hook vocabulary to cover the proposed lifecycle events.

[bar-capsule]

Thanks @President for the detailed write-up, and @MKaptein for the use case. I agree the gap is real, but I wouldn't make this required, for two reasons:

1. Most popular coding agents can't fire it. Claude Code's hooks docs list 33 events and none fires per model request; the closest are PreModelSwitch / PostModelSwitch and a model field on SessionStart. Cursor, Codex and Copilot have no model-call hook either. Gemini CLI (BeforeModel / AfterModel) and frameworks like ADK, LangChain, CrewAI and Pydantic AI do.
2. Most of the cases already map to existing hooks: the session's model (sessionStart and the AgBOM), a model swap (agbom/changed), compaction (preCompact), and embedding or judge calls the harness runs as tools (toolCallRequest).

So here's what I'd suggest, with no new hook:

• An optional model object (name, provider, server_address, following the OTel GenAI names) on turnStart, preCompact and toolCallRequest. On turnStart it tells the Guardian where the turn's model calls go, so it can deny the turn before any data leaves. A Claude Code host can fill it from SessionStart and PostModelSwitch.
• An optional, audit-only response_model on turnEnd for the model that actually answered, next to the usage object [Proposal] Per-turn model usage on the wire, so a Guardian can enforce cost ceilings #124 proposes, so both land together.
• Hosts SHOULD fill these when they know them.
• A dedicated modelCallRequest stays on the table for later, for harnesses that switch models inside a single turn, once a reference host can fire it per request.

@rocklambros @afogel @President @MKaptein would this work for you?

[rocklambros]

@bar-capsule yes, that shape works for me. I backed a narrow modelCallRequest last week, and I'm fine dropping it for now. Neither shipped host can fire a per-call hook, and a hook no reference host can fire is one nobody can test. The two cases that met the reopen bar in issue #122 (where the data goes, and which model answered) are covered on the hosts we can run: turnStart says where the turn's calls go before any data leaves, and turnEnd records who answered.

Four things I'd want in the proposal issue:

1. Define the model object once (provider, name, server address and port, with the OTel GenAI names) and reference it from turnStart, preCompact, toolCallRequest and turnEnd. Three copies will drift.
2. Make the turnEnd field a list of the models that answered during the turn. A turn in a tool loop is several model calls, and a fallback to another provider halfway through is what case 5 wants to catch.
3. Say what a Guardian does with a turnStart model the session's AgBOM doesn't list. I'd treat it like a model swap: the host fires agbom/changed first, and a Guardian records a turn that names a model it has no inventory for. Otherwise the per-turn field and the inventory can disagree and nothing says which one wins.
4. Say the limit in the hook text. The turnStart model is where the turn starts sending. A harness that switches models inside a turn without an agbom/changed is the gap, and that's the case the dedicated hook stays parked for. Nobody should read the field as a promise for the whole turn.

Landing it with the usage object from issue #124 on turnEnd in one PR makes sense.

@President, since you wrote this up, would you open the proposal issue with Bar's shape and these four, and link this discussion, issue #122 and issue #124? That gives the leads one thing to triage.

[President]

@bar-capsule yes, this shape works for me.
@rocklambros done: #363 - Bar's shape plus your four points, linked to #122 and #124.
Thanks @MKaptein and @afogel for the input. Happy to change anything.