Evaluate GPT-6 Astra capacity scope and reasoning-effort selector onboarding #49

New issue

Closed

opened 2026-09-07 08:40:41 +00:00 by kilo · 1 comment

kilo commented

2026-09-07 08:40:41 +00:00

Member

Goal

Determine whether and how GPT-6 Astra can become a valid Scarcity Router
selector candidate without guessing its identity, capability or subscription
capacity semantics.

Why

Policy v5 records GPT-6 Astra Low as the preferred reference scientific,
methodological and deep-technical role, but the active selector catalog remains
the calibrated four-model M2 catalog. Selector onboarding requires separate
evidence and acceptance.

Evidence and questions

What exact subscription or runtime mechanism provides Astra?
What normalized capacity scope does using Astra consume?
Can that capacity be observed safely and reliably?
Does it share openai/codex or use another scope? Do not assume.
What exact provider/model/variant identity is evidenced?
How should reasoning effort (low/medium/high/max, if applicable) be represented?
Is effort a separate candidate variant or another explicit selector input?
What evidenced ratings exist for reasoning, coding,
scientific_methodological, writing_editorial, tool_use and
translation_multilingual?
What hard properties are evidenced?
Which profile eligibility sets change?
What catalog_version and policy_version changes would follow?
What tests and live acceptance are required?

Constraints

research and calibration first
no guessed capacity binding
no private identifiers committed
no routing change until evidence is accepted
no model execution or provider-collector change as part of this issue's
research phase

Links

Parent policy update: #48
Active catalog: model-catalog.json
Calibration record: docs/model-calibration.md
Capacity applicability: docs/capacity-model.md

## Goal Determine whether and how GPT-6 Astra can become a valid Scarcity Router selector candidate without guessing its identity, capability or subscription capacity semantics. ## Why Policy v5 records GPT-6 Astra Low as the preferred reference scientific, methodological and deep-technical role, but the active selector catalog remains the calibrated four-model M2 catalog. Selector onboarding requires separate evidence and acceptance. ## Evidence and questions 1. What exact subscription or runtime mechanism provides Astra? 2. What normalized capacity scope does using Astra consume? 3. Can that capacity be observed safely and reliably? 4. Does it share `openai/codex` or use another scope? Do not assume. 5. What exact provider/model/variant identity is evidenced? 6. How should reasoning effort (`low`/`medium`/`high`/`max`, if applicable) be represented? 7. Is effort a separate candidate variant or another explicit selector input? 8. What evidenced ratings exist for reasoning, coding, scientific_methodological, writing_editorial, tool_use and translation_multilingual? 9. What hard properties are evidenced? 10. Which profile eligibility sets change? 11. What `catalog_version` and `policy_version` changes would follow? 12. What tests and live acceptance are required? ## Constraints - research and calibration first - no guessed capacity binding - no private identifiers committed - no routing change until evidence is accepted - no model execution or provider-collector change as part of this issue's research phase ## Links - Parent policy update: #48 - Active catalog: `model-catalog.json` - Calibration record: `docs/model-calibration.md` - Capacity applicability: `docs/capacity-model.md`

kilo referenced this issue

2026-09-07 08:40:51 +00:00

Update multi-model LLM operating policy and role assignments #48

kilo referenced this issue

2026-09-07 08:43:44 +00:00

Update multi-model LLM operating policy #50

kilo referenced this issue

2026-09-07 22:21:23 +00:00

Selector: make reasoning effort first-class and onboard Terra #57

kilo referenced this issue

2026-09-08 18:21:13 +00:00

Selector: Make reasoning effort first-class and onboard Terra #58

kilo commented

2026-09-09 20:16:21 +00:00

Author

Member

Current-state checkpoint (2026-09-09): PR #58 / D-032 is merged at develop d76b4a09ff; required f503107 ancestry verified and starting worktree clean. Active catalog is v2 with seven configurations: Luna Medium/Max, Terra Medium, Sol Medium/High, GLM-5.3 Max and GLM-5.3-Flash Max. Policy is v6; reasoning_effort is already first-class, independent of opaque variant identity. The original issue text is retained as historical context. #49 now concerns Astra Low identity, effort-specific calibration, hard properties and subscription capacity/plan applicability, not implementation of reasoning-effort support.

Execution boundary from the owner's current assignment: one existing Kilo session, no subagents, switching or internal reviewer loop; requested OpenAI / gpt-6-astra / low, runtime attestation RUNTIME_UNOBSERVABLE (no independent generated-turn/effort metadata available). Maximum 120 minutes, one bounded evidence pass and one status observation; no inference quota probe. Threat boundary: no credentials, raw responses, personal quota/reset values or private bucket identifiers in artifacts. Expected complexity: narrow documentation/evidence packet; only if FULL_GENERIC_ONBOARDING_SUPPORTED is evidenced, one catalog configuration and focused tests/docs. No collector, capacity-v3, profile-minimum or D-032 ranking change. Any material unresolved applicability blocks onboarding and escalates to the human. Human remains review/merge gate; one PR will remain open and unmerged.

Current-state checkpoint (2026-09-09): PR #58 / D-032 is merged at develop d76b4a09ffa4365ea22b3121086b8198a197eaef; required f503107 ancestry verified and starting worktree clean. Active catalog is v2 with seven configurations: Luna Medium/Max, Terra Medium, Sol Medium/High, GLM-5.3 Max and GLM-5.3-Flash Max. Policy is v6; reasoning_effort is already first-class, independent of opaque variant identity. The original issue text is retained as historical context. #49 now concerns Astra Low identity, effort-specific calibration, hard properties and subscription capacity/plan applicability, not implementation of reasoning-effort support. Execution boundary from the owner's current assignment: one existing Kilo session, no subagents, switching or internal reviewer loop; requested OpenAI / gpt-6-astra / low, runtime attestation RUNTIME_UNOBSERVABLE (no independent generated-turn/effort metadata available). Maximum 120 minutes, one bounded evidence pass and one status observation; no inference quota probe. Threat boundary: no credentials, raw responses, personal quota/reset values or private bucket identifiers in artifacts. Expected complexity: narrow documentation/evidence packet; only if FULL_GENERIC_ONBOARDING_SUPPORTED is evidenced, one catalog configuration and focused tests/docs. No collector, capacity-v3, profile-minimum or D-032 ranking change. Any material unresolved applicability blocks onboarding and escalates to the human. Human remains review/merge gate; one PR will remain open and unmerged.

kilo referenced this issue

2026-09-09 20:23:09 +00:00

Astra: Record selector onboarding evidence and blockers #59