Reviewing files that changed from the base of the PR and between 4e33465 and e8a9ca4.

• frontend/javascripts/test/snapshots/public-test/test-bundle/test/backend-snapshot-tests/misc.e2e.js.snap is excluded by !**/*.snap

• app/controllers/CreditTransactionController.scala (1 hunks)
• app/controllers/JobController.scala (10 hunks)
• app/controllers/OrganizationController.scala (1 hunks)
• app/controllers/WKRemoteWorkerController.scala (3 hunks)
• app/mail/DefaultMails.scala (1 hunks)
• app/models/job/JobService.scala (1 hunks)
• app/models/organization/CreditTransaction.scala (1 hunks)
• app/models/organization/CreditTransactionService.scala (1 hunks)
• app/models/organization/CreditTransactionState.scala (1 hunks)
• app/models/organization/OrganizationService.scala (4 hunks)
• app/models/team/PricingPlan.scala (1 hunks)
• app/utils/WkConf.scala (1 hunks)
• app/views/mail/orderCredits.scala.html (1 hunks)
• app/views/mail/orderCreditsRequest.scala.html (1 hunks)
• conf/application.conf (1 hunks)
• conf/messages (1 hunks)
• conf/webknossos.latest.routes (2 hunks)
• frontend/javascripts/admin/admin_rest_api.ts (1 hunks)
• frontend/javascripts/admin/organization/organization_cards.tsx (2 hunks)
• frontend/javascripts/admin/organization/upgrade_plan_modal.tsx (3 hunks)
• frontend/javascripts/messages.tsx (1 hunks)
• frontend/javascripts/oxalis/view/action-bar/starting_job_modals.tsx (18 hunks)
• frontend/javascripts/test/snapshots/public-test/test-bundle/test/backend-snapshot-tests/misc.e2e.js.md (2 hunks)
• frontend/javascripts/types/api_flow_types.ts (1 hunks)
• tools/postgres/schema.sql (7 hunks)
• util/src/main/scala/com/scalableminds/util/time/Instant.scala (1 hunks)

• app/models/organization/CreditTransactionState.scala

frontend/javascripts/oxalis/view/action-bar/starting_job_modals.tsx (19)

31-31: Import usage is appropriate
These changes look correct and necessary for formatting voxel volumes.

---

50-50: Import usage is appropriate
Importing BoundingBox appears correct for bounding box calculations.

---

111-111: Optional property addition
Introducing an optional jobCreditCostsPerGVx property in StartJobFormProps is consistent with dynamic cost calculations.

---

118-118: New property for volume rendering
Adding showVolume to BoundingBoxSelectionProps is a clear, self-explanatory approach for controlling volume display.

---

Line range hint 123-142: Rendering bounding box & volume
Passing showVolume to conditionally display formatted volume in renderUserBoundingBox is clear and intuitive. Code logic is consistent with the bounding box usage.

---

160-160: Default parameter value
The default false for showVolume prevents accidental volume display.

---

166-166: Type definition
Using showVolume: boolean; aligns properly with the usage and default.

---

185-185: Prop forwarded to bounding box render
Forwarding showVolume makes the bounding box rendering more flexible.

---

196-196: Consistent default parameter
Again, defaulting showVolume to false ensures backward compatibility.

---

259-259: Prop propagation
Explicitly passing showVolume={showVolume} to the BoundingBoxSelection is clear.

---

536-549: Check rounding logic
Using Math.ceil(jobCosts * 100) enforces upward rounding. Verify that this behavior matches the intended billing policy, as it may differ from a standard round.

---

643-651: Prop destructuring
Destructuring jobCreditCostsPerGVx from props is consistent with the rest of the code.

---

674-682: Bounding box selection logic
The ternary fallback for selectedBoundingBox is sensible. This ensures the bounding box is derived properly for cost calculations.

---

846-846: Feature-based cost retrieval
Pulling neuronInferralCostsPerGVx from features is consistent with the global approach for dynamic pricing.

---

856-856: Passing cost prop
Sending neuronInferralCostsPerGVx to StartJobForm properly links to the credit-based pricing system.

---

884-884: Feature-based cost retrieval
Similarly, pulling mitochondriaInferralCostsPerGVx is consistent.

---

894-894: Passing cost prop
Providing jobCreditCostsPerGVx={mitochondriaInferralCostsPerGVx} correctly configures the segmentation form.

---

999-999: Feature-based cost retrieval
Getting alignmentCostsPerGVx from features() follows the established pattern.

---

1012-1012: Integration of alignment cost
Aligning sections also consumes credits, using alignmentCostsPerGVx for cost calculation is consistent.

app/controllers/CreditTransactionController.scala (1)

57-66: Validate transaction state before refunding.
The refund action checks if the transaction belongs to the organization but not whether the transaction is still pending or already refunded. Consider adding a state check to prevent multiple refunds or refunds for completed transactions.

app/models/organization/CreditTransactionService.scala (3)

17-20: Double-check negative balance scenarios.
While hasEnoughCredits returns whether the balance is >= creditsToSpent, no further check prevents negative balances if multiple transactions run concurrently. You may want to enforce stronger locks or a transaction-based approach to ensure consistency.

---

43-49: Confirm job-to-transaction mapping consistency.
completeTransactionOfJob depends on the transaction for a given jobId. If there are multiple transactions per job, this could lead to unexpected results. Ensure only one pending transaction per job or handle parallel completions gracefully.

---

57-60: Validate job ID assignment for concurrency safety.
addJobIdToTransaction updates an existing transaction, but multiple threads could map different job IDs if the transaction is used concurrently. Consider locking or transaction isolation if that’s a concern.

app/models/organization/CreditTransaction.scala (4)

28-56: DAO extension is well-structured.
The DAO cleanly extends SQLDAO, providing a consistent pattern for database interactions. Good approach for separation of concerns.

---

58-63: Review access control for read operations.
readAccessQ broadens access if the user is super user, but also includes an OR TRUE in (SELECT isSuperUser...) snippet. Verify that this logic doesn’t inadvertently grant access for unauthorized reads.

---

71-79: Check for non-existent transaction IDs.
findOne calls parseFirst which may fail if the ID doesn’t exist. Make sure you handle the resulting Fox failure in any calling code.

---

171-179: Ensure single transaction retrieval per job.
findTransactionForJob retrieves only the first match, but multiple transactions per job could exist in edge cases. Decide whether that scenario is allowed, and if so, handle it explicitly.

app/controllers/JobController.scala (7)

9-9: Import usage for credit management
It's good to see the new CreditTransactionService integrated here. Ensure that calls to it are always made from secure, authenticated endpoints.

---

67-68: Constructor injection verified
Injecting organizationService and creditTransactionService is consistent with the rest of the codebase. Make sure to include unit tests that validate these dependencies.

---

239-248: Bounding box check vs. credits
There’s a TODO suggesting that the bounding box check should be disabled since credits are already charged. Verify whether bounding box restrictions serve an additional purpose (e.g., resource usage constraints). Also remember to add any missing error messages to messages.conf and ensure test coverage for boundary conditions.

---

285-289: Revisit bounding box logic for mitochondria inference
Similar to neuron inference, there is a TODO to potentially disable the bounding box check. Verify whether this is truly desired, as bounding box checks can prevent resource overuse. Also ensure any error messages are finalized in messages.conf.

---

333-334: Confirm error messaging for insufficient credits
A TODO indicates adding a messages.conf entry for “job.notEnoughCredits.” Ensure these errors are user-friendly and tested for large bounding box scenarios.

---

493-493: Verify watermark requirement for paid plans
This logic forces paid plans to include a watermark. Generally, paid subscriptions remove or relax watermark requirements. Double-check if this is intended or if the condition should be inverted.

---

496-496: Confirm SD resolution requirement for paid plans
For paid customers, requiring SD resolution might be counterintuitive if higher-resolution outputs are typically a premium feature. Confirm that this constraint is correct or invert the condition if needed.

app/models/team/PricingPlan.scala (1)

8-9: Distinguish trial vs. paid plans
The current check lumps trial plans together with fully paid tiers. If a trial is not truly paid, consider updating the condition to exclude Team_Trial or Power_Trial. Otherwise, clarify that trials are regarded as paid for the application’s logic.

util/src/main/scala/com/scalableminds/util/time/Instant.scala (1)

62-63: Be mindful of date granularity
java.sql.Date does not store time components, so converting it to an epoch millisecond Instant may produce unexpected times at midnight UTC. Ensure all consumers of this method are aware of the day-only precision.

app/controllers/WKRemoteWorkerController.scala (2)

12-12: Import statement looks good.
No issues at this point.

---

24-24: New constructor parameter injection is appropriate.
This parameter dependency helps integrate credit transactions without cluttering the controller's code.

app/models/organization/OrganizationService.scala (2)

25-25: Constructor extension for credit transaction handling is correct.
Adding creditTransactionDAO here is a logical move to keep all organization-related operations encapsulated.

---

68-69: Displaying owner name and credit balance is helpful.
Check whether any Personally Identifiable Information (PII) might be exposed unintentionally. If safe, this addition is clear and beneficial.

conf/application.conf (1)

156-158: Cost configuration addition is clear.
Ensure the numeric values are correctly parsed as doubles and consumed appropriately for cost calculations.

frontend/javascripts/admin/organization/upgrade_plan_modal.tsx (1)

9-9: Good addition for email sending.

The new import of sendOrderCreditsEmail is properly utilized in handleOrderCredits below. No issues found here.

app/models/job/JobService.scala (2)

242-247: Ensure fractional bounding boxes are intended.

Dividing the parsed bounding box by parsedMag may yield non-integer coordinates. Confirm that fractional bounding boxes are valid in your logic. If only integer voxels are acceptable, enforce rounding or add domain checks.

---

222-222: Double-check bounding box validity.

Ensure zero or negative dimensions for boundingBox or mag are properly validated. Consider validating further (e.g., boundingBox corners or negative extents) to avoid unexpected behaviors.

✅ Verification successful

Bounding box validation is properly implemented.

The codebase already has comprehensive validation for bounding box dimensions:

• Non-negative width/height/depth enforced by parsing
• Zero/negative dimensions checked via isEmpty
• Volume and edge length limits prevent unreasonable extents
• Negative coordinates are properly supported

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Searching for parseBoundingBoxWithMagOpt calls to confirm usage
rg -A 3 'parseBoundingBoxWithMagOpt'

Length of output: 2080

---

Script:

#!/bin/bash
# Search for BoundingBox class and fromLiteral implementation
ast-grep --pattern 'object BoundingBox {
  $$$
  def fromLiteral($$$) {
    $$$
  }
  $$$
}'

# Also search for any BoundingBox validation related code
rg -A 5 'BoundingBox.*valid|valid.*BoundingBox'

# Search for Vec3Int fromMagLiteral implementation
ast-grep --pattern 'object Vec3Int {
  $$$
  def fromMagLiteral($$$) {
    $$$
  }
  $$$
}'

Length of output: 5404

---

Script:

#!/bin/bash
# Search for BoundingBox class implementation
rg -A 10 'case class BoundingBox|object BoundingBox'

# Search for specific validation checks within BoundingBox
rg -A 5 'width|height|depth.*[<=>]|[<=>].*width|height|depth'

Length of output: 81972

conf/messages (1)

43-43: Consistent and user-focused messaging

The newly added error message is well-phrased and aligns with the existing message style, clearly explaining that only the organization owner can order credits. This helps users quickly understand the authorization requirements.

frontend/javascripts/messages.tsx (1)

495-496: Accurate feedback for credit requests

Adding "organization.credit_request_sent" clarifies to users that their credit request email was sent. The message is concise and consistent with the rest of the file’s user-facing notifications.

conf/webknossos.latest.routes (2)

249-249: Validate and handle potential edge cases for requested credits.

The new route POST /pricing/requestCredits relies on the query parameter requestedCredits. Consider validating its value (e.g., ensuring it’s non-negative and within expected upper bounds) to avoid potential abuse or data inconsistencies.

---

294-296: Confirm access control checks for superuser-only credit transactions.

Ensure that these newly introduced endpoints (POST /creditTransactions/chargeUpCredits and PATCH /creditTransactions/:transactionId) feature robust access control, restricting usage to super users or authorized admins. This prevents unauthorized credit modifications or refunds.

app/views/mail/orderCredits.scala.html (1)

1-2: Template parameters look fine.

No immediate concerns. Play’s template engine will automatically escape the supplied arguments, minimizing security issues like XSS if they are user-provided.

app/views/mail/orderCreditsRequest.scala.html (1)

1-2: Signature parameters appear correct.

All parameters are strongly typed, and name/email are inserted safely in the Play template. This is good for maintainability and security.

tools/postgres/schema.sql (3)

23-23: LGTM! Schema version bump is appropriate.

The schema version is correctly incremented for the new credit system changes.

---

1092-1093: Verify the credit revocation scheduling approach.

The cron schedule is commented out. We need to confirm if this is intentional or if it should be enabled for production.

Please clarify:

1. Should this be uncommented for production?
2. Is pg_cron the preferred scheduling method, or should we use an external scheduler?
3. Have we considered timezone implications for the 00:01 schedule?

---

998-998: ⚠️ Potential issue

Critical: Address the TODO comment about revoked free credits.

This TODO indicates a potential issue with credit revocation that needs to be fixed before deployment.

Let's verify the current behavior:

Reviewing files that changed from the base of the PR and between e8a9ca4 and 98164a9.

• .circleci/config.yml (1 hunks)
• .circleci/not-on-master.sh (1 hunks)
• conf/evolutions/126-credit-transactions.sql (1 hunks)
• tools/postgres/schema.sql (7 hunks)

• GitHub Check: circleci_build

conf/evolutions/126-credit-transactions.sql (5)

1-4: LGTM! Transaction block and version check are properly implemented.

The script correctly ensures atomicity and proper migration order.

---

24-29: LGTM! View and indexes are well-designed.

The view properly handles soft deletion, and the indexes will optimize queries in the revocation procedure.

---

31-34: LGTM! Foreign key constraints are properly implemented.

The deferrable constraints allow for flexible transaction management.

---

64-64: Address the TODO comment about refunded free credits.

The comment indicates a known issue with refunded free credits not being revoked. This needs to be addressed before deployment.

Would you like me to help implement the fix for handling refunded free credits?

---

158-160: LGTM! Schema version update is properly placed.

The update is correctly wrapped in the transaction block.

tools/postgres/schema.sql (3)

23-23: LGTM: Schema version increment is appropriate.

The schema version is incremented from 125 to 126, which is appropriate for introducing credit transaction functionality.

---

781-782: LGTM: Appropriate indexes for credit transactions.

The indexes on state and expiration_date will improve query performance for credit transaction operations.

---

838-840: LGTM: Well-defined foreign key constraints.

The foreign key constraints for organization and paid job references are properly defined with the DEFERRABLE option, which is good for transaction handling.

Reviewing files that changed from the base of the PR and between b7e27a1 and 1d2380d.

• MIGRATIONS.unreleased.md (1 hunks)
• frontend/javascripts/admin/organization/upgrade_plan_modal.tsx (6 hunks)
• frontend/javascripts/types/api_flow_types.ts (3 hunks)

• MIGRATIONS.unreleased.md

• GitHub Check: circleci_build

frontend/javascripts/admin/organization/upgrade_plan_modal.tsx (11)

9-9: Good import addition for the credit system implementation.

The addition of the sendOrderCreditsEmail import aligns with the credit system functionality being implemented.

---

17-18: Appropriate imports for feature access and currency formatting.

The imports of features and formatCurrency are well-chosen for implementing the credit ordering functionality, providing access to configuration values and proper formatting utilities.

---

23-23: React hooks added for state management in the new component.

The addition of useEffect and useState to the imports is necessary for managing the credit amount and cost calculation in the new OrderWebknossosCreditsModal component.

---

40-40: Export functions to improve reusability across components.

Making these functions exportable improves the modularity of the codebase and allows them to be reused in other components, which is a good practice for maintaining a clean architecture.

Also applies to: 73-73, 118-118, 251-251

---

302-306: Well-structured entry point function for ordering credits.

This function follows the same pattern as the other modal-triggering functions in the file, maintaining consistency in the codebase.

---

310-314: Inconsistent state variable naming.

The state setter function setCreditCostsAsString uses plural "Costs" while the state variable creditCostAsString uses singular "Cost".

-  const [creditCostAsString, setCreditCostsAsString] = useState<string>(
+  const [creditCostAsString, setCreditCostAsString] = useState<string>(

---

320-323: Add Unicode thin space between number and currency symbol.

There should be a thin space between the number and the currency symbol as mentioned in previous review comments.

-    setCreditCostsAsString(`${totalCostInEuro}€/${totalCostInDollar}$`);
+    setCreditCostAsString(`${totalCostInEuro}\u2009€/${totalCostInDollar}\u2009$`);

---

325-338: Good error handling for credit order requests.

The implementation includes proper error handling with try/catch, displaying an error toast to the user if the credit request fails. This addresses a previous review comment that highlighted the need for error handling.

---

343-343: Use Unicode thin space in the OK button text.

Apply the same formatting recommendation to ensure consistency with currency display throughout the UI.

-      okText={`Buy more WEBKNOSSOS Credits for ${creditCostAsString}`}
+      okText={`Buy more WEBKNOSSOS Credits for ${creditCostAsString.replace('€', '\u2009€').replace('$', '\u2009$')}`}

---

356-365: Good implementation of the credit amount input.

The InputNumber component is properly configured with appropriate minimums, steps, and onChange handlers. The min=1 setting prevents ordering zero credits, which was a good recommendation from a previous review.

---

386-386: Good export addition for the new functionality.

The new function is properly added to the default exports, making it accessible to other parts of the application.

frontend/javascripts/types/api_flow_types.ts (2)

652-652: Type consistency concern for financial values

The creditBalance is typed as string | null | undefined, which might lead to confusion when performing arithmetic operations. While this appears to be a deliberate choice (based on PR comments about precision in financial calculations), it's important to ensure that the codebase consistently handles these string-based financial values.

---

770-770:

❓ Verification inconclusive

Ensure consistent credit value handling

Similar to creditBalance, creditCost is typed as string | null | undefined. Make sure the application has consistent utility functions for performing operations on these string-based credit values to avoid floating-point precision issues.

---

🏁 Script executed:

#!/bin/bash
# Check for credit handling utility functions in the codebase
echo "Searching for credit-related utility functions..."
rg -A 5 "format.*Credit|calculate.*Credit|convert.*Credit" --type ts

Length of output: 5058

---

Ensure consistent usage of credit utilities for creditCost

It looks like the codebase already includes a centralized utility—formatCreditsString in frontend/javascripts/libs/format_utils.ts—that handles string-based credit values. Please verify that all operations involving creditCost (typed as string | null | undefined in frontend/javascripts/types/api_flow_types.ts) consistently make use of these dedicated utilities (or other equivalent functions like formatCurrency where appropriate) to avoid floating-point precision issues. In particular:

• Make sure any arithmetic or formatting on creditCost leverages the centralized functions.
• Confirm that nullish values are correctly handled before operations are applied.
• Cross-check that usage in components (e.g., in admin modals and job-related views) remains consistent with how creditBalance is managed.

Reviewing files that changed from the base of the PR and between 01cf95d and b26afd5.

• frontend/javascripts/test/snapshots/public-test/test-bundle/test/backend-snapshot-tests/misc.e2e.js.snap is excluded by !**/*.snap

• frontend/javascripts/oxalis/view/action-bar/starting_job_modals.tsx (27 hunks)
• frontend/javascripts/test/snapshots/public-test/test-bundle/test/backend-snapshot-tests/misc.e2e.js.md (2 hunks)

• frontend/javascripts/test/snapshots/public-test/test-bundle/test/backend-snapshot-tests/misc.e2e.js.md

• GitHub Check: circleci_build

frontend/javascripts/oxalis/view/action-bar/starting_job_modals.tsx (39)

2-7: LGTM: API imports updated for credit system support.

The imports have been correctly expanded to include credit-related functionality from the admin REST API.

---

15-15: LGTM: Added import for credit ordering.

Adding this import correctly enables the functionality for users to order WEBKNOSSOS credits.

---

38-40: LGTM: Added useful formatting imports.

The new imports for formatting credits and voxels are appropriate for displaying currency values and volumes in a user-friendly way.

---

56-59: LGTM: Added Redux action imports for organization.

These organization action imports are necessary for updating the organization's credit balance in the Redux store.

---

66-69: LGTM: Updated imports and fixed React ordering.

The imports are properly organized, and React is imported correctly. The addition of Link from React Router is appropriate for the credit purchasing links.

---

79-82: LGTM: Updated modal state types to use enum.

The code has been correctly updated to use the APIJobType enum values instead of string literals for better type safety.

---

113-114: LGTM: Updated type to use APIJobType enum.

Correctly updated to use the APIJobType enum instead of string literals for better type safety.

---

124-125: LGTM: Added jobCreditCostPerGVx prop.

The new prop allows passing job credit cost per Gigavoxel, which is necessary for credit cost calculation.

---

131-132: LGTM: Added showVolume prop to control bounding box display.

This new property appropriately controls whether to display volume information in the bounding box selection UI.

---

136-156: LGTM: Updated function signature to support volume display.

The function has been properly updated to accept the new showVolume parameter and conditionally display volume information.

---

173-174: LGTM: Added showVolume parameter with appropriate default.

The showVolume parameter has been correctly added with a default value of false to maintain backward compatibility.

Also applies to: 179-180

---

198-199: LGTM: Correctly passing showVolume to the rendering function.

The renderUserBoundingBox function now receives the showVolume parameter as expected.

---

209-210: LGTM: Added showVolume parameter to BoundingBoxSelectionFormItem.

Consistently added the showVolume parameter with a proper default value.

---

272-273: LGTM: Properly passing showVolume to the BoundingBoxSelection component.

The parent component correctly forwards the showVolume prop to the child component.

---

403-404: LGTM: Updated to use APIJobType enum.

The code has been properly updated to use the APIJobType enum instead of string literals.

---

419-436: LGTM: Added Mitochondria detection option.

The UI for mitochondria detection has been properly implemented with appropriate styling and event handling.

---

441-443: LGTM: Updated to use APIJobType enum for nuclei detection.

The code has been properly updated to use the APIJobType enum.

---

459-464: LGTM: Updated conditional rendering to use APIJobType enum.

The conditional rendering of form components based on the job type has been correctly updated to use the APIJobType enum.

---

548-654: LGTM: Well-designed JobCreditCostInformation component.

The new component effectively displays:

• Job cost information based on bounding box size
• Organization's current credit balance
• Information about how costs are calculated
• Error messages when credits are insufficient

The TODO comment on line 613 is deliberately left for after the testing phase, as confirmed in previous review discussions.

---

728-756: LGTM: Added helpful utility functions for bounding box management.

These well-designed utility functions:

• getBoundingBoxesForLayers: Generates bounding boxes for complete layers
• useCurrentlySelectedBoundingBox: Manages the currently selected bounding box state

Both functions are properly implemented with appropriate types and logic.

---

783-785: LGTM: Added organization credit balance from Redux store.

The code correctly retrieves the organization's credit balance from the Redux store.

---

788-796: LGTM: Using new utility functions for bounding box selection.

The code properly utilizes the new helper functions for bounding box management.

---

797-808: LGTM: Added credit cost fetching functionality.

The useFetch hook is properly implemented to fetch credit cost information when the bounding box changes.

---

809-814: LGTM: Added effect to update organization credits.

This effect ensures the Redux store is updated with the latest credit balance from the backend.

---

858-869: LGTM: Added organization credit refresh after job start.

The code properly refreshes the organization's credit information after a job is started, with good error handling.

---

927-928: LGTM: Conditionally showing volume based on job credits.

The code correctly passes the showVolume property based on whether the job has a credit cost.

---

937-945: LGTM: Conditionally rendering the JobCreditCostInformation component.

The component is only rendered when a credit cost is specified, with all necessary props passed correctly.

---

949-951: LGTM: Added credit cost information to the button label.

The button now includes credit cost information when available, improving user experience.

---

993-994: LGTM: Added neuron inferral cost per GVx from features.

The cost per gigavoxel is correctly retrieved from the features configuration.

---

1000-1001: LGTM: Updated to use APIJobType enum for job name.

The code consistently uses the APIJobType enum.

---

1005-1006: LGTM: Passing neuron inferral cost to StartJobForm.

The credit cost per gigavoxel is properly passed to the form component.

---

1070-1071: LGTM: Added mitochondria inferral cost per GVx from features.

The cost information is consistently retrieved from the features configuration.

---

1075-1076: LGTM: Updated to use APIJobType enum for job name.

The code consistently uses the APIJobType enum.

---

1080-1081: LGTM: Passing mitochondria inferral cost to StartJobForm.

The credit cost per gigavoxel is properly passed to the form component.

---

1129-1130: LGTM: Updated to use APIJobType enum for job name.

The code consistently uses the APIJobType enum for custom AI model inference.

---

1185-1186: LGTM: Added alignment cost per GVx from features.

The cost information is consistently retrieved from the features configuration.

---

1189-1190: LGTM: Updated to use APIJobType enum for job name.

The code consistently uses the APIJobType enum.

---

1198-1199: LGTM: Passing alignment cost to StartJobForm.

The credit cost per gigavoxel is properly passed to the form component.

---

1293-1294: LGTM: Updated to use APIJobType enum for job name.

The code consistently uses the APIJobType enum for materializing volume annotations.